While writing the content for our course, we scour the web for case studies to support the points we’re making. Frequently we find information telling us how something is being done; we rarely find information describing why people have decided to use one practice or another. We feel understanding the why is often the most important aspect. We’ve decided to start including experience reports/case studies sourced directly from the community. As part of that process, we’re posting the output here. In the first of those case studies, we spoke to Tom Howlett (@diaryofscrum) one of the members of the Development team at Biomni. Thanks to Tom for spending time with us to create the case study.
Case Study: Biomni, overlaying kanban
Creating software to assist large organisations structure and manage their IT services to different business user groups, Biomni is now in the 6th generation of its service catalogue offering. The development team has been working together for nearly 10 years and adopted Scrum about five years ago. In each retrospective the same issue came up again and again – a gap seemed to have opened up between the work being processed by the 7 developers and the 2 QAs. In fact, quite often at the end of a sprint a piece of work wasn’t really ‘done’, it still needed some final testing and then a few tweaks of rework.
This might not sound like a great deal, but rather than congratulating themselves on how super-agile they were compared to other companies, the team recognised that continuous improvement meant exactly what it said. Since the problem was primarily one of flow, in 2011 the team decided to overlay kanban on top of their existing working arrangement. The team was distributed, and so the first task was to visualise the workflow in a meaningful way. The team chose the ‘kanbanery’ tool to help them with this, providing a virtual taskboard, that was an almost instant improvement on the spreadsheets they had used previously.
The team took the most important (and painful) step, to create and enforce Work-In-Progress limits. There were immediate effects. Quality Analysts don’t like standing around with nothing to do while the developers create some code. So naturally, they got involved in discussing what kind of tests they ought to be thinking about. The developers pointed out that a lot of the tests were already covered by the unit tests that they wrote as part of coding. The testers shouldn’t waste their time with those – they should focus on all those tricky mind-bending tests that developers didn’t even consider!
Of course, this conversation was always meant to happen anyway, but somehow before it just … hadn’t.
The idea became an explicit process policy: there must be a conversation between developers who worked on the story and QA engineers to establish the best plan for tackling the testing of the story. The Biomni team adopted a name for this conversation – the 3 amigos. A developer, a quality analyst and the Product Owner were expected to get together and discuss ideas up front – everyone got excited as the collaboration started to pay dividends in slightly unexpected areas like integration and regression testing.
Unsurprisingly, the team still had occasional flow problems and bottlenecks. A big queue built up in front of testing at one point, but because strict WIP limits meant that the developers couldn’t just keep cracking on with writing more code, the whole team was forced to swarm in order to crack the flow problem. It gave the whole team a more structured way of dealing with problems and fostered a greater sense of collaboration.
Finally Kanban’s insistence on lead time as a metric, backed up by cumulative flow diagrams to show pinch points, really helped the team focus their energies quickly. It was impossible to build up an internal queue which only came to light at the end of the sprint – instead the flow was something every team member was aware of, and which helped make retrospectives less a matter of subjective opinion and more about the empirical data of their performance. Indeed, so helpful had the enforced conversations been to planning the work, that the idea was mooted to expand the 3 amigos into 4, and include input from customer service representatives into initial development discussions.