Recently I have been working on a project for a new client delivering replacement digital processes for their paper based predecessors. Due to the nature of the work I am unable to provide specifics about the projects but can divulge the approach the team has used to achieve this work.

On day one of my assignment the team and myself were cobbled together and asked to finish off the project which was started six months ago or so. The project has been dormant whilst a third party went away and developed their part of the system in an waterfall way (perhaps i’ll save that experience for another blog!). Whilst a backlog existed it hadn’t been refined for around six months and contained some items that were done, some that weren’t required and was missing a lot of stories that we had to do.

My first instinct was that Scrum was going to be difficult to use in this scenario. Firstly we didn’t have enough work for even a one week sprint on day one and secondly it was clear that the priorities were going to change as we discovered more about the project. For these reasons I suggested to the team we use Kanban. Kanban has roots in Japanese manufacturing and focuses on reducing waste, visualising your workflow and limiting work in progress. It also doesn’t prescribe a time-box like Scrum does with a sprint. A sprint in Scrum locks the scope for that sprint and whilst i am a huge advocate of Scrum we just couldn’t lock the scope down to even a one week sprint. With work to do whilst we worked with the PO to ascertain the full backlog we started with Kanban. We ordered the stories we had by priority and split them into tasks and the team worked on the most important item in the workflow. Throughout the 3 week project lifecycle the priorities changed and new items rose to the top of the board to be worked on next when someone was free.

From the feedback from the team it was quite good for them to know what they should work on next as it was clearly defined by the priority on the board.

When is it best to use Scrum?

As i have mentioned above Scrum is best utilised when the idea of the sprint can be adhered to. The focus of the team for that sprint is what is agreed between the team and PO in sprint planning and whilst I always encourage teams/PO’s to have some flexibility and room for negotiating for the most part the work remains fixed in whatever sprint size you choose. Scrum is also better placed for longer term “product” based development where the product evolves over numerous iterations based on user feedback or prototypes.

In a similar way to Kanban, Scrum acts as a mirror and whilst the approach can bring great changes and improvements in efficiency, quality and morale. Just using Scrum won’t fix all of your problems but it will show them and make them evident to the whole team. These can then be identified and fixed in the sprint retrospective.

When is it best to use Kanban?

Kanban is great for the scenario described above, moving targets or ever evolving requirements that are likely to immediately effect the priorities. I have known a lot of teams to use this approach for support purposes for live systems or when leading up to a large release where bug fixing or other activities done in a hardening sprint may be done.

I’ve also known teams to use a Kanban approach when first moving away from a waterfall approach to an agile approach. The great thing about this approach is immediately allows anyone to see the teams process by visualising it (usually on a wall or online tool such as LeanKit). This is a great way of spotting waste in your process and spotting immediate ways the team can change and improve how they operate.

Something that is becoming quite common is teams using a mix of Scrum and Kanban (more commonly known as “Scrum-ban“) which takes the best of worlds and merges them into a single approach.