With one of our offices in Canberra — the seat of the Federal Government in Australia — I’ve been hearing that a number of departments and agencies have tried Agile, but failed. Unfortunately, some seem to then return to their old Waterfall processes. What, though, it at the heart of the failure of Agile to live up to its potential? When it fails, what is the root cause? What can we do to recover from a failed Agile project, learn from it, and make it a success?
The causes for Agile adoption failure
The leading causes of failure for adoption of agile methods are a lack of experience and a lack of understanding of broader changed required (VersionOne, 2012) in the organisation to support those agile methods.
Of greatest concern is that 13% of respondents to VersionOne’s State of Agile survey just don’t know why their attempts at agile fail. For me, though, this suggests factors akin to “lack of experience” in order to know what worked, what didn’t and why.
Barriers to adoption
When something new is tried, but fails, it’s easiest to return to old behaviours. For others, the barriers outside of the project or program of work are too great. Most struggle in getting the wider organisation to understand the changes needed to support an agile project, but for others, a general resistance to change and lack of management support are the primary reasons why agile adoption simply doesn’t work or doesn’t go ahead.
Challenging resistance to change
Understanding readiness to change is an important consideration, but not everyone or every project is going to be at the same state of readiness. Having a check-list in Q&A format can help increase transparency regarding the rationale for resistance and assist establishing an action plan for addressing that resistance. An understanding the science of change — human cognitions and behaviour — is vital factor in effectively addressing the resistance to changing to an agile method.
Pre-contemplation stage
Goal: a project’s owners will begin thinking about changing methodologies.
- “What would have to happen for you to know that using Waterfall has its problems?”
- “What warning signs would let you know that Waterfall has its problems?”
- “Have you tried to change in the past?”
Contemplation stage
Goal: patient will examine benefits and barriers to change.
- “Why do you want to change at this time?”
- “What were the reasons for not changing from Waterfall?”
- “What would keep you from changing to a specific Agile method at this time?”
- “What are the barriers today that keep you from change?”
- “What might help you with that aspect?”
- “What things (people, programs and behaviours) have helped in the past?”
- “What would help you at this time?”
- “What do you think you need to learn about changing to an Agile method?”
An adoption check-list
Given a lack of experience with agile methods is one of the primary factor in why agile doesn’t work and fails, then finding that experience is an important first step toward success. This a agile experience is best found in a coach — an experienced agile practitioner in the methodology you want to adopt (e.g. Scrum). They should also have experience in introducing the agile methodology into a project through way of coaching a team, transferring their knowledge to the team, to management and internal stakeholders. Your coach should then help prepare a check-list for adoption explicitly addressing any resistance to change, including:
- Addressing organisational concerns about adoption of agile methods through explicit communications strategies.
- Improving awareness of the benefits that agile methods can deliver over traditional Waterfall methods by creation of an action plan.
- Reducing the risk for adoption and improves the chances of success by setting goals and pragmatic learning processes for the team’s project to achieve them.
At a high-level, Zen Ex Machina’s check-list address these issues through creating the following action plan:
| Issue | Zen Ex Machina’s Action Plan for Successful Scrum Adoption |
| Availability of personnel with right skills | Engage a Scrum Coach. |
| Ability to change organisational culture | Use the ‘Start Small‘ pattern of adoption so any change required is small. |
| General resistance to change | Be public about the adoption and limit it to a single project. Labelling the project a ‘pilot’ provides psychological cushioning that change will be needed, but with minimal impact. |
| Management support | Address concerns about adopting agile, including lack of documentation, predictability, scalability, time to transition and budget through robust, transparent, reporting mechanisms.Establish how Scrum will align with existing governance, reporting, and management processes such as PRINCE2. |
| Project complexity | Choose a high-value project with a medium over high-level of complexity. Demonstrate how Scrum’s processes break-down complexity so that requirements are more easily managed and implemented. |
| Confidence in ability to scale | First, start small and understand and address those issues on a small scale, slowly scale to larger, more complex projects with in-built, transparent learning on how to adapt.Publicly communicate victories and enable the team to talk to others about their experiences through leveraging internal channels, such as intranet, blogs and Yammer. Do research on how patterns like a Scrum of Scrums could apply to your organisation. |
| Collaboration | Scrum’s language can be a barrier to communication and collaboration.Describe the opportunities for closer collaboration that are available rather than focus on terminology and dogma.Establish a governance framework based on best-practice RACI-VS. |
| Perceived time to transition | Set an agenda for the Scrum Coach to embed his knowledge in a 3-month timeframe. |
| Budget constraints | Even with a Scrum Coach, the overall net costs for transition in a ‘Start Small’ project should aim to be zero. |
Getting started after failure
We know from quit smoking programs and dieting fads that most people give in to their desires and fall off the proverbial wagon [1] — it’s just human nature. Learning from methods outside of project management, like behavioural and cognitive psychology, provides us valuable insight into failure and how to respond to it:
- Don’t get back on the horse, just get on a different one — We’re taught to get back on the horse when we fall off. Einstein however, defined insanity as trying the same thing and expecting different results. The main thing to remember is to change goals and try something different. If you’re one of the 18% who don’t know what Agile method you tried, and you failed, then try a specific methodology like Scrum. Scrum is the easiest to learn because its framework has few processes and few rules. Being disciplined in sticking to those rules is the key to success with Scrum and a vital role of a Scrum Coach.
- Communicate an expectation of failure — Accepting that failure is a natural part of learning and the process of success sets the expectation that failure is just a step backwards. Have a risk mitigation plan that takes account of failures and learns from them in sufficient time to steer the project back on track. Scrum has built-in processes to take account of these issues. Having a Scrum Coach will also help shed light on failures so you can stop making the same mistakes later. A good Scrum Coach, though, will help the project identify issues, and allow them to make mistakes so that they learn from it, as it’s only from our mistakes not our successes that we truly learn [2].
- Don’t be afraid to ask for help — Having the right governance framework, one that is designed to support the project rather than punish it, is vital to success. Using a RACI-VS framework embedded into a PRINCE2 project control process for escalation of risks and issues is vital. Understanding how these pieces fit together is an important job for your Scrum Coach to collaborate with your Project Manager during project initiation.
M
– – – –
1. Zimmerman, G. L., Olsen, C. G., and Bosworth, M. F. (2000) A ‘Stages of Change’ Approach to Helping Patients Change Behaviour. Am Fam Physician. 2000 Mar 1;61(5):1409-1416. Online at: www.aafp.org/afp/2000/0301/p1409.html
2. Halber, D. (2009) Why we learn more from our successes than our failures. MIT study sheds light on the brain’s ability to change in response to learning. Online at: web.mit.edu/newsoffice/2009/successes-0729.html
