Agile Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

Kanban: Engineer Killer?

07.31.2013
| 8003 views |
  • submit to reddit

Brian de Haaff has an interesting blog out this weekend (which I'm sure David J. Anderson will not be happy about) called "Kanban–The Secret Engineer Killer."

Kanban–The Secret Engineer Killer


Here's just a taste of the criticism from Brian's article:

Kanban devalues your company’s own talent, culture, market and unique know how. It teaches you that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects. Worse, it trains the team to only focus on evolutionary improvements and avoid looking for major breakthroughs.

No comments are allowed on his blog but you can sound off here.

Comments

Ian Mitchell replied on Wed, 2013/07/31 - 3:10am

Kanban can be viewed in at least two ways.

Firstly there is "Kanban as method", and this is where I think Brian has a point. IT workers are not assembly line workers and their approach to the value stream, and its optimization, may not bear much comparison. If the Kanban method is applied to project work, and the de-risking of uncertain project scope, then the approach can indeed be found wanting. However, if we constrain the use of a Kanban method to small and repeatable changes - such as the administrative or templated changes that typify "Business as Usual" work - then the benefits of Kanban do stand a better chance of being realized. The use of Scrum for project work, and Kanban for Business as Usual, is a recurring enterprise pattern and one that can be used successfully.

Secondly there is "Kanban as tool". This is where andon signals and information radiators, such as a Kanban board, are used without buying into Kanban working practices. Scrum teams, for example, might use a Kanban board rather than a task board. Individuals might use "personal Kanban" to visualize their work, somewhat in the manner of a "to do" list. Kanban is a great tool for transparency, and can lead quite naturally into better ways of working such as the gradual limitation of work in progress. I'll often set up a Kanban board as the first step in an agile transition, just as a tactical move to get the transparency in place, before making any strategic decisions about how to transform an organization's working practices.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.