For many organizations agile adoption has brought disappointment to whoever is involved in such transformation. I can recall a project several years ago when senior management did not want to hear the word agile any more because of mediocre projects’ performance.
Jean Tabaka in her keynote in Agile, Australia 2009 titled TWELVE Agile Adoption Failure Modes, has given a road map of 12 failure modes which can contribute to failure of agile transformation. In Tabaka’s view Agile doesn’t fail instead an adoption failure mode gets in the way of adoption. I agree with this statement.
In my view, before agile we were not really doing any specific methodology, even Waterfall. The reason is that we tend to back off when it comes to point of commitment, when we are required to do what it takes to reap the real benefits from implementing the methodology or framework.
In same line of thought, whether we are transforming to RUP, ISO, CMMI, Waterfall, Lean or Agile we can fail because of not doing what it takes to make the framework useful.
In contrast to other frameworks, Agile has been designed to address experimental endeavors where the solution is unknown, requirements are yet to be discovered and sometimes even the real problem is to be defined.
I believe that this shift from deterministic mentality to experimentation is the mind-set needed to avoid the 12 adoption failure modes of Agile. This is in line with what Tabaka said “Agile did not really fail but a failure mode got into the way of Agile”.
I believe that all these modes are critical for any organization to understand irrespective of its Agile adoption stage. While I am listing the titles of these modes below, I added my own reflections in addition to what I learned from Tabaka’s keynote.
1.“Checkbook commitments” from executive management
- Enforcing Agile from top down to get the improved results.
- Management is eager for the results without doing what it takes to achieve them.
- Agile is silver bullet!
- Management does not understand the experimental nature of software development and IT projects. Similarly, the road to become Agile is neither linear nor deterministic.
2.A culture that does not support learning
- Governance bodies in the organization (e.g. PMO, architecture, and others) are enforcers instead of being enablers.
- Instead of enforcing best practices, organization should ask teams to provide what practices work for them.
- PMO still requires big upfront plan and ignores the exploration inherent in the projects.
- Organizations should promote knowledge creation and organization learning instead of enforcing working standards which limits innovation abilities of practitioners.
- Apply the SECI model of knowledge dimensions attributed to Nonaka, instead of having rigid work standards which are not helping engaging the practitioners.
- Instead of building standard process, the organization would rather benefit from having work agreement among the various groups involved in the delivery. An example of work agreement can be QA department should provide testers throughput the whole duration of the project starting from product backlog creation.
3.Ineffective use of the retrospective
- This failure mode can prevent the organization from recognizing where it stands and what it needs to do in-order to succeed with Agile. In other words, doing effective retrospective can expose the rest of failure modes and help in acting on them.
- Failing in retrospectives can have the following forms:
- Do not have any retrospectives at all.
- Scrum master ignore opinions of team members during retrospective sessions, therefore the outcomes are not owned by the team.
- No action plans coming from retrospectives and therefore retrospectives as are still non effective.
- Norman Kerth has put Anatomy of retrospectives which can be effective in reminding us of what it takes to have good retrospective sessions.
- Retrospective session should be data driven and follow effective conservation to arrive at new learning. The ORID technique explained in this document should help in structuring effective retrospectives.
- Rolling up decisions from retrospectives every quarter or so can serve to obtain management backing on those decisions and extend them horizontally through the organization.
4.Failure to pay attention to the infrastructure required
- We will not attain the business benefits from Agile without becoming Agile in the first place. But becoming Agile needs investment in Agile tools, Engineering tools (e.g. Continuous Integration and Test Automation) and other required infra-structure.
- From my view a key infra-structure is a training program targeting various categories of users at various management levels. This program will not only cover education on Agile practices but also enforce the mind-set of being Agile which can create the critical mass needed to affect the transformation.
- An observation about tools is they can be implemented in way not helping in Agile adoption. An Agile project management tool can be implemented a way similar to traditional project management, for example.
5.Inability to get everyone in the planning meetings
- In this mode we assume that we do not need to have all team members for release planning as example.
- Not having some members in the room can delay making decisions which are contingent on those people. Waiting is waste according to Lean Thinking.
- In addition, providing a plan to non participating team member is a reverting back to command and control mentality. Since this means people receive directions (plans) while not participating.
- We ignore valuable interactions which can create new insights and knowledge as advocated by Nonaka above. It deprives the organization from the chance of social interaction as discussed in Nonaka model which is precursor for the converting this knowledge to become explicit.
6.Unavailable product owner, or too many product owners who can’t agree
- The product owner provides product vision and direction. Therefore, if this role is ineffective we can have ship sailing without a radar.
- Unavailable product owner:
- This means team members may not get answers timely to their questions. This waiting is a waste which can impact project outcomes.
- Too many product owners:
- This leads to conflicting direction which will leave the team not knowing what to do.
- This scenario is common because there are usually diverse interests from many users in the product.
- Instead of limiting commitment to the team only, the product owner should commit too with the team.
- Being able to set product direction within the diverse interests of stakeholders in the product is just demonstrating how demanding the product owner role can be.
- Scrum master should be facilitating instead of dictating. This role when created was intended to educate teams on Scrum process and help them in its implementation.
- Dictating on the team reduces interactions and knowledge generation. Also, it is a form of command and control which can create adverse impact on its team members by lowering their IQs.
- Removing impediments needs strong communication skills and understanding of the organization so that the Scrum Master can influence actions which increase team agility. Essentially, team agility can be impacted by organizational impediments which the Scrum Master can serve to remove.
8.Not having an onsite evangelist for remote locations
- Organizations are normally geographically dispersed. Adoption of Agile requires evangelist who supports people and renew the promise of becoming Agile.
- A firm believer in Agile who also understands the organization, the Agile evangelist can be key to avoid remote locations from reverting back.
- Though listening is important skill of an Agile coach, it can be more important for evangelist. The reason for that, he can be in many scenarios where Agile implementation is at risk and his listening skill and appreciation of people problem would help in maneuvering and follow Agile approach.
9.Teams lacking authority and decision-making ability
- This mode is a result of command and control mentality and is entrenched in many of the above modes, for example mode 7.
- Motivating teams is about self-direction, self-mastery and having sense of purpose,
- We need to empower teams instead of leaving them to deal with red tape around them.
- Empowered teams amplify learning and generate knowledge through interactions to create meaningful new knowledge that is explicit and which contributes to organizational learning. This is in contrary to enforced work standards which can serve to demoralize teams and which can become out-dated.
- In short amplifying learning learning leads to high performance. Team retrospective is forum for generating new knowledge and therefore increasing team performance.
- We should leverage teams by appreciating Tuckman’s stages of group development model of Forming, Storming, Norming and finally Performing.
10.Not pulling Testing forward into Definition of “Done”
- Agile projects require that we create software which is working according to the Definition of Done in every iteration.
- Omit testing from Definition of Done means the accepted software during sprint review demo is still need to be tested. Accumulating non tested functionality then test them later enlarges batch size in front of testing which can:
- Force tester to work beyond their WIP limit
- Increases cycle time because is directly related to batch size
- Increase defects and technical debt because of the build up of non tested functionality
- A common problem in Agile testing is what testers are going to do during early iterations while developers are still creating code. This is perceived by command and control management as under utilization of resources. Avoiding under utilization by involving testers late will create technical debt as explained in the previous point. In other words having lower utilization while being able to discover defects early is the favored approach.
- A key measurement of success in Agile adoption is how many defects are coming out from every iteration. Good news we can have NO defects in early iteration by not testing, but the bad news this is a misuse of this metric. At later iteration we probably will have burst of defects and need of rework. This can lower team velocity which was expected to improve due to being at a later iteration.
11.Continuing to rely on a performance appraisal system
- Appraisals reward individual heroics who multi-task without being able to complete meaningful work in full. Those heroes usually have many tasks tied to them which can not be worked on by other team members.
- Multi-task is considered as a common strength in traditional appraisals. Agile is about doing tasks in full according to Definition of Done. Having partially complete work is harmful because:
- Partially complete work is another type of waste according to Lean Thinking
- There are normally defects entrenched in partially done work, therefore it will increase length of time between defect injection and its detection.
- Team rewarding is better approach which rewards overall team performance.
- I like the story Tabaka has mentioned about a professor who gave “A” grade to all his students just on one condition that each one sends him a report explaining why he deserves an “A”
12.Reverting to form, embracing the evil we know
- Change is hard and we most probably going to face storms during our adoption journey. Reverting to previous process can happen as waves become higher.
- When storm blows, instead of returning to where we had been, look again at the above failure modes. You probably will find some of them are manifested and require attention instead of backing of.
- Proactively addressing the previous 11 failures can reduce the severity of the situation and therefore helping Agile adoption to survive.
I see the above failure modes are highly related and one of them can amplify any of the others.