I see four common reasons an agile implementation doesn't get the benefits hoped for. These reasons include a failure to limit risk, long end-to-end delivery lead times, consistent cost-overruns, and no one knows why you do what you do. Are you in this situation? Read on to see if these match up to your current situation.
You’re not limiting risk
General adoption of agile ideas, frameworks, and tools have happened. In my experience there are few organizations deriving the maximum benefit by embracing agility as an organizational goal. Baked into agile frameworks is risk mitigation. Risk comes in many forms, but the most common include:
- Unfit for purpose
- Customers don’t like it.
- Changing conditions
- Cost overruns
- Missed deadlines
- Quality
- Security
You may be using Scrum, Kanban, XP, SAFe, etc..but that doesn't mean you’re appropriately protecting yourself from these risks. If that’s true then you’re limiting the benefits you receive. If you look to traditional SDLCs, they were designed to mitigate risk. Project managers serve a major role in ensuring risks are mitigated and dealt with appropriately.
When it comes to change and flexibility, traditional SDLCs usually go too far with control and do more harm than good. It's not that waterfall is bad, it just requires you know with certainty the end state, the time to complete, and the cost to get there. Any change to the plan risks disrupting the certainty in these variables and the happiness of your customers.
In many cases traditional projects increase time-to-first-value, which means delaying the total value achieved over time. The tendency for traditional projects to increase in scope to multiyear efforts adds back in the risk of change while trying to mitigate the risks of everything else. Enforcement of official change requests worsens the tendency toward longer projects since customers want to make sure everything they could possibly want is in scope before signing off to start. The more traditional SDLCs attempt to mitigate risk the more risk they create.
Just because you deliver in small batches doesn't mean you’ve mitigated all risk. For an agile adoption to be successful it must also address the same risks listed above and do as good of a job to mitigate or eliminate them.
To often I see agile shops that don’t adopt the practices as intended. Some examples include
- Low quality because QA is another team
- Security concerns aren't addressed because it isn't in the definition of done (if they have one)
- Lack of involvement from customers increases risk of building the wrong thing
- Poor visibility into team progress can cause cost overruns
Lead time
Plain and simple, it's taking you too long to get an idea into customers hands.
The first thing I’d look for when auditing an agile implementation is the time it takes to go from concept to cash. This is the time it takes for a feature idea to become reality and ready for use by the customer. One has to consider all quality checks, documentation requirements, and anything else necessary to be customer-ready. In some cases, the amount of quality checks involved considerably constrains how much you can shorten lead time. In one company I consulted a 3 month regression test was the norm. Any change, no matter how small, would cause a 3 month manual regression test to get to production. If you have long lead times, you're not getting the full benefits of agility.
Consistent cost overruns
Cost overruns can come from numerous sources and I’ll list a few common ones. If you don’t build cross-functional feature teams, but instead build component teams that feed one another in a dependency chain, you increase the time to first value. There’s no guarantee the downstream teams will be able to use the upstream team’s contribution. To finish a feature, thrashing occurs when downstream teams send work back for fixes to be done by upstream teams. This scenario causes significant delays. The irony here is that component teams are often set up to be more efficient and cost-effective. The results are the opposite. If you have no control over costs, you’re not getting all the benefits of agility.
No one knows why
Do you know why you decided to become agile? Do the teams stand around like robots every day failing to question bad decisions? Does your Product Owner still expect your team to commit to a date including completion of every single item on their list? Why does your business exist and does the team know that? If no one knows why, or even asks, you aren’t getting the benefits of agility.
Conclusion
Has your agile implementation failed? do you want to fix it? First, let’s redefine agile: it's being nimble or light on your feet. If something changes and you can’t respond quickly and cheaply, I’d say you have a way to go before you call yourself ‘agile’. Agile frameworks are designed to help you be light on your feet, but they don’t promise you’ll succeed in using them as intended. That’s up to you. If you’re struggling with the above consider bringing in an outsider to help audit your implementation. It’s hard to see what’s right in front of you when you’re in the weeds of execution on a daily basis.
Any other things you’ve seen which prevent organizations from getting the true benefits of agility? Leave a comment!
Originally posted at responsiveadvisors.com