People Process and Tools in an Agile Project – How to Fix a Broken Project

The inter-relationship of people, process, and tools in an Agile project is important to understand. It is particularly important when you try to fix a broken project.

People Process and Tools

Typical Traditional Project Management Approach

On several occasions, I’ve been brought in to rescue a project that was in trouble. In many cases, there is an expectation that, as a Project Manager,

  • I will re-plan the project,
  • Get it on the right track, and
  • Perhaps also”ram-rod” the effort to get it moving through to completion if necessary.

That’s the typical expectation of what a traditional Project Manager might do. If a project fails, it is the Project Manager who is typically held responsible.

People Process and Tools in an Agile Project

I think the Agile environment is different.

  • I’ve certainly seen a need to re-plan projects and get them on the right track and it often takes some strong leadership skills to do that; however
  • A more critical role in many cases in an Agile project is developing the right people, process, and tools to make the Agile project teams more effective and self-sufficient.

The irony is that if you do that successfully, you might practically eliminate the need for a Project Manager and put yourself out of a job, but that’s the right thing to do. I think that’s a key difference in an Agile project. In a traditional project, the role of the Project Manager might normally be expected to continue all the way to the end in order to push the project on to completion.

I’ve seen several Agile projects that got into trouble because they didn’t have an adequate amount of upfront planning. And, as a result the project didn’t have the right people, process, and tools to be successful. This happens frequently in larger, enterprise-level projects because many people don’t understand or appreciate what it takes to scale an Agile development approach to an enterprise level. Here are a few examples of typical problem areas I’ve seen:


The first and most important area is related to “people”:

  • It takes a lot more skill to organize a large, enterprise-level Agile project
  • The number and different types of people involved are typically a lot more numerous and complex
  • It can be a real challenge to figure out how to organize all of the people (both inside and outside of the project teams) to get the effort done successfully

Here’s an example:

  • I’ve seen projects get in trouble because there was no Project Governance model defined to provide overall direction to the project
  • In many cases at an enterprise level, its not as simple as having a single Product Owner to provide direction. And, without a plan for how all of the stakeholders and decision-makers will participate in the project as it moves forward, it’s very easy for a project to go off-course and get in trouble


The second major area is process:

  • In many cases, there’s also not a clear understanding of what it takes to scale an Agile process like Scrum to enterprise levels.
  • There are typically layers of management needed above the team level and it has to be well-integrated with the company’s primary management structure.
  • It may not be as simple as layering a Scrum-of-Scrums approach on top of a couple of Agile teams.
  • There is also often a need to define a hybrid process that blends together:
    • Some amount of traditional plan-driven project management at a higher level with
    • An Agile development approach like Scrum at the team level.


The third area that it often important in effectively organizing large, enterprise-level Agile projects is tools.

  • In large, complex enterprise-level projects, tools also can be a major problem area
  • The tools that people many times use for small, simple Agile projects, just don’t necessarily scale well to larger, more complex, enterprise-level projects

For example,

  • People might use physical story cards and white-boards for tracking progress of small, single-team Agile projects but
  • Those methods start to fall short very rapidly as you to try to scale the effort to larger, enterprise-level projects with multiple teams that need to coordinate with each other and may not be collocated
  • Managing that type of situation typically requires more sophisticated, on-line electronic tools

People Process and Tools – Overall Summary

I’ve been in situations where clients might not have the patience to address some of these more systemic issues involving people, process, and tools:

  • In some cases, there might be an expectation that the Project Manager will just somehow “ram-rod” the project to get it moving and get it back on the right track but
  • Taking that kind of approach and ignoring the more systemic factors associated with people, process, and tools is not likely to be very successful,
  • That’s equivalent to just putting pressure on a broken process to make it work better. A more effective approach in most cases is to fix the broken process.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is Agile Functional Decomposition? Why Is It Important?

What is Agile functional decomposition? (and why is it important?) Investopedia defines “functional decomposition” as follows:

“A method of business analysis that dissects a complex business process to show its individual elements. Functional decomposition facilitates the understanding and management of large and/or complex processes and can be used to help solve problems:

  • Basically, functional decomposition takes something complicated and simplifies it
  • The individual elements of the process and their hierarchical relationship to each other are commonly displayed in a diagram called a functional decomposition diagram.”

