Kanban as a Software Development Process in Practice [closed]

Question

Has anyone used the kanban method for software development management?

I am evaluating kanban as a technique and would be curious to hear from anyone who has actually applied it in practice as to how effective it is. I've seen questions like: is-anyone-using-kanban, kanban-vs-scrum, and apply-kanban-in-an-agile-team but they don't address my concerns.

What I'm interested in specifically is:

1. Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?
2. Is it easy to execute in practice, or does it have logistical challenges that you need to manage?
3. Does it scale well to project teams with many parallel streams of work and many developers?
4. How does it compare to critical path analysis (as implemented in MS Project), how is it different?
5. What other benefits can be gained from applying kanban?

Thanks.

Answer 1

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

Answer 2

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:

1. 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.

2. 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.

3. Yes there are many documented cases of this.

4. 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.

5. 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

Answer 3

I also don't have a lot of experience with it, but I think I can offer some insight. 1 & 4: the main difference between Kanban boards and other techniques, like CPM, is that a Kanban board, in a correct implementation, forces you to impose work-in-progress limits. This creates a pull system, since new items are accepted by workers only when they have capacity. This differs from an MS project type project where tasks are assigned to workers before-hand (i.e. pushed).

It is much easier to identify a bottleneck in a pull system, because work items will be queuing up at some stage in the process. In a push system, work is pushed through the system (whether it is 'done done' or not), so its difficult to find bottlenecks.

Another advantage of a pull system is you can start to base work timelines on actual results (lead and cycle time), as opposed to prediction. Yes, the size and granularity of stories does affect this, but with techniques such as cumulative flow diagrams this becomes less important.

2: Most implementations are pretty simple, and therein lies some of the strength of the technique. I think if you're having problems with the logistics of the technique, you're doing it wrong. Have a look here for a nice 'kickstart example'.

Answer 4

Few definitions to focus on before jumping onto the differences:

Agile – A structured and iterative framework to track and manage projects. This approach is used in managing software development projects. It allows cross-functional teams to collaborate on users expectations.
Kanban – A framework which utilizes visualization technique, limiting the number of tasks to be taken in “Work in Progress” column. The segregation of a similar type of tasks can be done here. To simplify it, allocate colors to tasks using the swim lanes.
Scrum – The approach followed here is breaking down a complex task into simpler smaller manageable pieces which are easy to collaborate upon by the respective owners of the [scrum][1]. 

Similarities between Kanban and Scrum

• Frameworks of agile methodologies
• Used to track the progress of the project
• Provide the team transparency in tracking the work progress
• Make use of visualization

Differences between Kanban and Scrum

Roles – Scrum is dependent on the scrum owners and is worked upon by them respectively. Kanban is independent of cross-functional team members and parallel roles.

Release cycle – Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Kanban does not follow any cycle and the process is continuous in nature.

Tracking parameters – Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint. Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.

The scope of improvement – Scrum does not encourage changes in ongoing sprints. Kanban is open to any changes before the completion of the project. It is flexible in nature.

Fit factor – Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit. Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.

Pick process – Scrum picks the entire batch of user stories from the product backlog for development. Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.

Delivery – Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.Kanban follows the continuous delivery model based on business needs.

The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.

Answer 5

I don't have specific experience with using Kanban in software but I am familiar with the practice from a manufacturing point of view, so I was curious as to the implementation. Reading your link, the thing that struck me as a possible hitch is what felt like an underlying assumption about the same-sized ness of the units of work (features, stories, whatever). While keeping things "story sized" is a good goal, there are often mixes of bigger and little stories floating around, and the small number constraints in their pipeline therefore seem artificial. If the goal is to highlight bottlenecks, I would think that stand ups and sprint planning and retrospectives will do that well enough. If the goal is to facilitate prioritization, I think that putting constraints on numbers of tasks by types wouldn't do that as well as simply ordering them top to bottom.

I guess I don't really see what value its adding; that being said, I don't see the harm in trying it and adopting whatever pieces work.

Answer 6

1. Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?

This has been my experience. By setting your WIP limits to reflect available capacity, if there is work that needs to make use of that capacity but has to wait for it to become available then you will see it as the queue of work backs up ahead of the bottleneck. I have seen this happen when there is an overworked QA team with an upstream development team who keep producing even though there is no chance of it getting looked at by QA. The solution we took to this was to lend some of the developers to the QA team who then helped alleviate the bottleneck.

2. Is it easy to execute in practice, or does it have logistical challenges that you need to manage?

This will depend on many factors which will be specific to the context to which you are applying it. One of the great strengths of Kanban is it does not require an immediate 'all or nothing' change from how you are currently working. The chapter 'A Recipe for Success' in David Anderson's 'Kanban' book gives a great way of approaching the change, starting with 'Focus on Quality'

3. Does it scale well to project teams with many parallel streams of work and many developers?

In the project where I first used it we ended up with a team of seventeen developers and we had moved the QA team of four into our team too. We also had lots of external dependencies which we used Kanban to model.

4. How does it compare to critical path analysis (as implemented in MS Project), how is it different?

Pass as have never used

5. What other benefits can be gained from applying kanban?

There are many but the one I will call out is that it gives you metrics that are genuinely useful for discussing and steering the work, both with the team and with stakeholders and other people outside the team. Specifically the use of 'Throughput' and 'Cycle Time' help give you a probabilistic for cast of when work will get done.