Show all posts
7 years ago

5 Wrong Reasons To Apply Kanban

Kanban is becoming a popular agile tool. Indeed it is very good for software projects of certain types. However, there is a danger of false reasons behind Kanban adoption.

#1. User Stories Diversity

"Our stories vary in size a lot from 1 point to 40 points. Large stories just do not fit into an iteration"

It is very easy to say you can't split user stories, thus iterations should be abandoned. An easy solution is not the best one. There is something important behind the fact you can't split stories. Most likely you don't know how to split stories right. It is quite hard from the beginning and demands creativity.

Moreover, according to Queueing Theory, it is better to have small stories with roughly equal size. Small batches with equal size improve flow (and you have a better and more predictive cycle time). So in Kanban you still have to split stories to smaller stories and try to make them equal size.

#2. Failed Iterations

"We can't complete most stories in a single iteration"

There may be many, many reasons behind. Mini-waterfall approach, velocity greed, large stories, manual testing, poor stories description, etc. You may even have a wrong iteration length. For example, in large projects 1 week iteration may be an overhead with a huge transaction cost. So 1 month iteration may be much better in this case.

You need to analyze true reasons, the roots of the problem.

#3. Failed Retrospective Meetings

"Retrospective meetings are waste, they do not help in process improvement and we want to remove them"

You just don't do these meetings right. One popular failure is no Action Items after the meeting. Without action items a Retrospective Meeting is just a kind of informal chat that you may have over a glass of beer. You meet, chat about your problems, and get back on the same track next day. Rule #1 is to collect and write the list of Action Items that you will try to accomplish during the next Sprint [or any other time box].

One more  common pitfall is to skip action items execution. You may collect them, but not really try. You may even try them, but abandon too quickly. Almost all new rules or practices put you off the comfort zone. It takes time to learn them, use them and like them (or dislike), but it should be an expert opinion, not just a gut feeling.

If you expect that you will replace failed retrospective meetings with a nice and simple "stop the line" rule, you'll fail, since it is even harder than scheduled regular retrospectives and demands even higher level of self-discipline.

#4. Shared People / Functional Departments

"We have a single pool of developers and share them between projects. We can't form stable project teams"

Do you really think that Kanban will solve your social and organizational problems? C'mon! It helps to visualize flow and find bottlenecks, but if you don't have a cross-functional team — you have hard times. It is proven in so many sources and researches that cross-functional teams perform better, produce better results and better software.

If you are experiencing difficulties planning sprints with shared pool of developers, try to fix the root of the problem first - switch to cross-functional teams and eliminate multi-tasking.

#5. Simplicity

"Kanban is so simple! No plans, no estimations, no iterations, no overhead"

Indeed Kanban looks simple. But it provides nothing interesting by itself. To ensure a successful Kanban adoption, you need to apply Lean principles first. This new buzzword may sound like a silver bullet, but obviously it  is not. Hard work, discipline, target on perfection and constant improvements - all that is required to apply any agile methodology.

Don't get me wrong. I am not saying that Kanban is bad. We use it within TargetProcess and I personally believe it works way better than iterative development (for us).  I just want to make a point that you'd hardly resolve all your underlying problems as you switch to Kanban.

