I have been trying to break free from the shackles of the traditional waterfall approach to project management in software development. As a project manager, I am amazed by the waste in the name of following a process. Heavy on documentation, traditional approaches may have worked in industries like construction where it is difficult, and at times impossible, to change specifications once a structure has been erected. Not so in software.
There is value in developing and delivering small chunks of features. These features being small can be developed quickly, thereby improving project delivery speed. For the uninitiated, there are a plethora of Agile tools – Rational Unified Process (RUP), eXtreme Programming (XP), Scrum and more recently Kanban. I was fortunate to be given the opportunity to improve part of our software development process – increase speed of service delivery without sacrificing quality. Kanban wins hands down. Why? Over 80% reduction in delivery times within two months.
Kanban – a pull system
Kanban is a Japanese term that literally means “signboard”. in its strictest sense, it is essentially a scheduling system that “signals” what to produce, when to produce and how much to produce. (And yes, you are right in assuming that it originated at Toyota.) If you work in a matrix organization as a project manager, you are well aware of the challenges of securing dedicated resources for your projects. If you do not get dedicated resources, you need all of your sales and negotiation skills to ensure resource availability when needed. On the flip side, as a resource manager, you are constantly juggling your resources on various projects – an optimization challenge.
This is a push system. Usually, symptoms manifest itself as resource contention, waits between steps, extended duration, resource unavailability when needed, overtime, and many issues that distract from actual work. The person screaming the loudest usually also gets the resources. In this system, you push to get work done through the pipe. As you will see, Kanban is a pull system. Work gets pulled by the people who actually do the work based on their availability.
Kanban – evolutionary and leads to continuous improvement
There’s a saying – people like change as long as it does not happen to them. Ask anyone on their view about change and you will get all positive things about it. Ask them to change, and you will hear all the reasons why it cannot be done. “I agree we need to change, but the timing is not right.” “Yes, but we are different.” “Oh, the company that implemented Kanban is a manufacturing firm. We are different”.
If you work in such an environment, getting enterprise-wide change that is revolutionary is excruciatingly painful and slow process. So you need to evolve. Of all the Agile tools out there, the only tool that helps you evolve is the Kanban process. Exceedingly simple to implement, you can be up and running with the tool in less than a week.
Kanban can lay over your existing process and asks you to follow just three basic principles:
1. Visualize your workflow
2. Limit your work in progress
3. Only start new work when you have finished some existing work
I know this sounds crazy, but following these basic principles can dramatically improve your team’s throughput. How, you ask? Let’s look at each principle.
Visualize your work
This helps you see where the work currently is in your process. Assume work flows through the following stages: requirements, design, build, unit test, promote to QC, testing, approval, deploy. Visualizing your work will show in which stage each feature is. One look at your Kanban board and you will know where all of your work is. Visualizing your work will also help you identify wastes in your process that you can reduce or eliminate. It will also help you identify bottlenecks before they become raging fires.
Limit your work in progress
Multi-tasking does not exist. Period. You cannot work on more than one task at a time. So why juggle between five tasks and extend the duration of each, when you can complete each one sequentially and reduce the duration of each. Kanban prescribes work in progress at each stage. Your system throughput now is determined by the process with the least WIP limit. One of the early pioneers of Kanban, Henrik Kniberg, has put together this interesting Kanban cartoon that explains the WIP limits. Murphy exists and can strike anywhere at any time. Enforcing WIP limits creates idleness and creates a swarming behavior on the problem. So if you are not prepared to enforce WIP limits, be prepared for your improvement initiative using this tool to fail.
Start new work only when you finish some existing work
While exceedingly simple, this is again a hard one for people to comprehend. “What should I do if I complete my piece?”, is the common question. Here is what you need to realize that just because you have completed your work does not mean the customer got it. A work is only complete when your customer has received the product and is using it. By pulling in more work at this stage means you may not be available to fix bugs when needed, thereby increasing duration. So go test help with documentation, do whatever, but do not pull more work until some existing work is complete.
To reiterate, Kanban’s appeal is one does not have change the existing process. It can be implemented over the existing process. Once the team gets the hang of it, local improvements will follow. WIP limits act as a clog in the pipe. If the pipe is clogged, work does not flow through the system and the team will be forced to unclog the pipe before pulling new work.
If you are new to Kanban you might consider looking up the limitedwipsociety.org – a great resource for someone considering implementing Kanban.