How Is It Relevant to Agile?

Why is that relevant to Agile? A major goal of Agile is to maximize the business value that a project produces.

  • On small, simple projects, you might be able to easily discover what the business value is based on direct face-to-face discussion with the Product Owner and individual stakeholders
  • On large enterprise-level projects, that may not be so easy to do:
    • An example is that I was involved in a large project with about 500 user stories, and
    • We had to do some prioritization to move things out to a future release
    • Doing that on a project of that size without understanding the relationships among the stories can be very difficult if they’re not organized into some kind of functional hierarchy

Agile Functional Decomposition – Keeping Stories Well-Organized

Using functional decomposition to organize stories into epics and themes:

  • Makes it possible to keep all of the stories well-aligned with producing the higher-level business value that the project is intended to produce, and
  • It makes it a lot easier to effectively manage the Product Backlog

It also provides a capability for trace-ability

  • You can look at the top-level functionality and then look down into the functional decomposition to verify that the lower-level functionality is really complete and
  • That the lower-level functionality is sufficient to support the higher-level functionality.

Agile Functional Decomposition – Overall Summary

Functional decomposition has been around for years but many people don’t think it is relevant to Agile projects. It’s one of those traditional, plan-driven practices that people seem to assume is now obsolete and no longer relevant with Agile. I don’t believe that is the case.

  • You don’t have to completely throw away all the traditional plan-driven practices you may have learned in order to practice Agile and
  • Some of those practices become especially important as you begin to try to scale Agile to an enterprise level
  • Functional Decomposition is an example

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

The Importance of Agile Project Governance

Is Agile Project Governance an Oxymoron?

Do the words “Agile Project Governance” sound like they go together? On first glance, your answer might be “No”.

  • The idea of superimposing a Project Governance Model on an Agile project sounds like mixing oil and vinegar
  • However, I don’t believe that is necessarily the case especially when you attempt to scale an Agile project to large, complex enterprise-level projects
Agile Project Governance

Agile Project Governance – Conventional Agile Wisdom

Much of the wisdom about Agile has been about how to optimize the performance of an individual Agile team.

  • There are hundreds of books about almost every aspect of optimizing Agile team performance. However, the idea of scaling Agile to enterprise-level projects is a road that is far less traveled and requires a lot of new thinking
  • In many cases, it requires blending together some plan-driven principles and practices with Agile principles and practices. The goal is to create an overall governance model for large, complex programs consisting of multiple teams.

Agile Project Governance – Fitting the Approach to the Company

The predominant thinking in many cases seems to be that you have to shift the entire culture of a corporation to adapt it to an Agile development approach.

  • My experience has been that is not necessarily the best approach in many situations
  • The company’s culture:
    • Needs to be built around what makes sense for that company to be most successful.
    • Should be determined by the business environment that it operates in and that may not always be well-aligned with becoming totally Agile

Companies Focused on Product Innovation

An Agile culture works best in companies who are focused on product innovation. Examples are:

  • Companies who produce and sell software products like Intuit Quickbooks or
  • Where some form of product innovation is closely related to their primary business goals like

Companies Focused on Other Areas

In companies where product innovation is not the most important factor in the success of the business, it becomes a lot more difficult to convert a company to an Agile development approach because it may not make sense to force the company to adopt a culture that is totally Agile. Consider, for example, the following case studies from my new book:

Agile Project Governance – Some Examples

Here are a few examples from case studies I’ve done to illustrate the role of the company’s business environment.

Harvard Pilgrim Healthcare (HPHC)

HPHC’s business success is driven largely by customer satisfaction. They have been ranked number one in healthcare industry surveys for over nine years. Operational excellence is a very important goal. They must be able to process millions of healthcare transactions efficiently at a very low cost

  • They were faced with a requirement to do a massive redesign of all their operational systems that involved over 100 Agile teams over a five year period
  • Obviously, they can’t afford any disruption of customer service in that process, and
  • There are a lot of moving parts that need to be carefully coordinated to avoid any disruption of service to their customers.

General Dynamics, UK

