Joe sighed and returned to his desk. He had been waiting for Jane to provide him with information for the last two days. If Jane could only take a few hours to do it, he could get on with his work and check it off his list. Instead he would now have to wait for a week before Jane can even look at it. He would just have to tell Smith this project deliverable will be delayed. The customer is probably not going to be happy about it, but there is nothing he could do about it. Reaching his desk, he put this work aside and stared at the pending work list wondering what he could do next that can be completed. The list continued to grow. We need more people, he thought as he eyed his manager walking towards him.
Jane shook her head in frustration. She wanted to help Joe out; in fact she had been scheduled to work on Joe’s stuff, but was pulled away on other priority work. Glancing at the work requests piling up, she thought, we need more people.
Donald, the CEO, sat staring at the phone. He just got off the phone with one of the customers. The project team had missed the delivery for the third time. And this was not the only project that was in trouble. “This is crazy. What”, he thought, “were we doing wrong? Why can’t we seem to get our act together and deliver projects to the plan? We should plan better. I better find Smith and find out what’s going on.”
If you can relate to this scenario you are not alone. Dedicated project teams are not always an option. The same person may work on projects, perform maintenance tasks and also is part of the support team. This individual finds his time divided to work on more than one “work type” during the course of the week. However, this allocation of time between “work types” is not always adhered to – the allocation shifts based on priorities and fires that are burning during the course of the week. This is a very stressful method of working. The list of unhappy people is endless.
Is there a way out of this chaos? Can Donald and his team get out of this rut? Sure. What Donald and his team does not realize, that the silver bullet is just a few steps away. But first let’s see what information does Donald and his team need to improve their performance. They need an understanding of:
- Work types, and
- Rate of flow of each work type through the system
Let’s assume the following work types for Donald’s organization:
- Quick work
- Project work
- Problem work
- Support and Maintenance work
Your organization may have less or more work types. Now that Donald has an idea of his work types, he needs to figure out the rate of flow of work for each work type through the various teams. If you think, this is a complex undertaking, it is not. I’ll show you how easy it is to figure this one out.
Rate of production
But first, why is understanding the flow important? It is important to understand flow to set customer expectations. Think of flow as the actual rate of production for your team. Without the understanding of the flow, Donald cannot even dream of entering into service level agreements (SLAs) with customers. Without SLAs to set expectations, teams would not know what work is important and the order it needs to be completed. Flow is important to set customer expectations.
Donald’s organization is divided into teams. Teams within a matrix organization is generally divided by functional areas; a business analyst team, a .NET team, a business intelligence team, etc. Whatever the basis for your team’s division, it is important to understand at what rate each team completes each work type. Each work type may touch a number of teams and not necessarily in the same order. The throughput of the work through the system is a function of the rate of flow of work through the slowest team. Improve the performance of the slowest team and you have suddenly elevated the performance of the system for that work type.
How Kanban helps
That is theory. In practice, we really do not know upfront what effort and duration the work entails and which teams will be involved. As we learn more about the work, we gain a better understanding of the skills needed to complete the task. Due to this dynamic nature of work, work can sometimes get stuck waiting for people with the right skills. This is a bottleneck and we need to know as soon as it happens. Without highlighting such bottlenecks, work will only get complete when it is expedited. And expediting work will only happen with customers complain about the delay. Not good.
Highlighting bottlenecks as they appear will ensure that it gains visibility in the system. Resolving these bottlenecks then becomes a priority of the team. It is better to resolve bottlenecks at this level, than to wait for it to become a raging fire.
Kanban for software development does this beautifully. Kanban not only enables a visual work flow, the “limit work in progress (WIP)” rule also creates a bottleneck if flow is interrupted. If you think bottlenecks are bad think again. Bottlenecks are necessary to enable a smooth flow of work. That’s the main reason bottles have necks. Without the bottleneck, it will be quite hard to pour out the liquid without making a mess. Just as the neck of the bottle regulates the flow of the liquid, your process bottle neck will regulate the speed of delivery.
Now that Donald has a good understanding of his work types and the flow of work through the various teams, he is now ready to improve. Donald’s focuses his improvement efforts on the team that data shows to be a consistent bottleneck over a period of time. Improving flow and reducing waste through just that one bottleneck team will elevate his system throughput considerably thereby gaining him significant capacity without adding headcount.
The best part about implementing an initial Kanban is that Donald does not have the change a thing in his processes. It is the least disruptive of processes to implement. All Donald has to do is to visualize the work flow for each team to begin with. Just visualizing the work will help speed things up. Once the teams are comfortable with the visual tool, the next step is to limit work in progress (WIP). This can be accomplished by limiting WIP by process step or limiting WIP by people. Have a guideline that says, no one can work on more than one or two active tasks at the same time. Limiting work either way works. That’s it. That’s all there is to implementing a Kanban.
Of course, you need to develop policies along the way as you learn more about the work types, the teams and the flow rate. The key is to keep it simple. Kanban matters. As the Kanban world says, “Visualize. Limit. Improve!”
4 thoughts on “Why Kanban for software engineering matters”
Yes, the recent rhetoric is indeed sad. Totally unnecessary. I personally like Kanban for its evolutionary approach. But I have nothing against Scrum or even Waterfall for that matter. These are just tools in the project manager’s toolkit. Need to use the right tool for the right job, I say. 🙂
Nice Post CA,
I’m disappointed with all the heated rhetoric these days between the Scrum and Kanban communities. Like many Kanban practitioners, I’ve implemented Scrum in the past within the context of a large organization and found it could be effective for a single project, but it was hard to maintain and scale across the organization. This is not a defect in Scrum, but a mismatch between the “ideal” context for Scrum and the reality of how most large organizations are structured. If you can change the organization around to suit Scrum, go for it. If not, Kanban is a great way to start introducing improvements that will, hopefully, over time lead to greater organizational change.