What are our Kanban boards for?

Our Kanban boards act as a Kanban system (important to distinguish this from the Kanban method which means something different).

The Japanese word Kanban literally translates to Signal Card.

By extension of this literal translation, the Kanban system is a ticketing system that allows us to manage the work items.

Real World Kanban system

An obvious example (that I think everyone has heard of) is the Starbucks coffee cup.

OK so we want a coffee and we pop in to Starbucks, queue up and then order a coffee.

The person with the funny haircut at the counter creates Kanban, of a specific work type. That is, they pick up the relevant coffee cup and writes down the type of coffee chosen, the milk type, the extras selected, and name of the customer.

When there is a person free to make coffee, she will grab the next empty cup and make the coffee to spec.

Then there is a guy handing the coffees out to the customers - they pick up the next coffee and call out the name of the customer and hands it over.

Flow V Pull in Starbucks

Now think about what happens when the shop is not busy - we walk in, give our order and it is made immediately - super quick.

If the shop is busy, then maybe the person taking orders will also help out with making the coffee. That means that we might have to wait a little longer between getting our coffee, but we know we will get it soon enough.

This highlights the importance of flow efficiency and how it is better than an environment where we have to pull work items into progress.

"Flow if you can, pull if you must"

Knowledge based teams Kanban Systems

It is similar to how our work should be managed on our boards, however with starbucks there is an extremely important distinction.

In Starbucks the output is a very tangible cup of Venti Vanilla Soy Double-shot Frappucino. The Kanban is attached to the physical output all the way.

We are lucky enough to be involved every day with knowledge based work.

However there is nothing tangible to attach to our work items as they move closer to completion.This is an important distinction.

It means that we should only use the Kanban boards as:

• a communication device
• A tool to manage our work.
• A visual aid to interested parties to the status of the work - a mirror to the state of what our teams are doing right now.

If we have failed to use he board to manage our work cleanly or communicate effectively then we have jumped the shark just like Fonzy!

Flow V Pull in knowledge based work

Going back to the Starbucks example - during lunchtime, Starbucks are forced into a state of Queuing, and that causes delays. In our environment we can try to control that. We want to have flow and increase the efficiency of our working ways

(when I say efficiency, I mean reducing the amount of time our cards are not being worked on. If a card has a lead time of 10 days, and it spend 2 of those days in progress, and 8 days in waiting, then it has a 20% efficiency).

If we have a card with poor efficiency, then it is an indicator that we have not managed our bottlenecks well, and we have not tuned our WIP accordingly.

High efficiency is not a goal we are trying to achieve but can be a measure of how well we are managing our work items.

"both the first and last finisher in the marathon had 100% flow efficiency"

Going back to the Starbucks example - if you go into any busy Starbucks at lunchtime, you will never see the coffee machine inactive.

They are controlling their bottlenecks to have maximum efficiency. They might even have more than one machine, attempting to reduce the burden on the bottleneck, and improve the flow, getting as many cups of coffee out as quickly as possible and make bucketfuls of cash.

And so it goes for us. We should constantly look to where our bottleneck exists and maximise and alleviate it.

The Story of Why

In Order to <INSERT BUSINESS VALUE>,

As a <INSERT BENEFICIARY>,
I Want <INSERT BEHAVIOR>

Seems obvious doesnt it?
Apparently not!
I think it is easy to fall into the trap of stating What Who and How instead of WhyWho and What.

All too frequently Client stories are missing the Business Value

• If we cannot visualise the Value of a story then we are powerless to prioritise the work.
• If the Value of a story is not apparent then we are unable to know if our teams are helping business to make more money

To take a highly disguised example, which is somewhat typical on many teams  :

This reads to me as WHAT, WHO, HOW.

Basically we are looking for WHY, WHO and WHAT

First thing to scrutinise is, whether it is clear to all parties how is this offering business value?
"filter stuff based on a specific value flag" doesn't clarify that in my opinion.

Second of all having the "As a" section as another application is a big warning sign that the story may not be cross functional

Last of all for the "I want" section it is clear in this case there is a clear instruction of how this should be implemented, and this eliminates the freedom of the developer to identify the best solution

An arguably better version of this could be:

In order to prevent the overhead of processing superfluous messages
As a consumer
I want to filter messages based on a specific value flag.

