12 adoption failure mode of Agile

 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.

Fail modes 1-6

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.
Fail modes 7-12In 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. 
  • File:SECI Model.jpgInstead 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.
7.Bad Scrum-Masters
  • 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.

2 thoughts on “12 adoption failure mode of Agile

  1. You post interesting posts here. Your page deserves much more traffic.

    It can go viral if you give it initial boost, i
    know useful tool that can help you, just type in google: svetsern traffic tips

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s