Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

4 Reasons Your Agile Implementation Isn't Working

DZone's Guide to

4 Reasons Your Agile Implementation Isn't Working

Agile implementations may be disappointing due to failure to limit risk, long lead times, consistent cost-overruns, and the fact that no one knows why you do what you do.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

I see four common reasons that Agile implementations don’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 the fact that 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.

1. You’re Not Limiting Risk

A general adoption of Agile ideas, frameworks, and tools has 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 changing conditions, cost overruns, missed deadlines, quality, security, and something being unfit for purpose or disliked by customers.

You may be using Scrum, Kanban, XP, SAFe, etc., but that doesn’t mean that you’re appropriately protecting yourself from these risks. If that’s true, then you’re limiting the benefits you receive. Traditional SDLCs were designed to mitigate risk. Project managers serve a major role in ensuring that 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.

Too 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 the risk of building the wrong thing.
  • Poor visibility into team progress can cause cost overruns.

2. Long 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 that 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 three-month regression test was the norm. Any change, no matter how small, would cause a three-month manual regression test to get to production. If you have long lead times, you’re not getting the full benefits of agility.

3. 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 and instead build component teams that feed one another in a dependency chain, you increase the time to first value. There’s no guarantee that 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

Let’s redefine agility: 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 that 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!

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

Topics:
agile ,agile transformation ,career

Published at DZone with permission of Robert Pieper, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}