General Dynamics, UK is a large defense contractor in Europe.

  • Obviously, there business has to be geared around government contracting so there are limits on how Agile they can become, yet
  • They were able to blend together some level of traditional plan-driven project/program management practices with an Agile development approach to achieve the right balance to fit their business


Valpak is a very Agile company and fast-paced product innovation is much more critical to their business success. It is the company that periodically sends people in the US those blue envelopes stuffed with coupons.

  • They have a huge processing facility in Tampa where paper comes in one end and millions of coupons stuffed in envelopes ready for mailing come out the other end
  • The whole operation is very highly automated and it is a very impressive operation
  • Valpak has been very successful in transforming their entire business using Dean Leffingwell’s Scaled Agile Framework.

Overall Summary

The key point is that each of these three businesses is different. Trying to use a “one size fits all” approach to force each business to adapt to a “textbook” agile model would not have been the best solution.

  • The right approach is to go in the other direction and fit the approach to the business environment
  • It requires a lot more skill to do that, but fortunately some frameworks and models are evolving to make that a lot easier to do. Dean Leffingwell’s Scaled Agile Framework is only one example

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is an Agile Business Analyst? How is the Role Different?

Many software development projects are moving rapidly to an Agile development approach:

  • That has dramatically impacted the role of a project manager in an Agile environment
  • Agile also has a significant impact on the role of a Business Analyst

In this article, we will explore “What is an Agile Business Analyst?” and “How is the role different?”.

What is an Agile Business Analyst?

Traditional Business Analyst Role

The traditional role of a Business Analyst is defined as follows:

“The business analyst’s primary objective is helping businesses implement technology solutions in a cost-effective way by determining the requirements of a project or program, and communicating them clearly to stakeholders, facilitators and partners.”
Business Analyst Job Description, Villanova Univ.

That’s the predominant role that has been played by Business Analysts for many years.  In some cases, the role has primarily focused on simply talking to users about their needs and writing requirements documents.

  • That it has been a very documentation-intensive role
  • However, the real value-added that a Business Analyst should provide is in helping to define innovative solutions to business problems
  • It should not be limited to just simply creating requirements documents. 

In a traditional plan-driven environment, documentation often takes on a life of its own. In that environment,

  • It is easy to lose sight of the fact that the goal is to create business value and
  • Documentation is only a by-product

What Are the Skills Needed by a Business Analyst?

In an Agile environment a Business Analyst needs to provide value beyond simply writing requirements documents. The Business Analyst has to have an understanding of:

Knowlege AreaRequirement
Business Domain KnowledgeIn-depth knowledge of the Business Domain that they work in (finance, healthcare, manufacturing, or whatever else it might be). That means that the BA understands:
  • What the major business processes are,
  • The metrics that are important to the business, and
  • How to improve the processes from a business perspective
Process Improvement Tools and TechniquesUnderstand how to:
  • Identify and define opportunities for improvement
  • Use process improvement tools and techniques such as Six Sigma and others to analyze an existing business process, and
IT Solutions PerspectiveKnow how to translate understanding of the business process improvement needs into IT solution requirements to create effective and innovative business solutions
Project Process UnderstandingNeed to understand:
  • How an overall project development process works, and
  • How their role fits into that process so that they can work most effectively as a member of a development team

These fundamental skills have not changed over the years. A good Business Analyst should be strong in all of these areas.

What Is Wrong With the Traditional Business Analyst Role?

The problems with the Traditional Business Analyst role are essentially the same as a Traditional Project Management role.

Level of Uncertainty

Today’s environment typically has a much higher level of uncertainty associated with defining software solutions.  The traditional approach of documenting detailed requirements prior to the start of projects just doesn’t work well with high levels of uncertainty: 

  • A lot of time might be wasted trying to define detailed requirements prior to the start of the project
  • Many of those requirements might be based on speculation and assumptions, and
  • Those requirements might then go through an enormous amount of change as the project is in progress.

Emphasis on Creativity and Innovation

The emphasis in many projects is shifting:

  • In the past, the primary emphasis in many projects has been on planning and control
  • A key goal was to achieve predictability of project costs and schedules
  • Competitive pressures today have created a need to put more emphasis on creativity and innovation to maximize the business value of the solution

