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
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.
sounds a bit like some of the ExtremeProgrammingCorePractices
. See also LeanProgramming
, as applied to software development, typically proceeds by
- dividing the software development process into a sequence of steps,
- moving the story cards across a big visible board (with one column for each step)
- 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 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.
concepts, like the TheoryOfConstraints
map well to software development practices.
Software development is a design
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
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
- A simple and understandable process (PlanningGame)
- Provides quick and precise information (BigVisibleChart)
- Low costs associated with the transfer of information (OnsiteCustomer & BigVisibleChart)
- Provides quick response to changes (TestDrivenDevelopment)
- Limit of over-capacity in processes (OnceAndOnlyOnce)
- Avoids overproduction (YouArentGonnaNeedIt, SmallReleases)
- Minimizes waste (YouArentGonnaNeedIt, RefactorMercilessly)
- Control can be maintained (PlanningGame)
- Delegates responsibility to line workers (CollectiveCodeOwnership)