Show all posts
8 years ago

5 Right Reasons to Apply Kanban

In previous post I mentioned 5 wrong reasons to apply Kanban. Tobias Mayer asked to blog about 5 right reasons 🙂 Obviously there should be right reasons, otherwise Kanban adoption would fail everywhere. So there they go:

#1. Ability to release anytime

In Scrum or XP you can't release in the middle of an iteration. In Kanban you may release anytime. When user story is ready, you may release it. Definitely it is a challenge to setup development process this way. It is required to have "branch-by-feature" source control policy, merge often, integrate and test often. But it gives you an ability to release often. That is something worth to fight for.

As a PO I like this ability very much. An important user story implemented? OK, let's release it tomorrow in v.2.15.2. Our customers may benefit from this release as soon as possible. Lead time is faster — customers are happier.

One thing to mention — you need to have a good automated test suite, otherwise it will be problematic to make small releases with a good quality.

#2. Ability to change priorities on the fly

In Scrum you can't add stories on the fly into sprint (usually). At least it is not an easy process and development team often resists to replacing a story from Sprint backlog. The story has been discussed, estimated etc. A new story may be discussed in a hurry, some details will be missed and as a result significant re-work will be required. So in general iteration or sprint should be frozen.

In Kanban if you have an urgent request to implement or a really important user story, you can just put it on top of the queue. It will be taken as soon as a free slot is available. It is simply a Product Owner's dream 🙂

#3. No need in iterations

Why you need iterations? Initially iterations help to reveal real problems in the development process quickly. Further on they establish a project rhythm and rituals. However at some point in project I think you no longer need them.

My vision is that you need to iterate first, then flow. Our backlog is fuzzy now, plans change often. We learn how to do agile in general and iterations are not helpful there anymore. Without iterations there is no need in iteration planning and iteration demo meetings. They are waste. Instead we have more smaller just-in-time meetings with people in a feature-team before starting the development for each user story.  It works perfect.

Some people are missing the rhythm, but I think it is more to habit. Kanban establishes more complex rhythm and it may take time for development team to recognize it. Still stable rhythm may be the only reason to keep iterations in the late phase of product development, in my opinion.

#4. No need in estimates

Why you need estimates? In iterative development you need them to predict how many stories you may take in the next iteration. You may even predict a release date based on estimated backlog and iteration velocity. The other reason is that PO wants to know how big the user story is. If it is big enough, PO  may consider moving it to the next release. If it is small, PO may decide to put it into the next iteration.

Obviously, iterative development is hardly possible without estimates. But if you drop iterations, it is not a problem anymore. Can Product Owner live without estimates? Well, yes. In our company we don't estimate user stories. Why not? Because I as a PO don't need them and we don't use iterations. All I may ask is a very rough estimate like  normal, large, very large.

