Tag Archives: kanban


Designing an Enterprise Portfolio Kanban Board

Our EKB (Enterprise Kanban Board) has gone through 5 major revisions over the last year. We started our using a traditional Kanban board to measure flow and on-boarded all work across all departments.

Originally we were tracking projects only and then expanded into tracking MMFs (minimal marketable features) with the goal of figure out our capacity and throughput.

We wanted to get to a state where teams would be able to establish a monthly throughput and them long-term plan accordingly.  What was actually happening was that teams were shoving features into the schedule based on due dates.  So if their throughput was actually 4 features per month but they needed 38 to meet the schedule, they’d cram 38 in “1 month away”.

Over the year it’s been re-built 4 times and tweaked often.  At one point we purposely let it die because no one was getting any value out of it or using it.  One day one of the managers thought it would be great if we could visualize all the releases that were coming up and voila! EKB was re-born and back like a bad rash! Continue reading

Playing Get Kanban with an Experienced Team

One of my most popular posts is “Kanban Isn’t the Point” where I wrote about the four stages of competence and how people may flow through the stages with respect to learning Kanban.

Recently I had the opportunity to run the Get Kanban game with an experienced team that has been using Kanban for quite some time and it was interesting to hear the different types of discussions that were generated compared to when I’ve run the game with people new to Kanban.  Shocking, I know.

At one point in the game, (spoiler alert!!) a situation happens that is designed to have work pile up with the testing team and the whole system grinds to a halt.  Poor testers, always getting beaten.  Anyway, how did the experienced team respond compared to in-experienced teams?

The Response from People In-Experienced with Kanban

– aaaaahhhhh!  look at all the work!!! This isn’t fair!!!! no way!!!!  The response gets worse when the next event happens that makes the situation worse!

The Response from this Experienced Team

– no problem.  The response was the same when the other event happened too.

Notice the black line? That’s flow!

The difference between the two teams is that as soon as the game started, the experienced team looked at the work on the board, the amount of effort required for testing on ALL the cards on the board and the fact that there are only 2 dice (therefore 2 testers) in the testing column, they immediately saw a bottleneck forming and exploited it.

They were focused on flow.  Notice the CFD, you can see they quickly adjusted to focusing on testing right away (the lagging indicator is where the green line goes flat on the left side of the chart).  The black line (delivered stories) is almost perfectly parallel which shows consistant value delivery.  There are no signs of problems due to the 2 testing events because of how the work was managed.

The board when the ‘Carlos’ factor kicked in

The teams new to Kanban are focused on maximizing the work in progress because the theory is that the more you work on, the more you get done.

Other Observations – Experienced Team

  • They counted total effort represented by circles on the story cards and related that to cycle time.
  • They immediately reduced WIP in the ready column by not pulling in more stories even though the game didn’t tell them to.
  • They were fined $2200 for not finishing a fixed date story because their math showed it was more effective to get other stories done that had higher value that would offset the fine.  Obviously in this case there is no damage to the company, in the real world a fixed date could be a legislative change which has more severe consequences.
  • They delivered a story with every roll of the dice
  • They finished all the improvement stories and received the benefit of reduced development and testing time.
  • They worked as a team, considering each team members perspective
  • They use the data on their charts, the data on the story cards, the “trend of the rolls of the dice”
  • They see slack time as a good thing (these guys called it facebook time)….and they tracked it just in case.

Other Observations – New Teams

  • They always pick the highest value stories without considering effort.  That makes the situation worse when the testing problem happens because by that time all the stories in test are high effort
  • They maximize WIP, and in the newest version of the game some teams DOUBLE their WIP limits.
  • They always do the fixed date story and usually don’t talk about tradeoffs of doing stories that have less effort and more value
  • They rarely do improvement stories
  • They ‘flatline’ often in value delivery (not delivering value every roll as shown through the CFD)
  • They are very impatient!! The most dominant personality wins and decides the strategy
  • They see slack time as waste…more work could have got done

To be clear, I’m not picking on new people who play the game.  The point is, when adopting any new process the only thing that is going to help people and teams adjust to using it effectively is time.

Over time, experience teaches people how to “see” when looking at a Kanban board.   The reaction to a Kanban board changes from “wow, a wall with sticky notes” to “holy shit!! there is NO WAY we’re going to get all that done!!”

It’s important to remember the 4 stages of competence when bringing change into your organization because progress is going to grind to a halt (or slow considerably) no matter what you do.  Chaotic systems are unpredictable and change brings chaos.   Experience is built by living through the pain of chaos through to integration of the transforming idea into the new status quo.  It’s a natural change process and in order to progress through the 4 stages of competence all you need it time.

Is Kanban Really Less Disruptive?

Kanban is often referred to as an ‘evolutionary approach to change‘.     The approach taken with Kanban is to make visible the current state of the existing process and existing work.  From there flow work through your system, measure it and then look for, and fix, problems.

Yes that is an over-simplification and my explanation isn’t the point of this post.   Many people have written about Kanban being a gentler approach to change because it’s less disruptive and doesn’t ask you to change anything about how you manage work in your organization. Fair enough.

Is it really less disruptive?  If by “less disruptive” you mean “minimal or no process changes”, then yes it’s less disruptive but that is an over-simplification as well.

Making work visible is a huge disruption to an organization if you consider “disruption” being people’s reaction to all of their work being made visible.  What happens when the work is made visible and exposes a bottleneck in development?  All eyes (and fingers) point towards the development manager which immediately invokes a threat response from that person.   The intent is that we expose bottlenecks and deal with them (elevate, exploit etc) but in organizations just getting started with Kanban, the people are not usually at a maturity level where a “no blame” culture has been created.

Making my work visible and making my problems visible can immediately put me, as a manager, on the defensive.  I suppose you could also argue that you can make your management policies explicit before you make your work visible, but that isn’t going to change how people process change and perceived threats.   All the policies and implementing changes in any order has the potential to generate a threat response and that response can be magnified if the organization has a history of using the  ‘rule by fear’ style of management.

That threat response can manifest itself as ‘fight or flight’, a feeling of looking incompetent, a rise in stress level and dare I say it, ‘resistance’!  There are many more emotional responses that I won’t go into.  That’s not the point either.

The point is, you cannot control how people respond to change no matter what process you start with.    Bringing in Agile, Scrum, Kanban or any other process change into a traditional life-cycle organization is a massive change.   The right approach is the approach that most likely flows with the currents in the organization instead of against it.   If you don’t understand those currents, a tool like ADKAR can be helpful.   ADKAR is a model you can use to understand:

Awareness: Are people aware of the need to change? What’s driving the change?

Desire: The desire to support and participate in the change

Knowledge: The knowledge of how to change and what the change looks like

Ability:  The skills needed to implement the change

Reinforcement:  How to sustain the change

Administered the right way, ADKAR can give you data to see where there would be more support for changes and where there may be people who don’t understand why a change is being brought in.  Typically you would call the latter “resistance” but I don’t like that word.  “Resistance” is a surface response, not the problem and the person resisting isn’t a bad person.

For example,  doing an ADKAR assessment and slicing the results by department and by hierarchy will help you develop a change strategy and will put the people involved in the change ahead of the method being used.     Our last ADKAR assessment showed high scores in Desire which told us there was an appetite to change.  The feedback and pulls we’ve received from all areas of the organization is strong validation of that data.

Remember, just because Kanban is called ‘evolutionary change’ or a ‘gateway drug to Agile’ or whatever, change is change.    HR and Change Management understand this, if you have them in your organization, leverage them.   If you don’t, learn about the practices they use and start talking about change management and leave the methodology out of the equation until you have a temperature reading of the organization.