Kanban Limits

  • Article

Model your process

Probably by now if you work in the software industry you heard about the word kanban or already are using a Kanban board with your team.

A Kanban board (usually implemented using a whiteboard, wall with stickies, or electronic version) lets you model the series of steps that as a team you have to take in order to produce working software.

Some of the benefits are that you gain visibility, communication and transparency in one simple step. And if you use it right you will be able to show bottlenecks and cope with them or at least elevate the issue to someone that has the power to solve it.

Most important is that you can focus on working based on your team capacity (Pull) vs. working by demand (Push).

However today I don’t want to do a 101 post on Kanban. There are plenty of posts for that, you can find them here, here and here.

Today I want to talk about what is the result when, once you read that intro, decide to implement Kanban with your team. What happens next?

The quality conundrum

I have to admit it, having a wall full of stickies looks pretty cool. Looks like you are really busy. If you have a mess at work every day, probably the board will look exactly like that.

Having the board quite full, though it represents accurately what’s going on, may raise some questions after a while:

  • Why are we doing this? What’s the benefit?
  • Isn’t this the same as the excel spreadsheet but horizontal?
  • Why can’t I just put the sticky notes wherever I want?
  • Can we skip it just for now? Until after the deadline?
  • Where’s my Gantt chart?

These questions are quite valid. Like any other process, you need buy-in from the team, but also you need to show some kind of improvement.

For some teams, just showing the status on a board is quite a benefit and management sees value right away because they can look at pending work, what’s going on, etc, with less meetings and less checks on the team.

That is an excellent first step, and for some teams it is ok to stay there. However lets not forget though that the team is still working based on demand, if more features are needed for the release they will go into the queue no matter what.

Finding the team capacity and being able to do more accurate estimations is the next step.

Continuos improvement culture

In his book, David J. Anderson talks about Kaizen. The culture of continuos improvement.

But in order to improve we need to know first our reality and identify what is the capacity of the team. Remember, no matter what we think of ourselves, reality always wins.

To do that we need to find the Work In Progress limit for each phase so we can pace the amount of features that enter to the backlog. Otherwise the input queue is the same excel spreadsheet that we had before.

Missing on using the limits or postponing choosing limits may lead to a failure in implementing the board in some cases, and I urge you not to let it be so.

The concept of Lead Time is key. That’s the time that takes for a feature since was added to the queue to be finished, but really finished, not just compiled (if compiles it works, right?), not 90% tested, done done. Think about it like being a bit pregnant, how many answers you have for that?

That is the measure that we need to improve (to go faster), and that’s how are we going to tell if the board is working for us or not. Once that metric is calculated and shared, it is easier to discuss about speed, analyze bottlenecks and other problems, and find solutions for them.

Choosing WIP limits is important and it should not be delayed. Start by proposing some numbers, don’t worry about 100% accuracy. So far no unicorns have been sacrificed in the name of the “Gantt chart” god because a team got his WIP limits wrong the first time.

How do you know if it works? Well, check your lead time. Is it improving? Are you happy with it? Is management happy with it?

Tips that help:

  • Work as a team: The team has to help to push features faster. When someone has an issue, then the whole team is responsible for it and they need to work together to fix it no matter if they are analysts, BAs, testers, devs, etc.
  • Never move a card/story back: That breaks the limits and doesn’t help. Remember that we are not trying to identify in which phase a card is, but to move faster. If a card needs more work it should stay in the phase that needs more work. And if that happens often, well, time to talk about it.
  • Similar sized features: Try to consume a feature every two or three days if possible, that would give you and idea when a feature is too large and has to be split.
  • Don’t waste time estimating: Identifying complexity is fine, but to use that information to calculate days or hours of work is a waste. Use the board to have an idea of how many features you can complete, that’s your reality.
  • Avoid tasks lists to estimate completion: Task lists do not show progress. One day you have 10 tasks, the next day you discover 5 more, the day after that you realize that with 5 tasks is enough, get the gist?
  • Watch the board: Don’t let cards stay for too long on a phase, raise concerns because something not working as expected.