In our situation (I stress that, in our situation), estimates are waste. We don't spend time on estimates. We have a prioritized backlog and just take the most important user story and implement it. It may not work in some conditions, but we have quite a mature product and hundreds requests from customers. There is no clean field development, so normally we don't have any defined release date. We release when it is ready (I understand that many companies can't do that, but we have this favor).

#5. Perfect flow visualization

Kanban Board provides a very clear view on current work in progress. It visualizes flow and enables fast planning and tracking. It is really a great tool, we love it.

Kanban Board

  • Michael Dubakov

    Reply from Dzone by antych

    Where do you people learn Scrum?
    #1 Nothing is stopping you from releasing before the sprint is over. If a feature is done than it’s tested and ready for production, go ahead and release it.
    #2 Sure you can add urgent stories to the sprint, after PO agrees to take something less urgent out. There might be issues that need fixing immediately. Just because you planned a sprint doesn’t mean you can ignore reality until it’s over.
    #3 You use iterations to re-plan and re-estimate in an organised way. They are only a waste if you do maintenance without a deadline.
    #4 You need estimates if your business wants a deadline, which is almost always the case.
    #5 You have pretty much the same board in Scrum.

    Don’t get me wrong, I like Kanban, it’s a perfect fit for some types of projects and organisations, but it’s not a remedy for a botched Scrum. Unfortunately, it’s recently advertised as a silver bullet for those who failed at Scrum. Considering there’s even less planning and control (as perceived by the business) and it’s even more “radical” than Scrum from a traditional project management perspective, I think you’re even more likely to fail with Kanban than you are with Scrum.

  • Derick Bailey

    Hey Michael,

    I started to post a response in your comments, but the size of the response got out of hand, so I posted it via my blog, here:

  • Ian Fergus

    There is a danger that the use of language such as “No Need for Iterations” can lead to confusion and that principles are interpreted either too literally or taken out of context. All the reasons for not using Kanban and all the reasons to use Kanban are all valid provided they are highly qualified as options for consideration – and not commandments.

    We have multiple backlogs for a large number of customers and more than one kanban depending on the class of service, we estimate some work items, but not others, we provide feature/story based delivery to some customers that want that and time-boxed scheduled release for others that prefer a regular cadence. I can go on …

    The main theme is that we need to deliver quality our customers when they want it, in a manner that works for both the delivery team and the customer. Kanban and agile methods in general provide us with a rich set of options to choose from. Make a choice, inspect and adapt – it’s as simple and as hard as that.

  • Katie Playfair

    1. Ability to release anytime –
    For some Scrum teams, “Approved by x, y and z” and then “deployed to website” could be acceptance criteria for a user story. There may not be a reason to release only at the end of an iteration. Seriously though, if you’re doing short enough iterations, why would this be an issue?

    2. Ability to change priorities on the fly –
    I would suggest reading “Slack” by Tom DeMarco. He goes into the costs of task-switching in detail. Keeping a team focused on tangible short-term goals is important when doing intellectual work like software development. Chaos and task-switching leads to lower quality output of work. If you review locus of control studies in psychology, you’ll also see that there are health benefits to giving workers control over as much of their work day as operationally possible. What might be a product owner’s dream can be a team members’ nightmare.

    3. Iterations –
    Iterations provide structure that allows for inspect-and-adapt cycles necessary for technical quality, organizational quality, team and management quality, and a myriad of other adjustments that make organizations and their products more positive. Additionally within an iteration, workers have control over their day to day activities within the reasonable constraints of an iteration – going back to locus of control and health outcomes.

    4. Why estimate?
    How do you do release planning or make reasonable commitments without estimates? What large organization is OK with total unpredictability over what features will be released by which date? Sure, if you’re under no constraints with regard to date or feature delivery, estimates don’t matter I suppose.

    5. Kanban boards look almost exactly like taskboards in Scrum.

    Kanban was invented as a supply chain management technique for Toyota parts –…. I’m not sure if it’s exactly relevant to software development, particularly enterprise software development.

    When we start letting to of the feedback loops, retrospectives, and inspect-and-adapt cycles so important in Scrum and in other iterative and incremental agile techniques, I’m afraid we lose the real juice that’s making Scrum in particular, so successful for Fortune 500 companies. I don’t mean to be a party pooper but I’m just not sure Kanban is worth all the talk I hear about it recently.

  • Michael Dubakov

    I think it was better to name the post “5 Reasons Why We Switched to Kanban”. I do not promote Kanban for everyone and I do believe that iterative development works better for numerous cases. Kanban works for us very good. Period.

    Our dev. team does not have problems with focus. Short terms plans are known and we have meetings to discuss them when required.

    There is no multitasking. Task switching has not only negative, but also positive effects (fast knowledge transfer). Promiscuous pair programming is an extreme case of task switching. There are teams that switch pairs in 90 minutes! With great results. We did not try that so far, but we switch pairs each day.

    We have retrospectives each 2 weeks. We do not need iterations to inspect and adapt.

    We do not have deadlines, so we do not need estimates.

    As you see, there are many “we” in this comment. What works for us, may not work for most companies. But I do think that ISV companies with own products may follow Kanban with great success.

  • William Pietri

    I think you’ve set up a false dichotomy here. “Iterate, then flow” is one model. But for years, I’ve been coaching teams that could be describe as “iterate and flow.” They do iterations, but they also focus on minimum work in process and always being releasable. It’s perfectly possible to get #1, #2, and #5 in the context of iterations and estimation.

    Even if you don’t have deadlines, estimation can be handy. Without cost information, cost-benefit tradeoffs are much harder to make. Estimates can help with coordination and expectation-setting as well.

    That’s not to say everybody should do estimates or iterations, by the way; I think the rise of Kanban approaches is great, and I encourage it. But even if you have to do iterations, flow is achievable.

  • William Pietri

    @Katie Playfair

    Hi, Katie.

    Regardless of iteration boundaries, I think all teams should strive to be always releasable. Getting the chaos contained in iteration-sized boxes is only the first step of becoming Agile. With continuous improvement, teams eventually shrink the chaos enough that they can release trunk at any point.

    Once you’ve achieved that, the question isn’t “why should we release more often?” It’s “Why should we wait until the end of iteration to release?”

    Also, changing priorities on the fly isn’t about wasteful task switching. Indeed, the ability to change is maximized when you minimize task switching. Why? Suppose the team takes on 6 stories this week. If they only have 1 or 2 in progress at any point, then task switching is limited, because there just aren’t that many things to switch to. But that means the untouched stories can be swapped at any time without harm to the iteration, just as long as the stories are the same size.

  • Simon

    Good post, Michael.

    One question: how do you prioritise effectively with no estimates or only rough estimates? Do you not need an estimate in order to perform a quick cost/benefit analysis of any potential work?

  • Michael Dubakov

    @William Pietri I pretty much agree with you. Indeed it is possible to flow with iterations, so maybe the title of the post is not good enough. But also I think that in most cases if you may flow, iterations may not provide any additional value anymore. It depends of course (as always).

  • Michael Dubakov

    @Simon Prioritization is one of the most complex thing to do. PO has so many forces to consider making the decision. Estimation is just one of the force and to me it’s one of the least important. There other are:

    1. End user votes
    2. Own PO vision of the product
    3. Balancing between usability, simplicity and functionality
    4. Some external factors like important customer to please (we avoid this as possible, but large contracts sometimes demands custom features)
    5. Expenses (here is where estimates are required)

    If the feature requested by many end users, if it aligns with PO vision and improve usability for example, I don’t care much about estimate. It should be implemented anyway.

  • Pablo Pernot

    Hello, your two articles about Kanban are very interesting. But obviously you are in a software editor position. I wonder how it could work when dealing with customers and contract. For us -system integrators- it’s hard theses days (in France) to deal with customers around agile methods, especially due to “engagement area” or “result target” and not velocity/iteration/ROI. So introduce no iteration and no estimation (I know this is not quite that) is hard to setup for business/customers/contract. Even If I agree with the idea.


    (hope my english is not so terrible, you understand I’m french…).

  • Vlad

    Interesting stuff!

  • ashga

    Great Article!

    You have a really interesting perspective on Kanban 🙂

    Not sure I fully understand #2. Ability to change priorities on the fly

    I would encourage the team to accommodate to changing business priorities as long as they are removing stuff from the sprint as well as adding. It can work in scrum.