Kanban as a Software Development Process in Practice
The Kanban method is foremost a catalyst for continuous process improvements. It’s not a quick fix or a fixed set of steps/practices. The method has a few foundational principles and core properties, as described in David J Andersons recent blog post, that can lead you the way to continuous process improvements. To your questions:
The Kanban method in itself does not identify bottlenecks. When implementing work-in-progress limits to a process that creates stress on your process you will eventually create a pull system and then it becomes easier to identify bottlenecks in your process. Tools like a visual kanban board and Cumulative Flow Diagrams will help you identify the bottlenecks in the process.
If you apply the foundational principles and core properties and you have the stamina/patience/dedication it is not too hard. You need to manage the change process as with every organizational change but the Kanban Method is designed to make small and non-threatening changes.
Yes there are many documented cases of this.
The Kanban method does not identify a specific method for planning and projecting future deliveries. David J Anderson has a background in Theory of Constraints and uses TOC as a model in most of the writing I have read. I think the practical difference between using MS Project style big up front planning and the empirical based planning used in many kanban implementations is the big difference. When working with a project plan designed in MS Project in the beginning of a project you know very little of the actual problem domain and you make assumptions. Based on these assumptions you device a plan. A critical path is calculated based on these assumptions. With a stable kanban system and you use TOC as your model you plan “only” to have your constraint/bottleneck on the critical path. You take into account the historical variability of the work passing the constraint and you create buffers around you bottleneck with the appropriate risk you want to take. The thinking is that every hour lost at the bottleneck will be an hour lost for the whole system.
The main benefit of the Kanban Method is that it is a catalyst for continuous process improvements. It starts with what you got and makes non-threatening changes that sticks. Kanban is a method that is Made to Stick
In the article Applying Kanban to PC Deployment the Team has to account for the following equipment:
- 160 new PCs to be deployed
- 40 new laptops to be deployed
- 120 PCs and 10 laptops to be refreshed and redeployed
... we are exploring the use of Kanban to manage a short-term functional project. This example focuses on using Kanban to create a transparent process to track the flow of equipment through a number of complex steps, without incurring additional costs for tracking software, complex processes and training, or duplication of effort. Improved uniformity or quality of the deployment process will also help improve efficiencies in troubleshooting and repair times as well as ensure a document-ably high level of conformance to software and licensing standards.
The page above has also links to Kanban applied ...
- to Tech Support
- to PC Deployment (see Quote above)
- to a Development Group
- Challenges, Additional Concepts, and Wrapup