An over-emphasis on planning and control can destroy creativity and innovation:

  • Can you imagine trying to develop the next generation of a very innovative product like a new iPhone using a traditional, plan-driven approach?
  • It would be impossible to do that based on developing detailed requirements for the product upfront.

How Do Agile Requirements Work?

To understand the role of a Business Analyst in an Agile environment, we first need to understand how an Agile requirements process works:

  • There are a lot of misconceptions about Agile. Some people may think that there are no documented requirements
  • That is not the case. The approach for developing requirements in an Agile project should be directly related to the level of uncertainty in the project

High Levels of Uncertainty

In a project with a high level of uncertainty, it might be foolish to try to develop detailed requirements prior to the start of the project:

  • In that environment, the requirements might be limited to an overall vision and high-level requirements that the project must meet
  • More detailed requirements would be further elaborated as the project is in progress. That elaboration would be based heavily on direct feedback and inputs from the users

Lower Level of Uncertainty

If there is a lower level of uncertainty, the project might go further towards developing more defined requirements.

  • That might be particularly true if there is a need for some level of predictability of the project costs and schedule
  • However, an Agile environment would still emphasize some level of flexibility and adaptivity to maximize the business value of the solution as the project is in progress

Key Differences

There are several key differences in an Agile approach:

1. Less Emphasis on Documentation

Agile requirements are considerably simplified and are typically written in terms of “user stories”. 

  • A “user story” is a brief and very succinct definition of a business need. It does not provide any detail about how it will be implemented, 
  • A “user story” is considered to be a “placeholder for conversation”. Further definition of how it will be implemented will be determined based on direct, face-to-face communications with the users. That will take place as the user stories are being implemented.

2. Changes Are Encouraged

An Agile approach is designed around flexibility and adaptivity to maximize the value of the solution.  For that reason, changes to requirements as the project is in progress are encouraged.

3. Direct Communication

There is a lot more direct communication between the business users and the project team. 

  • First, there is a Product Owner who represents the business. The Product Owner directly participates in the project to provide overall business direction and priorities
  • Second, the developers on the project team are expected to communicate directly with the business users. That is essential to further elaborate and define requirements as the project is in progress

In this kind of environment,

  • The role of a Business Analyst should be more than just an intermediary to talk to the users and document requirements
  • That role would inhibit direct communications with the project team. It would probably also limit the flexibility and adaptivity that is so important to an Agile approach

So, What is an Agile Business Analyst?

So, What is an Agile Business Analyst?

  • The role of a Business Analyst in an Agile environment is not well-defined
  • On small, simple Agile projects there may not be a need for a Business Analyst role
  • That is frequently not the case on large, complex enterprise-level projects

In an Agile environment,

  • It might be assumed that the Product Owner plays the role that might normally be played by a Business Analyst. However, the Product Owner responsibility goes well beyond the role of a Business Analyst, and
  • It can be very difficult for a Product Owner to perform that role without some assistance on very large, complex projects

Ways to Provide More Value-Added

The value-added provided by a Business Analyst in an Agile environment needs to go beyond simply writing requirements documents.  Here are some potential ways that a BA can provide a higher level of value:

1. Process Improvement

Many times, simply automating a process “as-is” does not provide a sufficient level of value. 

  • Rather than simply documenting a process “as-is”,
  • A Business Analyst can provide a much higher level of value by finding innovative ways to improve an existing process to make it more efficient or more effective

2. Analyzing a Broadly-Defined Area

In large, complex projects:

  • Using functional decomposition can be essential to create a well-organized, value-driven framework
  • That helps to align the Product Backlog with the required business value
  • It also makes it easier to understanding the relationship of the stories and epics to each other and for satisfying overall business goals

3. Writing Individual Stories

A Business Analyst can provide value by writing user stories that are very clear and concise and easy-to-understand and implement by the development team. 

Writing effective user stories is a skill that is often taken for granted.

  • In good stories the “why” or the “so that” clause that expresses the business value the story is intended to provide is important
  • A good BA can provide that perspective that is difficult for a developer to provide.

4. Identifying Related User Stories and Epics

