Converting a Scrum Team to Kanban

This is a great Kanban use case, showing how a Scrum team had adapted to doing Kanban in order to get out of a lot of overtime, low delivery rate and low quality related trouble.

The situation

At the time this experiment started, the team had been in the 6th month of an 8-month project. They had already reduced the project scope to a minimum, so the only thing that could possibly make a difference now would be the way in which they work. The strong points were the team itself, good communication practice and a good backing up from the management.

The problems

When asked about their main problems, the team reported having to switch between tasks a lot - multitasking. The project manager's view of the main issues was the quality of deliveries, stress levels on the team and completely incorrect estimates.

Introduction of Kanban

The first step was, as usually, simply visualizing the current process on a Kanban board. Also, to there was a WIP limit applied to the working columns. After just two weeks Mattias (the team's Kanban coach) had noticed a pattern - the stories were getting stuck in the test phases. Also, they would often get through the board and get "half done", only to return to the board later on. Because of this, the demoralized team had come to apply the first solution possible, just in order to get the story pushed further, possibly to never have to see it again.

Putting an end to Sprints

One of the next steps along the way was deciding on abolishing Sprints altogether. Since the team wasn't able to deliver the stories needed within a sprint anyway, the feeling was that sticking with the Sprints resulted solely in running the morale down further still. However, they did keep the weekly release cadence though. Thanks to this, if an item didn't get done on time, they weren't pushing it to the following day, it was just made to be released in the upcoming week. More time, less chaos, then.

The main problem resurfaces and gets solved

It very often was the case, that there would be a queue of tasks in the testing stage - as it turned out, the only tester was the Project Manager. This wasn't enough. The answer to this was getting the team trained in Test Driven Development. Once they undergone this training, they themselves began to go back to the problems, that previously had caused the stories to run through the system unfinished.

Policy issues

Changes were also made with regards to how the new stories were allowed into the backlog (previously there was no specific policy on when the client can submit a new request - this caused the team to fall behind with current work).

The team regains control

Once the process was beginning to get streamlined, the team members had begun to take control over what and how they were doing into their own hands. There were new lane policies added and brand new process stages had appeared. The team also learned to recognize the difficulties before they escalated, and got well into the root cause analysis and problem solving techniques. They also decided on setting a weekly conference with the client's team, addressing the common problems and coming to agreed-upon solutions.

Results

The team did manage to meet their demanding deadline, and were soon granted another product contract from their client, which proves success.
In Mattias's view, the thing that made it work in this case was a good combination of many things. Kanban provided clear view into where the problems were. Getting rid of Sprints provided the ability to focus on quality, rather than quantity. Putting a stop to estimates freed-up some extra time too, without causing any damage.

Numbers

The throughput in this process had changed from 7.25 story points to 13.50. Velocity has changed from 0,64 to 1,04. They had also found the time and skill to implement all the improvement fixes they wanted. This goes to show, that where there's a will.. there will be time for the way. On top of this, this company's HR department is now doing Kanban too!

Read more Kanban Case Studies »