Edge of Chaos

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 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.