Agile Depth of Adoption Model: A team-focused approach to tracking adoption of agile practices

As part of an IT transformation initiative, we needed a way to validate the success of our minimum viable change initiatives as reflected on the adoption of new skills and behaviours by the project teams. Our initial approach was through a coach-led evaluation of skills and behaviours, mapped to kanban and agile learning tracks and visualized through character sheets with gamification concepts incorporated.     

This approach turned out to be unsuccessful. The fundamental flaw was that it provided a subjective, one-sided evaluation of acquired behaviours and skills, with no participation from the individuals being evaluated. As we realized this weeks later, we pivoted and changed our approach. We did a road show to communicate exactly what tracks were targeted for certain change initiatives, what behaviours and skills were expected to be acquired, and did a turnaround on the evaluation model to make it a validated self-assessment. And yet, the self-evaluations came back with irrational results and opened up too many unnecessary points for contention in the determination of skill-level adoption. Aside from this, there was very little enthusiasm for the character sheets which we were hoping would serve as visual motivators for skills acquisition. 

Recently, we came across the Kanban depth of implementation model by Hakan Forss and have tried implementing this approach on a couple of teams to cover the Kanban piece. The simple, non-threatening, team-focused evaluation approach has proven to be suitable for the teams and the culture of the organization. Teams were receptive to tracking and visualizing their progress beside their physical Kanban boards. Using the same approach, we came up with an Agile Depth of Adoption Model which incorporates targeted practices in the areas of requirements, planning, design and architecture modeling, as well as technical practices such as pair programming, clean code, TDD, build automation and configuration management. Although a natural adoption sequence can be somewhat implied, we decided to implement it loosely where teams can choose to focus on relevant practices and adopt them in a non-linear way as agreed upon and visualized through their Change Canvas. We are hoping that this non-threatening, team-focused approach to evaluating adoption of skills related to agile practices will be more acceptable to project teams since it is more in line with our overall goal of having self-organizing, collaborative project teams that collectively make commitments and share responsibility for results and outcomes.