Successful Agile adoption programs deliver productivity gains of 2X or more, while dramatically increasing the timeliness and quality of deliverables. Those who don’t be believe in free lunches know that results of this magnitude do not come from reading a book or taking a two-day class alone. Ultimately, a sea change in what were prevailing attitudes and the displacement of deeply-embedded limiting behaviors by new ways of working together will also be necessary for the Agile change initiative to provide lasting value. Agile adoption programs can definitely benefit from the use of proven organizational change management practices, and the more ambitious the change initiative the more important effective change management becomes.
In this post, we will explore how the ADKAR change model can serve as a change management framework for an Agile adoption initiative. A subsequent post will be devoted to Agile adoption and change program management.
The ADKAR change model
Prosci’s ADKAR change model describes the necessary phases for an individual to adopt a permanent change in their behavior and attitudes. Prosci’s approach to organizational change management is to first recognize that for an organization to successfully change, all individual stake holders must individuallytransition through each step of the ADKAR change model. The point is not that teams and organizations don’t have needs or concerns that are separate and distinct from the needs and concerns of individuals, but that we should never lose sight of the fact that those teams and organizations are comprised of individuals that need to make individual commitments to change, if change is to endure.
ADKAR, the name of the change model is an acronym of the five phases of change:
The model states that all five phases must be experienced and take place in the proper sequence or change will not endure.
First there needs to be an Awareness of both the need and possibility of change before any actual change can occur. Secondly, individuals must Desire or be motivated to participate in the change. Thirdly, individuals need to have the Knowledge of how to implement change in their environment. Fourthly, individuals need the Ability to enact change by applying the necessary skills. Finally, the change needs to be Reinforcedwithin a supportive environment.
Change management tools for Agile adoption
Prosci recommends a variety of tools that organizations can use to help individuals migrate through the ADKAR model, while meeting the organization’s change objectives. Today, we will discuss some of the tools that we use at SolutionsIQ that have proven especially effective for Agile adoption. These tools are designed to help Agile practitioners make lasting commitments to first learn and then continue using agile practices.
Training. Training services are typically no longer than a few days. Training is designed to introduce students to the principles and possibilities of Agile techniques. This includes definitions of terminology, descriptions of problems and solutions, and demonstrations of practices. From an ADKAR perspective, training is focused on the early phases. Developing awareness of Agile practices and fostering desire to use them is the principle objective.
Workshops. Like training, workshops are brief and have similar learning objectives. The chief differences are that workshops tend to be more focused on single topics and more tailored to a client’s specific project or program needs, and often involve performing real work. For example, a story-writing workshop would typically involve the client team and use the client’s own product backlog. Since the workshop is practically applied and less theoretical than training, there is more emphasis on knowledge and ability.
Coaching. Coaching is longer term than training or workshops, ranging from several weeks to months. Its principle purpose is to enable practitioners (usually in a team context) to develop the skill and confidence they need to use agile practices autonomously within their normal work environment. Coaching is more focused on the later ADKAR phases, especially knowledge and ability.
Embedded (experienced) practitioners. Embedded practitioners that join the team temporarily or permanently teach by example, demonstration, and pairing with other team members. Embedded practitioners demonstrate mastery of agile practices within a real-world context. Although their primary mission is production, they also accelerate the team’s education, since (team-directed) continuous learning is inherent to Agile practices. From an ADKAR perspective, embedded practitioners enhance ability and reinforce earlier learning.
The chart below shows how the agile change management tools correspond to the ADKAR change model:
Different tools are used at different ADKAR phases because the needs of individuals changes as they migrate through the model. Also, the tools overlap the ADKAR phases so that when used together an extra level of assurance is obtained that individuals are comprehensively supported throughout the entire change initiative.
ADKAR and Agile adoption — an illustrative example
The following example illustrates how different adoption tools play different roles as individuals migrate through the ADKAR change model.
Training – Bill, a software developer, hears about agile estimation in a two-day Scrum Certification public training class. The class learns that agile estimation is used to obtain a team commitment to the sprintand efficiently obtain a “good enough” estimate.
Day 1: Bill has some awareness of agile estimation.
Bill begins to develop a personal desire to try this new technique that he learned about in the public training class. However, the developer has doubts that he or his team will be allowed to do this or if everyone on the team will cooperate. However, the development manager and the project manager, who also participated in the public training, announce that his team will immediately adopt this practice and they are now required to do it.
Day 3: Bill has some desire to adopt this technique and his organization is providing some support but there are real doubts about others on his team (some of which did not attend the public training).
During the public training class, they did an agile estimation simulation using planning poker. The technique was simple to learn, but when the team tried using it they ran into several problems:
- Not everyone spoke up, and the vocal minority that traditionally dominated estimation discussion continued to do so. Less vocal parties became passive and individually non-committal.
- There were frequent large variances on estimates within the team, but no consensus emerged on what the correct estimate should be.
- Discussion continued forever speculating on what the story was actually for, without resolution, and the planning time was consumed without completion of the estimation task.
- Some of the stories were huge, taking more time than was available in the sprint.
Day 20: Bill’s current knowledge about planning poker is insufficient to result in the full team adopting this new practice. His disillusionment has diminished his desire to continue trying to use it, and he is starting to conclude that it cannot be successfully adopted within his organization. It is also becoming evident that others on the team do not have either the awareness or the desire needed to obtain the knowledge necessary for it to be successfully practiced.
Workshop/coaching – The company asks an outside consultant to help the team adopt agile estimation (as well as other agile practices).
After the coach introduced techniques that allowed the team to work through the barriers to effective collaboration that had been blocking their performance, planning poker started to work. The coach helped the team confront the issue that, although Bill and some others desired to use agile estimation, some team members (who had not attended training) were not supportive. Over time, the coach was able to facilitate the full team to make the commitment to do the collaborative estimation. In addition, the coach helped them understand that one root cause of their poor results was incomplete and improper user stories. When the novice and untrained product owner agreed to attend an estimation workshop and participate in the biweekly estimation sessions, things began to improve.
Day 40: Bill’s ability to successfully apply planning poker was contingent upon the rest of the team learning how to do it and agreeing to give the practice a committed try. The knowledge of planning poker alone was not sufficient. The ability to use it effectively was constrained by their lack of knowledge on two additional practices: effective collaboration and story-writing. The coach led the team first to awareness and then to knowledge and some ability in these new practices.
After a few sprints, the coach no longer needed to be present during the team’s estimation exercises for the team to successfully complete planning.
Embedded practitioners – After the coach left,the organization asked the consulting company to provide a pair of experienced agile developers to work with the team until their first major release. They not only worked as part of the team to establish team policies for using agile practices, but accelerated the overall team delivery performance. They worked with the team for several sprints after the coach left and, as part of the team, participated in agile estimation, providing a solid working example of how it was done as a best practice in their real-world work environment.
Day 120: When the experienced agile developers ended their engagement, after the successful release, the team was fully capable of applying agile estimation successfully in each planning session, as well as many other agile practices.
Although the tools were applied in an ad hoc manner, in this happy example, there was a good outcome. In retrospect, they probably would have been better off, if the full team took the 2-day training course together at the out start. The coach then would have needed less time to get “everyone on the same page,” and had more time to move the whole team forward.
This team was especially fortunate that they had strong management support throughout the change initiative. They were fortunate that management supported their endeavors:
- Part of leadership attended initial training.
- They willingly made the policy change to adopt the new practice.
- They brought in the coach and the embedded developers to complement the initial training.
- They tolerated initial failure and gave the team a chance to learn.