How We Mixed Scrum & Kanban to Get the Job Done

After Bart Vermijlen read Lean from the Trenches (a book by Henrik Kniberg) he was very eager to get implementing a combination of Scrum and Kanban in his environment.

The Project

Bart decided to test this approach on a very demanding project, in doing which he was cooperating with a development team, that was already very Agile, without putting any names onto what they did. There was demand on high quality of code and extensive and compact testing.

The beginning

They began by creating a simple, but transparent Kanban board. They put a limit of 5 onto the user story amount and another 5 maximum in the Development. There were also 4 "done" stages - 2 after the design process (1: finished for the creative team, then 2: accepted by the client) and 2 after the development (3: ok, tested by the developers and 4: tested and fine for the client).

The next stage involved getting the backlog full and starting the work. They gathered the already existing user stories, created new ones (by involving a product owner's representative) and at a meeting decided on which they'll add to the board. The team performed estimations on how long things should take, but they had no plans as to how they were going to measure this.

The work and the change

As quickly as 2 weeks after kick-off, it was clear that the board didn't match the process. There were plenty of tasks in the "design done" stage, awaiting approval form the end client, which wasn't coming through and developers had nothing to do. The process was quickly altered to one that completely removed the design parts, going straight to development and following the progress right there. Once the code was developed, there was a "styling" stage to be performed, and the order of tasks was decided on by the team involved, going by what was most progressed.

The result

Once the process had been adapted to the situation, work began to run smoothly. The designers worked alongside the developers, once a week there was a demo, which probably decreased the numbers of bugs and problems later on. Any difficulties that the team had had along the way were visible on the board, there was also a consensus about the overall benefit of being able to view the progress live on the Kanban board.

Final thoughts

The overall process was a success, if Bart was to wish for improvements for the future, they would be: more focus on cycle time and more involvement from the end client (which would speed everything up). All in all - an experiment well worth doing.

Read our article on Kanban for Software Development »