4 key takeaways from Kanban Management Professional training

After recently attending Kanban Management Professional I and II training, I got some useful new language to help me explain some of the underlying instincts that I have around typical project stumbling blocks.

I want to share a few of the “a-ha” moments where I think the application of Kanban principles applies to common project situations. Turning amorphous ‘feels’ into real-life explanations has definitely helped me, and it should apply to your projects too.

As someone who has worked in delivery for a while, I have come to trust my instincts and know when certain suggestions aren’t going to help a team to deliver. There are certain archetypes that come around again and again. Sometimes they’ll look different or involve different stakeholders but they are the same.

A classic of the genre is: “We’re late delivering widget A!  Let’s take team members from another project and add them to the widget A team to make it go quicker!”

Often your delivery spidey sense kicks in, either knowing from hard worn experience or simply your gut reaction that it won’t work.

Sometimes you have the support of stakeholders and along with your team can talk everyone out of it, but sometimes you can’t. Saying “trust me” isn’t going to be enough to convince the people who want to DO something.

Having the language to back up those gut feelings will make you more persuasive and help you influence decision-making.

1. “Throwing more devs at the problem will make it go quicker.”

Traditional project management thinks about people in terms of utilisation, that you can boil down what people do into units (e.g 1 dev day).

This way of thinking traces its roots back to Frederick Taylor, who popularised the idea of breaking down work into easily replicable steps, so anyone could do it.

This meant it was easy to know how much work a person could do in one day. It also created massive economies of scale (hello factories) and the ability to deliver far more than individuals ever could. This doesn’t work in digital projects however, because:

• ‘Work’ is complex knowledge work that is not easily replicable
• People are not units of production, they have thoughts and feelings.
• The work takes place as part of a system which has environmental factors

Kanban tells us there is no such thing as a dev day, you should look at the work and the system that is delivering the work. This system’s level is where you find inefficiencies and where you should start if you want to speed up delivery.

Therefore if dev days don't exist, adding more people isn’t necessarily going to make the work get done faster. Some reasons for this might be that new people need onboarding and this is going to slow team A down, especially if there is a new technology in play.

Team dynamics will be impacted. How is Team A going to feel when new people are drafted onto their team- could it leave them asking “we’re obviously not working hard enough”? Morale may decrease and with it delivery.

If the people added are developers but we only have one UXer those devs aren’t going to have a whole lot to do. So the simple approach of throwing more people at the situation does not make the thing get done quicker and has the potential to actually slow you down (at least at the beginning).

Kanban focuses on the work itself and not people. You can’t make a printer print any quicker by stuffing more paper in it.

2. “This work is similar to what we’re already doing, we should do it at the same time.”

Whether you’re working in sprints, to a fixed deadline or trying to get it done asap, you’ll have definitely heard this before. It also feels very tempting as there is always pressure to squeeze in something similar. Often with wishful thinking around the impact on the existing work.

• Starting sooner does not mean you get it sooner
• Work in progress (WIP) is the best indicator of lead time
• Start finishing and stop starting

Kanban is about visualizing the processes you need to get a piece of work from ‘started’ to ‘done’ (your system), and limiting the amount of work at each of the stages in between.

Then you can start to measure when something enters the system and when it leaves, this is your lead time. Work that is already in the system is work in progress (WIP).

Your best indicator of your lead time is the amount of WIP. You know this because you are measuring it. After a period of time, you’ll have some pretty solid data about how long your lead time is, and if you limit the WIP in your system you’ll find that the flow of the system is optimised.

Conventional thinking tells you the sooner you start the sooner you get it, but the shift in thinking here is about completing what you have already spent effort on.

Furthermore, the items you have spent the most effort on and are nearly done should be your focus. Once you have cleared that item you can then pull more work downstream.

That gap is a signal, a ‘kanban’ you’re ready for more, and this is how you actually finish work items instead of just starting new ones that are then in progress for weeks.

3.  "We’re just going to have to do overtime to catch up."

If you keep doing this people will leave. You pay for overtime in one way or another. It might get you over the line on a given day; but you’ll have sickness, poor team morale, and lower quality outputs from tiredness afterwards. Here’s some KMP knowledge looking at this:

• Irrefutable demand strings out teams and is unsustainable
• Blaming people for not working hard enough makes no sense

A smart guy called Dr Deming came up with the Red Bead Experiment which posits that a system has variability and the workers that are part of that system, even if they are doing their best work, cannot control this.

So telling them to work harder isn’t going to get the work delivered quicker, they can only work within the system they’re given. To get a better result you need to change the system not the individuals in it. Managers and those with the power to change the system need to remove the things that are holding the workers back from delivering.

People aren’t the problem, people are doing their best. The Prime Directive used in retrospectives sums this up pretty well: ‘Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.’

An overwhelming backlog where everything is super important and needed as soon as possible is an insurmountable feat, and most teams burn themselves out or become jaded with trying to keep up with irrefutable demand. If you’re the person encouraging this there is a reason you feel guilty.

When you’re using Kanban principles and measuring your lead time and WIP you can also measure your throughput (Lead time/WIP). This data tells you your capacity, so in one week I know I can do x amount of work.

Now you know what you can predictably deliver, you therefore know how much demand you can service. This is information that you can use upstream, to communicate to your stakeholders and to order the top of your backlog to ensure you have the right amount of work ready to go.

This creates a sustainable rate of work that creates a buffer in your system and is determined by how work actually gets done in reality by your team. You can then look to make improvements to the system to speed it up, but this understanding and rate of work have to be established first.

4. "We spend a lot of time estimating things, and most of the time they are nowhere near."

People want estimates as they want certainty and an idea of when it will be done.

At the beginning of a project we know a small percentage of what the work will entail, and we know very little about the capacity of our system (as we haven’t done any work yet), but this is precisely when people want commitments.

Hard deadlines are pushed as ‘encouragement’ to teams that have been perceived to have ‘missed deadlines’ in the past.

• With a few weeks of data, I can give you a % level of confidence when the work will be completed
• You don’t need to spend time on estimating every piece of work

If work is broken down into small enough pieces (i.e user stories) that have acceptance criteria, and you have set up your WIP limited Kanban system you simply need to start working on it. After a few weeks, you’ll have enough data on how long things are taking based on the actual work itself.

Upstream decision makers need a sense of timings, but they don’t need to know exactly how long every piece of work will take. This is especially true when those estimates have been shown to be inaccurate time and time again.

If you can show a predictable delivery rate and a projection of what that means for feature A with a % confidence, you won’t need to spend lots of time estimating. All of that time you used to spend estimating, you can then use to do more work.

So that’s it, a couple of small takeaways from the KMP course I recently attended. I’d love to hear if these chimed with you and what other Kanban thinking has helped to explain your delivery gut instincts.