Kanban In Software Development
Kanban In Software DevelopmentHow 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:
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
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.
Painful.
a Mapping of the KanbanSystem characteristics to ExtremeProgrammingPractices:
EditText of this page
(last edited October 22, 2014)
or FindPage with title or text search