When an Agile project gets stuck, what is the best way to determine the cause?
This is a particularly interesting question and exposes a challenging root-cause analysis. I'll answer this from...
the perspective of a sponsor who is funding the team, who expects Agile to be delivering value quickly and incrementally, and who is not seeing this value. Let's examine some root cause analysis methods that can help clarify what's going on.
One of the challenges of convincing an organization to invest in a project run with an Agile process is that generally the cost outlay is predictable but the results are not. A real concern for sponsors is that they will waste their investment. It can be difficult to build confidence that they will have what they need and enough of what they need to justify the expense.
There are two ways that a stakeholder might define getting stuck. Either the team isn't delivering anything or the team is delivering something but what it produces isn't delivering value. A review of a burn-down chart (or burn-up chart, or sticky notes in the "done-done" column of a Kanban board, or the release notes) will reveal if work is not getting completed. Reviewing the key performance indicators (KPIs) -- revenue, user adoption rates, cohort analyses, etc. -- will reveal when value is not being delivered.
These "look at the measures" exercises are a good first step for a stakeholder because they are indicators that a conversation is needed. The need to review these measures also indicates a broken Agile process. It shows communication is not happening when it should. With a working process, stakeholders will be as aware of these issues as the team is -- both viscerally and immediately.
Root cause analysis methods dig a little deeper
When work is not being finished, start with the assumption that the team members are independently capable and that there is a blocker in the process or a collective breakdown. If the team is using a Kanban (or Scrumban) process, look to see if work in progress is piling up somewhere. Perhaps stories have been implemented but are waiting for customer feedback or testing before they can be released. It may be that work on stories cannot be started because design resources are constrained or stories are not "ready;" the code-writing team members don't have the information they need to begin implementation work.
When work is being completed but value is not being delivered, the implementation and delivery process may be working fine, but what is happening is the Agile version of garbage-in, garbage-out. Simply put, the team is being asked to work on the wrong stuff.
The best-case scenario is that the items in the backlog are not prioritized correctly (or at all), and the team is working on the wrong things first. Perhaps they are tackling the most important steps in achieving user goals without enabling users to complete any single goal.
The more frightening scenario is that items in the backlog are not connected to value. Users realize value from achieving goals. Stories are put into the backlog to guide the team to build capabilities that enable users to perform specific actions with the expectation that those actions help them achieve their goals and realize value. Reviewing the traceability that shows how users' activities relate to their goals will indicate if the right activities are being targeted.
The last leg of our root cause analysis
From a stakeholder's point of view there are three avenues left to pursue if the team is still stuck after user goals are mapped to activities and the team is delivering against them.
- Are the hypotheses right? Check that the user goals are correct and that helping users achieve them does realize the value that you measure with the KPIs.
- Are the KPIs valid? Many teams measure what is easy to measure instead of what is important to measure. Even with the right measure, the target value may be wrong.
- Is the delivery good enough? A team can absolutely deliver the right capabilities to users, focused on the right goals that support the right business case and still deliver a product that fails because it is not good enough to gain adoption and succeed in the market.
Each exploration approach leads to different root causes of not delivering value and therefore different solutions. These root-cause analysis methods will get you started down the right path to resolving the problems.
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing.continue reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype.continue reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.