Guest Blogger - Kanban Transformation from the Trenches

This post is written by a guest blogger, a client of ours has participated in one of the largest and most ambitious Kanban transformations that I've had a privilege to be a part of.

Elaine Lee (has played the role of both Business Solutions Manager as well as Enterprise Architecture Manager, whose functions have been heavily influenced by the new direction that her organization is taking as a result of taking a lean perspective. We asked for her input on how she felt the transformation was going, what was working well, and what were some of the challenges...

--------------------

  

It's been a little more than 6 months since our IT organization began introducing completely new practices on a large scale.  Early on it started with foundational training and pilot projects, then in what felt like the blink of an eye it evolved into a reality where Kanban boards surfaced on every wall we had available and lingo like "Stand-ups", "retrospectives", "MMF's", "Story Maps", and "planning poker" have become the norm for us.

In retrospect, it definitely felt very hectic at times with the number of changes we made on a daily basis to refine our new processes into something that has now become the right shape and size for our organization.  As painful as it was I think this approach has been a blessing in disguise that's helped us transform as quickly as we have and allowed us to immediately begin living our future state before the concept became stale from 'all talk and no action'.  It has forced us to immediately get used to continuous change and experience what being flexible and agile really means in practice.  The model of theories was short lived for us because we would immediately start using it whether we were ready to or not.  There were flaws with some of the things we did and how we did it, but intentionally or not it has groomed us to constantly anticipate what the next change will be.  Because of that change in attitude, I find we no longer react to change as something bad, but rather as a means to improve something we've experimented with that needs to be made better.

Our new norm is an environment where most of us aren't embarrassed to ask for help with the new. techniques we've introduced.  It's an environment where there is a much greater tolerance for change.  It's an environment where there is a willingness to try and suggest unconventional ways of accomplishing the result.  I'm optimistic that once we are all physically realigned to be collocated with the teams we work with that we will also experience the effects of great collaboration can bring.  I'm happy with what our new norm is and am excited to see how it will further evolve in the future.

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.

Using Story Mapping for Defining Business Requirements

Story mapping is a lightweight and collaborative approach to defining and structuring user requirements. Story mapping involves describing the system as a list of features that provide a sequential story of requirements in a user-centric way. It supports iterative delivery where the story is divided into Features which can be prioritized and grouped by planned Releases/Minimum Marketable Features.

Approach

To come up with a Story Map, start out by identifying user personas or the major categories of users that gain value from the system. Next, identify the business/user goals or the major objectives that the system must support. For each goal, determine the user activities or the sequential events that the user needs to do in order to get value. Finally, break the activities down into explicit system Features that have real tangible business value.

Once the overall narrative of the system is understood, the Story Map can be used to prioritize the Features. For each of the activities, vertical component can be added to define the priority of the features with respect to each other. Each set of Features for a particular user activity are reshuffled and stacked vertically according to their relative priority. The top row of the Features on the story map represent the backbone of the product, which is the Minimum Marketable Features (MMFs) that are required in order to have a functional product. Features that may be delivered later (or sometimes never) are placed lower down.

Once overall prioritization of Features necessary to support each user activity is understood, the entire Story Map can be divided by planned Releases/Minimum Marketable Features. Horizontal lanes can be used to divide different MMFs from each other. The Story Map can then be used to tell a narrative for a particular MMF. This is done by traversing the map from left to right and only looking at the Features within a particular lane.

Story Mapping enables both a top-down and bottom-up perspective of the system to emerge. It facilitates understanding of the system from the users' perspective. It also lends itself to iterative delivery in that prioritization and grouping of Features into Releases/Minimum Marketable Features is supported.