Why We Dropped Scrum for Kanban Just Before Launch

Following is a great story showing that there is not a bad time for changing the way you do things, as proven by this team, who changed their software development process from Scrum to Kanban right before a release, and made a success of it.

The situation: changing environment in Scrum

The team was about to do the last Sprint before launch of the product. But they were facing some difficulties:

• A crucial developer would have been absent during that “last push” period
• They were going to release the product to small media circle, for getting early feedback, possibly teaching them something they have no idea about (fresh problems with no set solutions)
• There was a possibility of external source of added demand, needing them to add tasks to the last Sprint (not really possible in Scrum)
• The product still needed a lot of work done, the features awaiting were of a varied priority, and of course the stakeholders were waiting on all of them, but capacity was limited – demand on prioritization
• The team was already overworked, which put a question mark over the quality of the last changes done and coming
• This sprint had been overlapping with Easter holidays (never a good time for setting deadlines)

The solution: Kanban

All these problems had been raised at the previous Scrum retrospective. In order to resolve them, deliver the product on time, minimize the effects of the main developer's absence, get the ability to respond to the changing environment, maintain the quality of the work and stay Agile – they decided to do Kanban. Limiting the Work In Progress, visualizing the process, hands-on management of the process and evolutionary improvement seemed to foot the bill perfectly.

WIP limits and daily Stand-Ups

They got started with mapping out their ideal process and applying WIP limits to all stages. They also held a daily meeting with the product owner, and were deploying work on a daily basis to avoid problems later on. During the meetings they were discussing whether the process works at all, if there are any bottlenecks, issues and whether the product owner had any requests. This way they managed to remain on top of a changing scenario. The team had also begun displaying the Kanban board on a wall in front of the developers closely monitoring their WIP and overall process.

Result

Their greatest concern was that the Product Owner will not be happy being denied Sprint-like commitments from the team, but it turned out he appreciated the ability to see the process changes as they happen. Wins all round, then, as the development had been a success. Brendan is not trying to suggest Kanban's superiority over Scrum, but he remains certain that what they've achieved with such a success has to be attributed to the changed approach to the way they had worked. So, in this case, Kanban was the only reasonable way to go.

Read our article on Scrum & Kanban »