In a large complex project, there is value in grouping stories into themes and epics as necessary. That can be essential to understand the interrelationship and associated business process flows. 

  • The interrelationship of user stories and epics should be well-understood and
  • The implementation of stories across different functional areas may require some planning and coordination so that they are consistently implemented.
  • This overall framework can provide a mechanism for easily identifying any inconsistencies and/or missing functionality.

5. Integration With Related Projects

On large projects, there may also be a need to:

  • Integrate the needs of related projects as well as
  • Integrate the needs of a number of different stakeholders to produce an overall solution.

Overall Summary

The key point is that if a Business Analyst is involved at all in an Agile project, he/she should add value in some way.

  • He/she should not be just an intermediary between the development team and the business users and stakeholders
  • The role should not be limited to creating requirements documents

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Agile and Corporate Culture – How Do You Make it Work?

It’s important to understand the relationship of Agile and corporate culture.

  • Adapting an Agile development process to a corporate culture can be a very difficult thing to do. Especially if it involves changing a well-established corporate culture
  • If you ignore this problem and implement an Agile development process without attempting to integrate it with the overall business environment, it’s not likely to be totally effective
  • Some people think that you have to force the whole company to be Agile in order to adopt an Agile development process. I don’t believe that is the best solution in many cases.
  • A company’s culture should be designed and optimized around the business and markets that company operates in
Agile and Corporate Culture

Value Disciplines

One of my favorite books on this subject is “The Discipline of Market Leaders” by Treacy and Wierzema. It identifies three primary “value disciplines”

Value DisciplineDescription
Operational ExcellenceCompanies who focus on “Operational Excellence” succeed or fail by offering products and services more efficiently than their competitors can offer them.
McDonald’s and Walmart are examples of companies whose primary value discipline is operational excellence. They do the same thing repeatedly at a low cost; that is what “operational excellence” is and it is reflected in their culture.
Product LeadershipCompanies who focus on “Product Leadership” succeed or fail primarily by innovating products to meet market needs faster and better than their competitors.
Apple and Samsung are examples of companies whose primary value discipline is product leadership.
Constant innovation is very important to these companies and they might be dominated by engineers who wear jeans and sweatshirts to work.
Customer IntimacyCompanies who focus on customer intimacy succeed or fail primarily by providing a high level of personalized service to their customers relative to other competitors.
Ritz Carlton Hotels is an example of a company who is driven by a culture of customer intimacy.
Their employees are trained that customer needs and customer service always come first and their processes need to be flexible to adapt to customer needs.

The idea of value disciplines is that:

  • A company can’t be deficient in any of the three areas; however, no company can be all things to all people. The company needs to choose one value discipline as the primary area of focus to excel in.
  • The value discipline that is chosen as the primary competitive differentiation tends to define the whole company and its culture and values

Alignment of Values and Corporate Culture

How do these value disciplines align with an Agile development approach?

Product Leadership

  • Obviously, the Product Leadership discipline has a very strong alignment
  • Companies who are in a business that demands Product Leadership will have little difficulty in adapting to an Agile development approach
  • In that type of company, there is a natural alignment with the primary success factors in their business.

Operational Excellence

Operational Excellence is probably the one that is most difficult to align an Agile Development approach with. In these companies, there are several alternatives:

Ignore the Misalignment

One option is to ignore the misalignment and just implement Agile as a development process without attempting to align it with the business. That’s not likely to deliver optimum results, in my opinion.

Force the Company to Change It’s Culture

Another option is to attempt to force the company to change its culture to be more Agile. That may not be successful either and also may not be the best solution for the company’s business.

Develop an Adaptation Layer

Finally, you might develop an “Adaptation Layer” between the Agile development approach and the company’s business environment.

  • This approach is probably the most practical and most likely to be successful in many cases
  • It might consist of putting a thin plan-driven “wrapper” around an Agile development approach to integrate it with the company’s business

Check out this article for more on developing a hybrid approach:

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What’s the Right Level of Detail in an Agile User Story?

Questions frequently come up about “What’s the Right Level of Detail to Put in an Agile User Story?” – I want to share some thoughts with you on that subject. There is no absolute right/wrong answer about how much detail a story should contain – the best answer is “it depends”.

Level of Detail in an Agile User Story
An intelligent elegant business person sitting at a desk and working with drawn empty text bubbles, boxes around him concept

