Jeff Anderson has a great blog post about using Lean Startup to rollout a large Lean/Kanban transition.  We’re using this on a medium-large Lean/Kanban transition and I’m finding it to help a great deal with focus.  Usually I like to have a ‘transition backlog‘ of items to introduce and then after they get introduced see what changes stick and what don’t.  The difference with using a Lean Startup approach is to identify assumptions with a measurement before introducing the change and then compare the hypothesis with the outcome.

Last week we held our weekly transition retrospective and what seemed to be getting lost was “customer” feedback and not much consideration around pacing of the change.   Adjusting to change is difficult and the people already have day jobs so the more change we push, the more likely it won’t stick and be integrated into the new status quo.  Using Lean Startup in a product or software world is easier to measure.  You can define measurements of application usage, feature usage, behaviour patterns etc.  We’re using it to measure engagement and behaviour of the people affected by the change.  I’m sure some of you probably cringed at the mention of  “measuring people“.    Different people are going to be affected by change at different rates and intensities.   This is what we want to accomplish by measuring the engagement of people in the transition:

• who is utterly lost and why?
• who is eating this change up and why?
• who is suffering from change fatigue and why?
• who wants more change and why?
• are the changes we’re introducing the right ones at the right time and why?

These are a few pieces of information we want which will help us figure out our next set of MVC’s (minimum viable change).   What we’re changing this time around is that we’re giving our “customers” the measurements we’re tracking against.  Here’s a more concrete example, during the first wave of changes we introduced visualizing your work and running daily standups.  We expected to see these basic behaviours:

• people are visualizing all their work
• everyone is participating in the stand-ups
• people are moving work across the board
• people are identifying blockers and issues early

We have more advanced behaviours we expect people to evolve to over time:

• relaying work to and from their own functional kanban boards
• people are facilitating their own stand-up
• team members are jumping in (pinch hitting) to help other team members without being prompted
• functional and pilot teams are modifying their kanban board as they learn more

These are a few examples, the behaviour engine Jeff et al have created is much more substantial.   The reason behind this behaviour engine is, as practitioners, we see people progress from simply attending a standup to actively being engaged in the standup which leads to more “advanced” behaviours as we introduce more advanced practices.  Also, since we all have varying skill and personality differences, someone else may see a behaviour that I don’t see.

As change agents, our team observes and assesses these behaviours so we can figure out which teams need more help than others and how we can introduce new changes or pull back on changes if the teams are over-saturated with new practices.   We are now introducing self-assessments and showing our “customers” what we’re measuring and why.   We are being clear that this “measurement” is not to measure them but to measure our effectiveness bringing in change.  Who knows, they might all hate it or not understand why.  The point is, we want to rely more on “customer” feedback to drive future changes and introducing a self-assessment gives our “customers” more ownership of the change and, more importantly, more context around why the change is happening and what we’re doing to help them transition through it.