9 ways for Agile to go wrong

The other side of the Corporate Executive Board’s latest paper

We’ve worked with the Corporate Executive Board (CEB) before – jointly creating the Roadmap for Agile Success. Reading their latest paper that details the findings from the initial roadmap survey, 11 Steps for Getting Value from Agile, I was struck by the connection between their advice and our experience over the years and more recently in a number of project audits. You might call it the dark side – the problems we discover when Agile has been implemented poorly.

It made me think there was some benefit in presenting things this way round. Positive advice can sometimes feel frustratingly facile. Yes, of course, we all intend to collaborate. Few companies set out to intentionally divide themselves into cliques and groups, and yet that’s exactly what happens. So as a kind of counter-part to the CEB’s excellent advice, here is my guide to common problems – and steps to take to avoid or correct them.

1. Agile has been introduced in a pilot team only. Although it seems to make sense to trial a change, if there is no plan for roll-out then the Agile team gradually becomes isolated, setting up unnecessary barriers within the applications process. By contrast, where the whole organization is more Agile, with greater involvement from stakeholders, individual projects and the portfolio as a whole perform better.

2. A lack of balance between standardization and anarchy. Iterative development requires a level of flexibility. This means that top-down command and control management will stop teams being able to adapt the process as the unique conditions of their work require. Equally, however, a complete ‘free for all’ means unnecessary variation, stopping easy collaboration between teams and making it harder for people to move from one team to another.

3. Companies try to run two processes in parallel. Agile is by its nature flexible, concentrating on speed and predictability, not certainty. Companies that try to overlay traditional project management control of schedule and budget simply end up causing waste. Instead, the best project management focuses on managing external dependencies.

4. A lack of rigor in prioritization at a features or requirements level. In order to deliver the most important features early and often, teams should be meticulous about prioritizing requirements on an agreed definition of business value. Many early Agile implementations do not do this at a sufficiently detailed level, leaving it up to an individual product owner to decide prioritization. While this may be acceptable as a start, soon real business feedback should mean reassessment and reprioritization.

5. Failing to ensure customer involvement. Agile depends on close, frequent interaction with the customer. While for convenience a proxy customer or product owner may represent day-to-day interaction, this is no substitute for wider engagement with business stakeholders, real customers or end users.

6. Failing to invest in continuous improvement. This negative behavior can take several forms from a complacency in keeping Agile as a purely ‘development’ activity to allowing initiatives in sponsor involvement and shared project ownership to stagnate. Whatever the symptom, the result is that early gains falter and are not replicated or improved. Specifically team skills, excellence in engineering practices and deployment are all skills that require investment and development.

7. Not selecting the best team leaders. Many organizations struggle with implementation because they do not pay attention to the particular skills needed for Agile. Instead of recruiting or investing in skill development, they select project managers or developers with little experience in Agile or highly collaborative ways of working. Without leaders who understand the business value of Agile and act both as advocate and demonstration as Agile values, a successful implementation becomes highly unlikely.

8. Dissipating success. Teams require time to become high performing; they learn trust and gain experience as a collaborative group. Despite this, companies often throw away success by splitting up teams after every project. Even when co-location is not possible, it tends to be better to keep high performing teams intact, but include formal processes to mentor new developers and other teams.

9. A final problem was not mentioned by CEB, but is key in our experience: what measure is used to signify success. For many organizations, the measure of success is ‘adoption rate’. They probably decided on an Agile roll-out because they wanted to be faster or improve quality, or any other ‘outcome’, but once the process had been selected and defined, they then concentrated on whether all teams adopted the process correctly. It’s no surprise that the results are often disappointing.

Successful organizations remain focused on the outcome both for customer and the business. They introduce practices and techniques to improve on the overall outcomes rather than getting hung up on specific methodology. This permits adaptation to the complexities and realities of the operating environment. They measure success against these outcomes, and thus remain far better focused on the ideal of continuous improvement.

Related content