Level of Detail in an Agile User Story – What Factors Effect the Level of Detail?

The level of detail in the story depends on a number of factors including:

  • The complexity and nature of the story itself
  • The level of interaction available from the Product Owner to explain what is required
  • Where the story is in the overall lifecycle – there are at least three levels of detail required depending on how you plan projects, releases, and sprints:
Project-level PlanningLeast detailed, suitable for very high-level project planning
Release-level PlanningMedium detail, enough detail to do story point estimates
Sprint-level PlanningMost detail, suitable for actually starting development and planning development tasks

Level of Detail in an Agile User Story – Some Recommended Guidelines

Here’s what I recommend as some guidelines:

Err on the Side of Less Detail

It is always best to err on the side of less detail rather than more detail as a starting point – Agile has a concept of “Just Barely Good Enough” which means you put a sufficient level of effort into the task to accomplish what is needed and nothing more – anything more than that is waste

Use Top-down Functional Decomposition

Use a top-down, functional decomposition approach to start at the top-level to identify epics and story titles only. Once that is done and approved, write the actual stories, but only to the level of detail required progressively elaborate the level of detail in stories:

  • Rely on the developers and others on the team (QA) to tell you when the story is good enough:
    • A lot of collaboration and face-to-face communication is essential
    • We need to get away from the Waterfall approach where a BA writes detailed requirements (stories) and then hands those requirements off to developers

Overall Summary

Again, the key thing I want to emphasize is that there is no right/wrong answer about how much detail a story should contain.

  • Some general guidelines and models can be developed to guide the effort, but
  • The real test of whether a story is well-written or not is based on feedback from the people who have to use the information in the story for whatever purpose it is intended for (estimation or development)

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Overcoming Misconceptions About Agile Teams

There are a lot of misconceptions about Agile teams. There is no doubt that “Agile is a team sport”, but have you really thought about lessons learned from team sports that can be applied to Agile teams?

Misconceptions About Agile Teams
A rugby scrum pushes against each other

Many people have the view that an ideal Agile team is a team of peers where there is no specialization among people on the team, everyone on the team is capable of performing any role, and everyone on the team is also responsible for everything. That’s a very idealistic view and may not be the best way for Agile teams to work. For example:

Misconceptions About Agile Teams – Level of Developers

Is it inconsistent with Agile for a more senior-level Tech Lead to provide direction to other more junior-level developers?

  • My experience in the real world is that you don’t often find teams who are all peers and it may not be practical or cost-effective for a company to staff a development team with all senior-level people who are all self-sufficient.
  • The key thing is that you can have people at multiple levels of proficiency on a team without creating a formalized hierarchical structure that inhibits individual productivity and initiative.

Misconceptions About Agile Teams – Teamwork and Specialization

Is it inconsistent with Agile for individual people on the team to have defined roles like QA testing and does that limit the ability of the team to be cohesive? Think of a football team – each player has a role that he specializes in and is good at that role. A football team probably wouldn’t be very good if there was no specialization and everyone did a little of everything.

  • The center might be a 300 pound gorilla and might be very good at blocking and tackling, but he may not be very good at throwing touchdown passes.
  • Imagine the 180 pound quarterback attempting to play on the front line and blocking and imagine the 300+ pound center attempting to play the role of the nimble quarterback throwing passes.
  • Specialization on a team doesn’t preclude developing high-performance teams with very cohesive teamwork.
  • Having someone on a team who is skilled in QA testing and is specialized in playing that role is a lot different than having a separate QA group outside of the development team who specializes in QA testing.

Misconceptions About Agile Teams – Defined Individual Roles

Some people seem to think that having well-defined individual roles and accountability is inconsistent with having overall team accountability – shouldn’t everyone on the team be responsible for everything?

  • Think of a football team again – everyone on the team, as a whole, is responsible for winning; but what if everyone on the team just ran around without defined roles that they were responsible for and without defined plays trying to figure out what to do to get the ball across the finish line?
  • It wouldn’t be very likely to be a very high-performance winning team. Teams where “everyone is responsible for everything” and there is no individual accountability for anything are not likely to be very effective.

Blending Agile and Traditional Project Management