P.S. I usually don't read posts like "10 reasons to ..." Can't believe I wrote such post myself! :)
P.P.S. Read next post 5 right reasons to apply Kanban.

  • http://www.leadingagile.com Mike Cottmeyer

    Excellent post… it is easy to look at a new shiny tool without understanding why and how it works and in what contexts. This post was a really valuable contribution, thanks for sharing.

  • http://www.bigvisible.com George Schlitz

    Great post…I think that kanban applied to SD can be incredibly effective, but I believe that teams that haven’t mastered basic fundamentals of success (like completing quality product, collaborating, and much more) will have an incredibly difficult time with it and will just be perpetuating their problems. I like to introduce basic scrum- once they can demonstrate the ability to get things done, retrospect/improve, inspect/adapt/plan, collaborate, and more (including understanding of lean thinking), we can then seek ways to become even more effective- kanban is likely one such way.

  • bwtaylor

    I disagree with reason #1 and #2, which are essentially the same. An iterations is not end in itself! There’s no benefit to split work from its natural size to fit the software engineering process. You admit such work is “quite hard” and “demands creativity”. But what’s the value? Working around software process constraints has no direct value.

    Iterations are a form of batch processing. You end up wasting resources trying to fit your business problems into an arbitrary time box. Just get rid of the time box and then you don’t have to use your creativity solving hard problems imposed by the software engineering process with no direct benefit. Split requests into the smallest pieces that customers say have independent value. Among these “minimal marketable features”, pick the one (ONE!) that benefits customers the most. Ship it when it’s done, and when resources are freed, add then to MMFs in development first, and only start something new if you can’t make something in flight go faster.

    Timeboxing creates waste by holding up completed work or by causing splitting below the level of an MMF. When that happens, you ship partially completed MMFs which won’t be used by users. Meanwhile the dev will be redeployed to something else in iteration 2, and when code from iteration 1 has to change you’ll either have dev2 relearning what dev1 did and why, or you’ll be yanking dev1 back, forcing him to multitask, pausing his current work. Either way this is a huge waste which can often lead to quality problems in bugs or in “hodge-podge” design.

  • http://www.resourcesystemsconsulting.com/blog/ Larry Loucka

    Great reading about lean applications outside of the the manufacturing world. I’m a bright guy, or so people tell me, and I just didn’t get kanban for the longest time. Knew the rules, could do the math, just didn’t click until one day and then I got it. Good to see you struggling. Thanks for sharing and let us know how things go.

  • bwtaylor

    BTW, I do agree very much with #3. Lean **requires** “kaizen”, which is another name for the same basic thing as the retrospective meetings. If you can’t figure out how to get the team to identify and implement improvements, it doesn’t matter what you call it, you’ll have a hard time being successful.

    I also agree very much with #4. When you fill the kanbans on the incoming side, you have to make tough priority decisions. There’s no way around this. Although, instead of prioritizing everything, you only really have to pick the top N things to fill the kanban. Slightly better, but if you can’t balance competing customer desires and pick well and deal with the politics, you’ll struggle.

    Point #5 really concerns change management. Kanban is simple after to “get it”. It seems to take people about a year to fully grok lean. If you have some people around that have done it in other settings and can do “lean thinking” it is SO much easier. But nobody should underestimate how hard paradigm shifts are to make.

  • https://www.targetprocess.com Michael Dubakov
  • https://www.targetprocess.com Michael Dubakov

    @bwtaylor All what you said is right, but I mean something different. If development team fails iterations constantly, it is a clear sign of flaws in dev. process. And if you remove iterations, it will not help. Team will continue to fail with features (quality, long cycle time, re-work, etc.) Iterations have one benefit for new-to-agile teams: immediate feedback. Failed iteration – clear sign of dev. process problems. It is harder to see failures in iteration-less development. But again I do agree with you that for mature agile teams iterations may not bring any additional value.

  • http://www.davenicolette.net Dave Nicolette

    Good list. Changing from one process framework to another without understanding the root causes of problems won’t magically solve anything.

  • http://agileanarchy.wordpress.com/ Tobias Mayer

    Thanks. Good post.
    Now I’d like to see a post about the five RIGHT reasons to use Kanban, because I honestly don’t know what they might be.

  • http://availagility.wordpress.com Karl Scotland

    @Tobias Mayer
    Off the top of my head, 5 reasons to use Kanban approach:
    1. Model the whole value stream
    2. Visualise the work
    3. Limit work in progress
    4. Establish a Cadence
    5. Enable continuous improvement

  • Mike Sutton

    Thanks Michael – really great list…for me this distills down to…

    Your list points to instances of the organization anti-pattern of ‘Change Tools Rather Than Confront Organisational Dysfunction’. Don’t knock it – many managers have made successful careers of hopping from process to process, system to system without get rid of their problems.

    I suspect the folk that will do Kanban for the reasons you list – will be the same ones that use the next new thing when they find that Kanban ‘doesnt’ work for them.

    Note to Tobias – Kanban (for me) works for areas where you cannot reasonably estimate. In the teams I’m working with – we are trying to use it for the process of backlog definition and management (grooming) and emergency defects. So far we think it works pretty well compared to the attempts of using Scrum to manage the same challenge. Scrum is for new product development, after all.

  • https://www.targetprocess.com Michael Dubakov

    @Tobias Mayer OK, in my next post I reveal 5 right reasons to apply Kanban (on my opinion of course). BTW, I don’t agree with Karl about reasons, almost all the same can be achieved in Scrum or XP.

  • http://availagility.wordpress.com Karl Scotland

    @Michael Dubakov I agree those things can be achieved with Scrum and XP. Kanban is another way of achieving those things. At the end of the day, the reason to use any approach is because people understand it, and it gets results. No approach is a silver bullet.

  • http://peripateticaxiom.blogspot.com Keith Braithwaite

    “I personally believe [kanban] works way better than iterative development”

    Really? I keep seeing examples of Kanban boards that seem to show a one-shot linear progression of states for a feature but am repeatable told by kanban proponents that kanban does not require a linear process. I wonder if you really mean “iterative” here.

    The reason that this is of concern to me is that the fight to make room for iteration over software has been a long and hard one—it began in the late sixties, and isn’t over—but the benefits of iteration have been demonstrated again and again, right from the very earliest days of programming. I really don’t want the fashion for kanban to undo all that good work.

  • https://www.targetprocess.com Michael Dubakov

    @Keith Braithwaite This quote is out of context. Full is “I personally believe it works way better than iterative development (for us)”. Note “for us”. I am not saying that Kanban “always” better, it is not. But in our situation it works better.

  • http://agileanarchy.wordpress.com/ Tobias Mayer

    Keith Braithwaite :
    “…I really don’t want the fashion for kanban to undo all that good work.

    I share that concern. And I’d advise people to consider carefully what they are giving up when they give up time-boxed iterations. Boundaries are known to be a very important element in creating an environment for innovation and creativity. Time-box boundaries also help drive sensible prioritization decisions.

  • http://availagility.wordpress.com/ Karl Scotland

    @Tobias Mayer
    Losing time-boxed iterations does not require losing a cadence.
    See http://availagility.wordpress.com/2009/07/21/what-is-cadence/

  • http://agileanarchy.wordpress.com/ Tobias Mayer

    Karl Scotland :
    @Tobias Mayer
    Losing time-boxed iterations does not require losing a cadence.

    I did not imply that it does. Iterative development and cadence are two different things.

  • https://peripateticaxiom.blogspot.com Keith Braithwaite

    @Karl Scotland

    Having time-boxes called “iterations” doesn’t mean that you are doing iterative development. Nor that you aren’t.

  • https://peripateticaxiom.blogspot.com Keith Braithwaite

    @Tobias Mayer
    Let me be clear: I like regular, frequent, scheduled synchronization points at which working software reflecting the investment to date is exhibited and intentions for the future discussed. This has very little to do with iterative development, which is a matter of planned re-work.

    I also don’t like days long stoppages where the “next iteration/sprint/whatever” is planned (which is to say, predicted) so I don’t do them an I recommend my clients not to either.

  • http://availlagility.wordpress.com Karl Scotland

    Keith Braithwaite :
    @Karl Scotland
    Having time-boxes called “iterations” doesn’t mean that you are doing iterative development. Nor that you aren’t.

    That, I think we agree on :)
    Both Time-boxing and Kanban Systems are independent of actual iteration.

  • http://leanandkanban.wordpress.com David Joyce

    “I share that concern. And I’d advise people to consider carefully what they are giving up when they give up time-boxed iterations.”

    Isnt the point that a) each team is different b) as part of continuous improvement or inspect and adapt that people can try things (such as not using time-boxes) and if it works for them and they see improvement then great, rather than jump all over them and say you are no longer Agile!?!?!

  • http://www.bigvisible.com/ George Schlitz

    Great post…I think that kanban applied to SD can be incredibly effective, but I believe that teams that haven't mastered basic fundamentals of success (like completing quality product, collaborating, and much more) will have an incredibly difficult time with it and will just be perpetuating their problems. I like to introduce basic scrum- once they can demonstrate the ability to get things done, retrospect/improve, inspect/adapt/plan, collaborate, and more (including understanding of lean thinking), we can then seek ways to become even more effective- kanban is likely one such way.

  • LameCEO

    thanks for spamming!

  • http://elseinc.com/kanban-simulation-game.html Liza Mellin

    The last part is definitely a ‘bull’s eye’! I mean, why apply Kanban if there’s actually no goal to remove ‘muda’ or ‘wastes’? If a production firm wants to apply a Kanban system, they should realize what its goals are, and what other production systems goes with it (Like the ‘Lean’ System itself and ‘Just-in-Time’ manufacturing)

Get started for free

Sync up your teams with a visual project management tool that adapts to your organization and gives you transparency across different projects and departments. Visualize every step of the way.

Get started