How deep is your Kanban (or Scrum)?
Exam by Alberto G. on Flickr, cropped, CC BY 2.0 DEED Attribution 2.0 Generic
One of the great challenges of adopting an Agile methodology, Kanban, or similar approach, whether for development software or other type of work, is evaluating how you are doing and what to improve. Also challenging is understanding how well you are improving (or not) over time.
Beyond built-in ceremonies used to solicit improvement feedback, there are some evolving methods of self assessment that may be useful to generate feedback on the depth of your implementation. Through such an assessment, you or your team will likely find a different view of your implementation that will inspire change.
How Are We Doing?
In my occasional role as a "coach" teams would often ask how they were doing compared to all the others out there. Many individuals attend user group meetings and participate in online communities getting ideas and suggestions from others. These teams would retrospect and perform other activities that generate ideas on how they could make things better. But still there was often curiosity... "Are we a good Kanban (or Scrum) team?"
Sure, Scrum teams (and many Kanban teams) have their retrospectives, Kanban teams may have operations reviews, and done well these help identify ways to incrementally improve. Over time we can look at metrics like cycle time to get insight into improvement.
Maturity Models
Maturity Models are a popular idea. You can search and find various proposals for an Agile Maturity Model. There are also those who question them or question maturity models in general. I tend to share concerns about measuring an overall maturity level due to the tendency to oversimplify and not recognize when there are elements of good value in the current implementation.
Outside Assessment
This type of assessment is often performed by an Agile Consultant. While they can be based on any method (such as a maturity model), they are often custom and involve interviews, questionnaires, and observation resulting in a report and recommendations. I have been a part of these and while they are valuable, they are often performed without deep understanding of the team's context.
Assessing Depth
A number of people have been looking at a variation of assessment that focuses on depth of the implementation. These assessment approaches tend to be multidimensional as well as relative and used as a tool for a team and coach to guide improvement.
Borrowing from the often used iceberg metaphor, many adoptions focus primarily on some surface practices while glossing over or ignoring aspects of the approach that provide depth and are not easily seen. A depth assessment tries to highlight what areas are possibly too shallow and may benefit from developing greater depth of implementation.
The first of these that I encountered was a Depth of a Kanban tool described by Christophe Achouiantz and based on work by David J. Anderson, Håkan Fors, and others. I found that this approach requires more coach guidance as a team without deep understanding of practices and outcomes may have trouble assessing themselves in some areas. The descriptions linked to here even describe it as more of a coaching tool. The result is a ranking of depth in each of the core practice areas of Kanban (and a desired effects dimension as well) giving a coach and team areas in which to focus.
More recently, Mike Burrows, author of Kanban from the Inside created values-based depth assessment for Kanban that focuses the dimensions and questions on Kanban values instead of practices. Rather than rating descriptions, he has a well written set of questions that are suitable for spreadsheet or survey tool to collect ratings from the whole team.
The result is a ranking of depth around values, meaning the team might focus more on improving Flow and Customer Focus than on just Limiting WIP or Making Process Policies Explicit. Mike is building on his values-based assessment and other work through his new company, Agendashift.
For Scrum teams there are similar self-assessments I have seen described:
- James Shore described a self-assessment in The Art of Agile Development that even has an online version
- Mario Lucero describes a Scrum Team Self-Assessment
Give Yourself Some Feedback
I'm still experimenting with the use of depth assessments and intend to follow up with an experience report in the future. I encourage you to take a look at some of the options mentioned here and try yourself (or with your team).