Kanban, “signboard” in Japanese, is a scheduling system created by Taiichi Ohno to eliminate waste on the Toyota Production System. One of the its main benefits is to limit the work in progress and avoid the overload of the manufacturing system.
After software took over, many startups struggle with making their teams efficient while avoiding burn the pre-seed money faster than a box of matches inside a gasoline tank. Take a look below on what is working for our teams at Fyber and how we got to a 400% improvement in throughput in the last six months.
Use WIP limits by cycle and not by column
Have you ever wondered why traffic jams happen? Exactly. No WIP limits leads to more cars on the line waiting for the blocker to be cleared some miles down the road. That’s the last thing you want to have while building software.
Your teams should work together in cycles, not as individuals. This is the base thought behind any healthy work environment and it’s not any different for software development. There’s nothing wrong with using one specific WIP limit for each column, but let me give you another alternative to think about.
If you identify your teams development cycles and group them together under only one WIP limit you’re promoting collaboration instead of frustration for the individuals in your team that work more to the right of the board (typically Quality Assurance Engineers). Take the following board that illustrates a common software development process as an example:
If we take a look to the Development columns, we can see that only one more ticket can be started before that cycle is full. What will happen then if suddenly one more engineer is free to get something new? One might argue that you’d immediately start introducing waste in the system and throw money out of the window by not having your entire team busy. Nothing could be more far away from the truth.
Instead of starting new tickets focus your team on actually closing the ones already opened. This might seem very obvious if you put it this way but it’s actually not that trivial. Our normal behaviour as human beings it’s to clear tasks from our desk as fast as possible and move on to the next, so changing this pattern might be as much challenging as it is rewarding.
Ask your engineers for whenever they finish working on a ticket to do the opposite of when they cross the street (expect if you’re look first to the right instead of looking to the left. By doing this exercise many times we find people that need help: that new engineer that would highly benefit of some pair programming, the overwhelmed QA that is having a bad day with too many stuff in his plate or even the always busy release manager struggling with a merge conflict.
Keep the “why are we taking so long to start this?” pressure away and the results will a-m-a-z-e you. Pinky swear.
Before moving on, I have to publicly say to my manager and friend: you were right. I was too young and foolish to ever doubt you on this one!
Get your teams performance under your radar and easily trackable with your project management software (I have to say the folks at Atlassiandid a great job with Jira) .
Two basic KPIs you can start measuring are Throughput and Lead Time. Based on queuing theory, Little’s Law establishes a relation between the number of items in the process (which we call tickets) and the average time it takes to complete them (the lead time). This assumes a non-preemptive system, meaning that you can not include the states where things are not moving, typically the first and last column of your Kanban boards (backlog and closed). So going to the formula:
Lead Time = WIP / Throughput
Knowing two of these values you can always extract the other and keep your teams productivity under your radar. If we take a look to one of our teams at Fyber, this is how it looks like since January 2016:
Try out horizontal WIP limits
All engineers need a clear policy on how to choose the next task to work on. However, you also need to make your stakeholders happy and preferably avoid the discussion on why the marketing department got their tickets prioritised before the sales team.
The answer to this is to go a bit further and instead of only using vertical WIP limits, also limit the number of tickets in each swimlane. This will allow you to keep the entire board flowing and shape your teams’s effort wherever it’s needed (bugs, new features, improvements, technical debt, etc) without having to say a word.
Kanban is a pull system
That’s a fact, not a debate. Does any engineer in your team have to ask someone to do something before they can pick up any ticket on the board? If the answer is yes then you’re doing something wrong.
I’m going to repeat for emphasis — Kanban is a pull system — which means that any element of your team needs to be able to pull one ticket from the previous stage to the next at any time. QAs can not chase a developer and wait for staging deployment to start testing a new ticket. Developers can not wait for tickets to be assigned to them before starting a new task. Tickets are ready when they are ready, doesn’t matter in which state they are in the process.
Write down your policies
Kanban policies written down and get your people to come up with it, the likeliness of those policies being respected is way higher. Newcomers need to know how to work in your team without asking one single question to anyone.
Agree with your team what needs to happen for each ticket to be moved to the next column so no one has to wonder what to do with them while you are on that long meeting !
Don’t give one single ETA ever again
Yes, I’m not insane and also not trying to waste your time. Tomorrow in the office say out loud that Engineering will stop giving ETAs to the entire management team and stop talking for a few seconds. After the panic attacks, you can actually explain that an ETA is as good as the judgment of the person giving it, and we all know by experience how frequently that tends to fail.
Make your life simpler and convince your company to use lead time + standard deviation as ETAs outside of the company. Change the approach to ETAs and base those decisions and deadlines in actual historic statistic data instead of best guesses, feelings or “by the end of the week I should have something”.
This article will not give you all the answers (neither any other in the world) but hopefully will help you find what works for you and your team. Never forget: revisit your process regularly, find the waste, implement the improvements and repeat!