Category Archives: Work Systems

ekb-final-2

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.

Why Job Titles are Hurting Your Organization

I am very vocal with my opinion that job titles are stupid. I understand why they exist and I still think they are stupid. I have many examples over the years about why I came to the conclusion that job titles are stupid and the converging theme is because job titles get in the way of progress.

Having said that, I do believe roles are good. Roles help to shape your primary focus based on the work, whereas titles pigeon-hole people into doing one specific type of work.

How many times have your heard someone say “that’s not my job” or something similar?   I’ve worked with developers who have said “I’m a developer, I don’t test“.  The theory behind job titles is that it can create a sense of higher self-esteem and make people feel good and it can help establish what people are responsible for.  It can also be a way to determine how much to pay somebody.

Those can be good things.   Continue reading