Kanban In Software Development

How should the KanbanSystem be used in software development?

Do the concepts map directly across? Is it helpful or harmful to do kanban in software development?

Should the KanbanSystem be considered part of LeanProgramming?

Articles: Discussion:

Kanban is a term I just heard around Christmas of 2002, and a little research has turned up some interesting insights. Apparently MaryPoppendieck has noted this affinity with AgileMethods as well. -- StevenNewton

See the "LeanSoftwareDevelopment, An Agile Toolkit" book by Mary and Tom Poppendieck.

The KanbanSystem sounds a bit like some of the ExtremeProgrammingCorePractices. See also LeanProgramming and LeanThinking.

The KanbanSystem, as applied to software development, typically proceeds by
  1. dividing the software development process into a sequence of steps,
  2. moving the story cards across a big visible board (with one column for each step)
  3. and imposing limits on the number of stories that can be "in" each step, at one time.

This makes bottlenecks more visible and obvious, so that management (or the team) can take action to correct the situation.

For example, if stories back up in the final "testing phase" of software development, this application of the KanbanSystem would force the developers to stop coding until the next story completes testing. This might motivate developers to "switch hats" and take on the testing role to clear the queue. Or it might motivate the developers to make testing easier.

The problem I have with applying the KanbanSystem to software development is that it's an inappropriate tool for the job. Because the KanbanSystem is only applicable to processes that move work through sequential steps, teams adopting the KanbanSystem must create artificial problems in the software development process, by separating their work into sequential steps (a la WaterfallModel) so that they can use the KanbanSystem to solve SOME of the problems this causes.

The fundamental problem here is that kanban is a manufacturing process, while software development is a design process. The manufacturing process of software development is the act of compiling, linking and copying the deliverable software artifacts. In a well-run software development shop these steps are fully automated: They run with little or no manual intervention. Thus the only appropriate application of lean manufacturing specific concepts to software development, is the optimization one might do to make the build process run faster.

Lean design concepts, like the TheoryOfConstraints map well to software development practices. Software development is a design process. We produce the "blueprints" by which software is built: That is, the source code is the "blueprint" by which the automated build process "manufactures" the working system.

Focus on design! Software development is a design process! -- JeffGrigg

In other words, a KanbanSystem could help you solve some of the problems you introduced by distorting the software development process such that you could apply Kanban to it.

Yes. In the same way that I'd be glad to give you $1000 in cash. Right after you give me $1800 in cash first. ;->

Kanban applied to software development seems to fall into the classic trap of thinking that:

(a) Tasks are identical (b) Developers are replaceable cogs (c) Development can be reduced to a process (d) Product owners can 'groom' tickets effectively

After having this imposed on me, I really miss scrum. Never thought I would say it, but nothing in Scrum is as demoralizing as the "why is your ticket taking so long in the 'in progress' column" question. In Scrum, there would be a response: "It is an 8 point ticket." In Kanban, the attitude is that the Product Overlord has put the ticket in the hopper, thus it is identical to the other tickets.


a Mapping of the KanbanSystem characteristics to ExtremeProgrammingPractices:

  1. A simple and understandable process (PlanningGame)
  2. Provides quick and precise information (BigVisibleChart)
  3. Low costs associated with the transfer of information (OnsiteCustomer & BigVisibleChart)
  4. Provides quick response to changes (TestDrivenDevelopment)
  5. Limit of over-capacity in processes (OnceAndOnlyOnce)
  6. Avoids overproduction (YouArentGonnaNeedIt, SmallReleases)
  7. Minimizes waste (YouArentGonnaNeedIt, RefactorMercilessly)
  8. Control can be maintained (PlanningGame)
  9. Delegates responsibility to line workers (CollectiveCodeOwnership)

View edit of October 22, 2014 or FindPage with title or text search