Kanban is where software development starts getting interesting. It shows you a lot of flaws in the organisation.
What a great question!
Most of what we call Agile is based around optimizing the development team. Sprints, pairing, continuous delivery. We develop software with Scrum teams. Our developers work in squads and guilds.
We’ve come up with all kinds of ways to improve collaboration and productivity, but we don’t apply those outside the development silo. Silo? Yes, silo.
Development does Scrum, the rest of the company does whatever they do.
Our dev teams do Kanban.
More is more
The example above is a great one. We see our productivity rise when applying a Work In Progress limit. Developers stop starting and start finishing. Awesome. Yet the edges of the board pile up. The “To Do” list gets bigger, the “To Accept” list as well.
Why is that? Because the rest of the company is also looking at their individual productivity. Local optimization is the root of all evil.
“Let’s analyze one sprint ahead“, says the functional analyst as he writes another JIRA ticket.
“More ideas are better“, says product management.
“We’ll plan a UAT test at the end of the month“, says QA.
Muda, Muda, Muda. All of them are wasting the productivity gains the dev team has achieved.
Yet we keep squeezing the last out of dev productivity.
It’s the equivalent of taking a slow train and then renting a Lamborghini to race the last mile to the hotel. It’s the wrong thing to focus on. That’s not where we’re going to make the difference.
I wish there was an easy answer to @sftwrcraftman ‘s question, but there isn’t. For all the talk about “business agility”, it seems hard to get people to work in a Lean fashion.
That doesn’t mean there’s nothing we can do, but it’s going to be a bumpy ride.
Less is better
Like a lot of this agile stuff, the Work In Progress limit finds its origins on the Toyota factory floor. When a work station has a huge pile of doors that need to be installed, the common sense is to consider this station too slow. Either we need to add another one in parallel or we need to improve the productivity of the people who install doors.
Kanban says that’s wrong. We shouldn’t be looking at the productivity of the station but of the entire value stream. The logical solution is to slow down the work station that produces the doors. That increases the flow of the entire organisation.
In the typical development setup, there is a work station that produces JIRA tickets on the left of the board. The dev team builds its features and deposits them on the right-hand side of the board, ready to be picked up. We don’t want a faster Lamborgini, but a faster overall journey, so we are going to have to change the relationship with our neighbouring stations.
Start by applying a WIP limit to the edges. If we’re allowed to have 5 tickets “In progress”, then we’ll also allow only 5 tickets in “To Do”. By being strict about those, you’ll gently force the silo’s before and after to play ball.
Push on the left
The work station before us is churning out too many doors. We need to slow them down to speed up the entire flow. Pushing back on the left sounds counterproductive, but Kanban says it’s not. So, the dev team will only focus on what’s on the board. That means no estimates of stories for the coming sprints, no quick discussions about that one feature for Q3. Since there are only 5 slots available in “To Do”, they’ll have to be very selective. It will force the analysts to focus on the most important stuff and will bring them closer to your team. Remember, we’re aiming for Just-in-Time here.
Push on the right
The opposite logic works for the right. Let’s say there is a UAT column that’s the last step before things can be pushed to production. In a very common case, these UAT-testers are not working full time. In fact, they are probably doing acceptance testing as an extra. They often want to process a lot of tickets in one go because that’s better for their time management. That’s harmful to the overall flow.
Kanban tells us that when they go slow, development has to slow down as well. So do that.
If there are five tickets in UAT, stop developing. Let the entire team work on documentation. That one library that nobody knows really well? Read up on it. Improve your station, but don’t churn out more doors. Again, that feels counterproductive, but we’re looking at the overall flow of the product. We are not focussing on an even faster Lamborgini.
If all goes well, left and right will be more involved and we’re a step closer to breaking the silo.
The idea is to get the entire product team into the Kanban flow. It’s naive to think this will be easy, but it’s definitely worth it.