Over the last couple of years, Kanban has become an increasingly popular method for managing ongoing software development, particularly for small enhancements and fixes. It’s been particularly popular in the Scrum community, where it can be easily adopted as an open-ended rolling iteration, with some useful queuing science thrown in that accelerates the speed of delivery. Avoiding over-production and premature production in an environment of rapid change is very good too. And levelling production moves you towards an even, sustainable pace of delivery.
Being tool & method focused is only half of the story, though. They gain you the external benefits, no question about it. But what’s difficult to express is that implementing Lean-ness well and thoughtfully forces you into continuous improvement. As Mike Rother notes in Toyota Kata, the constraints that Kanban & Heijunka impose force you to confront existing problems (and as we all know: delivery problems are always best confronted). If your implementation goes smoothly, you’ve probably not set it up with enough constraints.
So it is with my newest implementation. This is for a particular technology’s workstream that delivers into a combination of customer projects, defect fixes, small enhancements and ongoing requests, all deriving from multiple stakeholders that don’t communicate with each other.
I deliberately set phase WiP limits generously, so that the process wouldn’t fall over and starve downstream processes on day 1. However, I warned all parties working on the process that we’d be gently reducing limits until it caused pain – that pain’s good, as it highlights process inefficiencies to be resolved. Once resolved, you’re back in the comfort zone, so reduce the limit again, and repeat until achieving the target condition of perfection.
What I hadn’t anticipated was that we’d start finding and fixing problems much faster.
The problem we’ve faced with this workstream for ever is that the team is overloaded and the business stakeholders have never had their expectations managed. They mail individual team-members with demands (not even requests sometimes) and expect instant turnaround. Prioritisation is a combination of ‘Who is currently shouting the loudest?’ and ‘Obey the HiPPO‘, while providing enough requirement detail to fulfil the work happens consistently closer to the next release than is healthy for the team (or our overtime budget). So work is regularly rushed and quality often sags below the acceptable.
In the team training before starting, I’d been clear that all work would go into a common backlog queue and the team would work to a defined set of prioritisation rules; jobs could be marked as higher priority and remain within WiP limits, but we could react to rush jobs by specifically agreeing what would be blocked in the mean time if WiP limits are compromised. Absent anything more specific negotiated, FIFO would rule. Of course, if everything’s marked as Priority or Urgent, FIFO still rules — if everything’s prioritised, nothing is.
Using those rules, we expected a client stakeholder to always be able to mark the backlog with the next N items to work on.
On day 1 of the new process being in operation, the client stakeholder we expected to do that prioritisation asked the pertinent question “Has the business been brought up to speed with this?” Of course, the answer was no — managing business stakeholders is outside our realm of control. But it opened a conversation that we’ve been trying to have for a year: “Dear business: understand that we have a limited throughput and demanding more & faster won’t work beyond the odd exception“
Next day, that same stakeholder declared that it wasn’t up to him to do prioritisation. Well that’s a brilliant starter. I’d feared that he’d just passively fail to do it, and make it difficult to replace him. So again, he’s opened a conversation about who should be doing it that I didn’t expect to be able to have for months.
Today (day 4) we finally started getting some jobs onto the board – stakeholders continued to mail the team-members directly. So we pushed them all into a common backlog, and worked on them in FIFO order (as we didn’t have any more specific prioritisation to work on). Pretty soon, our Dev phase was full — even given the generous limits — with an increasing number of items marked as ‘Ready to pull’ (ie can be pulled into the next phase, which is an internal peer review). And there they stuck. So per Kanban rules, once that phase hit its limit, work stopped.I spotted this in about 20 minutes (this is only one of many workstreams I own, but I was paying regular attention to it, being week 1). Another problem highlighted: who was doing peer review? It turned out that my onsite and offshore leads had a different view on what the approach should be, but they both shared the view that we didn’t have time to do this activity that has a direct link to quality.
Right, so that’s 2 more problems confronted: we now have a common view on who should be doing it, and it lets me open a(nother) conversation with the client: here’s the cycle time with peer review – this is the standard with the acceptable level of quality. If you want it instantly shorter, then you make the decision to skip quality phases and accept lower quality (naturally, I expect cycle time & quality to improve over time anyway, but you can’t shortcut the kaizen needed to make that work).
These are all real problems that we’ve been facing in this workstream for a year, and we’ve been unable to get any traction on them. All found and pointed in the direction of resolution within a week. I fully expect that we’ll find more problems tomorrow, and we’ll be forced to confront them and start talking about how to fix them.
This may be equally true of other methodologies, and it may be a one-off co-incidence but I’ve never before seen such progress on such substantive blockers in such a short time.