Perhaps a lot of people think 'So What!!' about the fastidiousness of this, but it IS Very important for a number of reasons:

1. By revealing the business value, you are enabling the team to have the potentialto identify a better solution
2. If the team clearly understand the business value, they can be ruthless in not creating wasted gold plating.
3. By removing the HOW part of the story, you are giving the freedom to the team to implement the solution in the way they see fit.
4. By stating the direct business Beneficiary, you are creating a vertical slice of the application instead of a horizontal slice.
5. Visualising the value gives clarity for providing clear prioritisations.

Sorry Eric, you are a genius, but we will engage our brain before doing anything thanks!

Why should we care about cycle times?

What on earth do a development team care about Cycle times? After all what is it really for?

What do I care if it management want some bullshit metric to measure teams with - that doesn't make it valuable to us. We can't do our jobs better because of that.

OK so management can use cycle times for planning - but I don't need to know about that. I just want to get on with developing the product.

Granted, if we have short cycle times we can release the software more quickly then the company can make money on it sooner. But its not like the money wouldn't be made eventually.

Yeah - I suppose if we released regularly then my jerk of a boss would see what we have done and wouldn't scream at me for building the wrong shit.

Then my jerk boss makes us hack in the right solution at the end of the project for 3 weekends straight. If the code wasn't full of last minute hacks then my boss' precious cycle times wouldn't be so long!

Alright Alright I admit, by having shorter cycle times then I am probably going to have less things at any one time to work on, and my focus and attention can be given to one work item and prevent context switching.

FINE!! - short cycle times mean that the client will see our progress and have faith in what we do, but does that help me do my job? Trust between my team and the client is great but how does that let us build something better?

Alright - fair enough - I guess by having the clients trust I won't have to listen to them tell me how to do my job and have them constantly checking up on my every move.

Okay Okay okay - other than quicker releases, better return on investment, fast feedback, cleaner solutions, less context switching, gaining the trust of the client, what have the Romans ever done for us?

Business Driven Goals - Why > What > How

​Whenever I am presented with a problem I usually jump straight in and start to think about the solution. It is a natural inclination I have to create a link between my knowledge and understanding, to the solution. I think that most people behave instinctively in a similar manner.

In that regards, I think it is very natural that when presenting a team with a feature that is to be developed, the language used is often based around HOW to create the solution.

A recurring problem that the teams I have been on, and our customer faced was to make sure the requirements defined WHAT is needed, and not HOW it was to be built. Over time this approach has been cemented, which was a very positive step forward.

It has allowed the team the ability to collaborate and Identify how best we can create a solution.

More recently we have started to be much more focused on defining stories based around the business value. It allows all members of the team to be conscious of the exact value being added with the work being done and keeps the work on focus. 

However, the feature that is being delivered is specific in its definition, so any attempt to define the business value for a story is inferred by the team. With a small amount of luck, the business value of the story will match the business value of the goal that the feature is trying to satisfy. 

But ...the team has not been told WHY the feature is to be built.

Quite possibly, the feature selected is not the best way to satisfy the business goal. 

Just as there is cognitive bias attached to presenting HOW to build something ahead of WHAT to build, there is a cognitive bias in presenting specifically WHAT to build ahead of WHY there is a need to build something. In each of these scenarios we are narrowing the scope of ideas.

We have previously learned that:

• By presenting a team with the steps to build a solution, it blocks them from creating better steps to the same solution.

To follow that same train of thought:

• By presenting a team with a solution to a business goal, it blocks the wider collaboration in thinking of better solutions.

By understanding the business goals that we are trying to achieve we improve by:

• Allowing teams to focus their efforts solely towards achieving that goal, and not wasting time exceeding the goal.
• Eliminating scope creep on features
• Eliminating pet projects
• Letting teams see which actions bring the goal closer
• Letting the team learn from steps that do not bring the goal closer

Lets be real - If a client decides that a feature will be of business value, and is paying for the feature to be built, its simply not feasible to suggest that the business goal be shared and that other solutions be explored. 

However, what should always be feasible is that the team can find out the business goals behind each feature, and also find out how to measure when the goal is complete.

So when we are looking at our goals, lets start with WHY, then we can look at WHAT, and eventually move to HOW.