Scrum by the Generals

Ok, so Scrum didn't do the trick for you? The teams fail sprints, the product owner can’t predict the releases anyway as there are too much new stuff added to the backlog all the time, the business people does not get anything because they have to wait five weeks for a 1 hour job and the team members complain about the unnecessary burden of actually being held accountable for what they do every day.

So what do we do? It is of course very efficient to look for something newer and better and simply say: The technique doesn't work. It is Scrums fault. Kanban is the new thing and much better. The gurus are really happy about this. They write Scrum vs kanban documents and will offer you a new course called something like Kanban Ninja and charge another $2,500 for it and then come in to mentor your organization for additional dollars. I can too, but before I do that I will try to get you to rethink...

If you can’t get Scrum to work, may it be so that it is something wrong with your organization? You must always adopt the Scrum methodology to your organization, but it must NEVER be done in a way that circumvents the problems you try to get solve. If the planning in two weeks sprints causes problems, the way forward is probably to increase the strategic planning horizon, not to remove the planning. By nature, Kanban is reactive and Scrum proactive and it is essential that the organization and the development is proactive.

I have used Kanban in software development multiple times and here are some of the observations:

Using Kanban in non-development areas works pretty well. If you are starting or running a small company, I would say Kanban is perfect for it. It helps you focus on the most important tasks and is extremely flexible. Here Scrum actually does not really work out as the sprint concept gets a bit artificial...

Kanban can be used instead of Scrum in software development. You still need to inherit a few "optional" features like a product owner and possibly a "Kanban Master" to support the team. However, using Kanban rather than Scrum in software development loses out on two essential points which you need to be aware of:

• The lack of planning can be fatal. The sprint planning will highlight and estimate the complexity of a proposed solution. It will allow for discussions of alternative solutions. This has to be handled in a Kanban situation too, or we risk that low priority work in progress linger on as work in progress, because we can't see the size and scope of it.
• The sprints play a role for the team. It brings a sense of completion and accomplishment. After the demo and retrospective, the team can go out for beers and feel good. If there are distinct releases with specified dates, these may substitute, but on the other hand if you had that you most probably don’t have to contemplate removing sprints. Running a continuous Kanban workflow may risk creating a type of "battle fatigue" with the team, reducing productivity.

So when is it then appropriate with Kanban? The situations I have successfully used it is as a temorary measure in the end of big development projects of completely new products. Here the focus is more on deficiencies, improvements and feedback. Of course it is important to continuously work with quality and feedback, but it is inevitable in an iterative development of a complex system that the feedback gets more and more intense the more complete the development is. By using Kanban rather than scrum, we can significantly shorten these feedback cycles and remove the somewhat unnecessary time of trying to estimate the time it takes to fix an unknown deficiency. This reactive situation will cumulate around the release and rather than getting thrown into a chaos, we use Kanban to adapt to a reactive mode.

As soon as the development is out of its most reactive stage, we need to regain the initiative to continue the development. This should be thoroughly weighted. Starting too early will make the sprints chaotic and waiting too late will delay the control of the development. The key is to have the team focused on the right things and motivated.

Happy introduction of Kanban, but don't do it just because you didn't manage to get Scrum right. Most probably you will find that the problem actually lies elsewhere.

For more information on Kanban vs. scrum, please look at Henriks mini-book Kanban vs. Scrum