At a first glance, kanban may look nothing more than a simple method to visualize work in progress, but by treating it as ‘just a visual board’ the team might be missing out on the real power of kanban.
So, whatis the real power of kanban? And, what is that ‘waterfall bug’ in Scrum?
Let’s try to understand the ‘waterfall bug’ first and let’s take a common example – a team, proficient enough in technology, has just moved to Scrum. They have completed a few sprints but are struggling to achieve a sustainable pace. Despite team members’ hard work, the velocity somehow keeps going up and down. The code isn’t too clean either – lots of patches are being added towards the end of the Sprint, in their desperate efforts to complete the stories.
Something is seriously wrong somewhere! The general feeling among team members is that it is less about technology and more about rhythm. The team is following all Scrum ceremonies, but still something seems amiss.
Let’s take a closer look.
During sprint planning, team picks five stories for their two week sprint and tasks them out – all assignments and task estimates are done. So far so good. There are five developers and three testers in the team,so when the sprint starts, five developers pick individual stories and starting working while the testers get busy creating test cases. Somewhere around day 5 or so, as development is finished on one of the stories, it is handed over to testers and the developer moves on to help out other developers who may be lagging behind. Collaboration is an important aspect of Agile, after all.
Fast forward to day 8 – testing is in full speed, bugs are being reported and fixed, but development is still in progress for one or two stories – it is almost done though. There is a little panic situation – only one story is completely done. Two more may get done before the end of day 9, but it looks likely that the last two may need to be carried forward to the next sprint. Some members wish development was allowed for a few hours of day 10.
It is a very common scenario that gets reported in almost each one of my trainings. And, to be honest, my first Scrum project went through the exact same scenario – for several sprints. I call this a ‘waterfall bug’ in the Scrum – team is sticking to its old waterfall practice of sequential execution, lack of collaboration and most important of all – too much work in progress.
So, how can kanban help here?
By limiting work in progress – a key kanban practice. I have seen this practice improve the quality of a team’s sprint execution without fail. Here is what the team could do – out of five stories, DO NOT work on more than three stories at a given time. Only when one of three stories is marked ‘done’, the team can pull the fourth one. And then, the fifth one. Work in progress (WIP) limit could also be applied at the task level where one team member is not allowed to work on more than one task at a given time – unless a task is blocked.
Limiting stories in progress necessitates that multiple team members collaborate on one story – via pair programming and/or splitting tasks based on skills (horizontal slicing) or acceptance criteria (vertical slicing). Thanks to this collaboration effort, chances improve that development is done for one of the in-progress stories much earlier – say on day 3 instead of 5, thereby enabling faster feedback loop from testers. As you may guess, the story burn-up will likely see a small increase 2-3 days sooner than when there was no WIP limit in place.
Overall, as commonly seen in kanban systems, limiting WIP helps reduce cycle time – the time a work item takes from start to finish. In our example, stories stay on board for a shorter period of time. 2 to 3 stories may get done before the panic stage of day 8-9, with much better quality. If it gets too late by the time team comes to the last story, they may decide to skip it altogether, thereby focusing their energies on the stories that are already in progress.
The kanban philosophy behind limiting WIP is to ‘stop starting, start finishing’ – it is much more important to finish what you have already started than starting more items. It often sounds counter-intuitive to managers transitioning from waterfall to agile – as limiting WIP may leave resources idle which is against effective resource utilization. But, the key point to note here is – in the agile world, maximizing the ‘finished work coming out’ is a far more important objective than ‘maximizing the work going in’.
To summarize… kanban is great at visualizing work, but if used effectively, it can help teams effectively manage the flow of work on a daily basis – thereby making sure the work flows smoothly and gets done on time. And, if your team cares for ‘work getting done’ but is struggling with Scrum, it may be time you take a closer look at kanban.
No Trainings found
