Scrumban - or How to get Leaner by Sprinting Less

Recap

Earlier this month we examined the problems and pitfalls associated with transitioning from Scrum to Lean Kanban. This typically happens when a Scrum project closes and enters a support and maintenance phase. The context shifts from that of a project, where much of the scope is uncertain, towards Business as Usual (BAU) changes of lower risk. We looked at the differences - both subtle and not so subtle - which often characterise this transformation. We also considered the difference in mindset that accompanies the change in method, and how this can cause problems for otherwise solid agile developers. But we also saw that there are clear synergies between Scrum and Lean Kanban. Both are agile methods and both apply broadly similar practices, such as daily standups and regular retrospectives. Both deliver results of value through ongoing delivery. Both are introspective and self-adapting. Both optimise their value streams as far as possible. Both use information radiators (task boards, Kanban boards) to transmit the state of backlogs, work in progress and to highlight impediments.

The natural question to ask is: can a hybrid approach be formulated which can be sensibly applied to both project and BAU work?

Enter Scrumban

About 4 years ago Corey Ladas wrote an article on a Lean approach he referred to as "Scrumban". This turned out to be a seminal paper on the topic and it still lists at the top of Google results today. Although 4 years old now, it remains well worth reading.

What Ladas did was to propose a mechanism for optimising a leaner, more pull-based system from an existing Scrum instance. This is done by reducing the level of on-hand inventory as far as possible. Batching work up is to be avoided; ideally each work item will be processed in response to a clear signal for demand. Interestingly, he saw this transition as being a worthwhile endeavour in a general sense, and not specifically when moving from project work into a BAU phase. He argued that "if your iteration backlog contains 20 work items, then that's still about 19 more than it needs to be in a pull system". His philosophy towards making Scrum leaner was "…to incrementally enhance Scrum with more and more pull-like features until all that remains of the original process is vestigial scaffolding".

Problems with Lean development as a general solution

However, I see excess risk in applying an uncompromising pull-driven model to application development in general.

In Scrum, iterations (or sprints) allow an emergent project scope to be rebaselined at regular intervals, and for a team to concentrate upon delivery one meaningful release at a time. It is advantageous to use sprints in projects of uncertain scope precisely because they reduce the pull on a product backlog. This reduction can be seen as a form of refactoring. In Scrum there are 2 kinds of pull - firstly the internal pull within a team during a sprint, such as the demand to supply completed user stories for test, and secondly the external pull of a product owner upon the product backlog. This refactoring of pull allows the risks associated with a requirements set to be managed in chunks, or to use the leaner term, in batches. A goal when optimising Lean Kanban systems is to try and reduce the batch size as far as possible…ideally to one. Scrum tempers this pull by batching correlated requirements, and then dealing with them in timeboxes so any associated scope risk can be managed.

Nevertheless, in a sense the Scrumban approach advocated by Ladas can be positioned as a general solution. If you start off with a canonical Scrum instance, you can reasonably expect to de-risk the project on an ongoing basis until such time as the project is delivered and a BAU phase is entered. Seen in that light, the "incremental enhancement of Scrum with more and more pull-like features" is a rational approach. It provides a recipe for managing the transition from project work to Business as Usual.

Ways to generalise Lean for dealing with uncertain scope

But what if a Lean process does have to handle tightly and weakly coupled requirements of uncertain scope? Well, you could always fake sprints in a Lean Kanban model by mapping out an agile release train to operational heartbeats. However this still involves the logical batching of PBI's (Product Backlog Items) which is, effectively, the introduction of sprint backlogs by stealth. You might as well be doing Scrum.

How about an explicit Kanban state for resolving the scope of backlog items? Ladas does this. In his article he split "in process" work into two further states: "specify" and "execute". This seems like a simple and straightforward solution. It might be criticised on the grounds that it makes estimation difficult, since you won't know the complexity of the work until it is specified. But then estimation shouldn't really be part of a lean value flow in the first place - it's the actuals that need to be tracked. So a ticket is simply removed from the backlog, the work specified, then executed, and the velocity and lead times updated. What more is needed?

Well, if each ticket represented an isolated piece of work, then a Kanban state for capturing analysis would be fine. Nothing more would be needed. The problem is that you don't often get such isolated requirements in the backlog of a project. You can expect a backlog of requirements that are tightly as well as weakly coupled in various ways, such as by correlation through features, epics, or themes. It makes no sense to specify a ticket in isolation from its peers if they are highly interdependent. It makes more sense to scope them out as a group in a planning session, and to estimate how much can be done to achieve a specific goal within a set timeframe. That's the rationale behind the Scrum sprint.

One way to get round this in Lean is to raise a ticket specifically for analysis. I've used this technique in the past with mixed results. What you do - upon recognising that the requirements associated with various tickets are related and uncertain - is to add a new ticket into the backlog for the purpose of investigation. Once the analysis ticket is completed and scope has been established, the tickets for doing the actual work are free to be progressed. The big problem with this approach is the management overhead, since there are complex ticket dependencies that will need to be tracked. In effect raising tickets for analysis is a sort of methodological hack. What you are doing is injecting process by having it ride as a ticket payload. You might be doing it with good intent, but in my experience it's a dodgy and rather convoluted practice.

Conclusion: Scrumban Can Scale Both Ways

These workarounds aren't ideal. They involve twisting Lean Kanban - which is optimised for BAU work - to handle scope uncertainty. More conventionally Agile approaches like Scrum and DSDM are geared to handle scope risk "out of the box". Ladas was right when he expressed the shift from one to the other in terms of structural process change. That is what it takes.

However, I don't see Scrumban as only working in one direction. It isn't just about modifying Scrum to perform in a Leaner fashion. It's also about going the other way when you need to…scaling a Lean Kanban up so that it can handle growing requirements uncertainty. This often happen in a BAU environment when you get requests for substantial changes, or multiple related ones, that effectively represent "mini projects". In an earlier post I wrote about how to scale between Lean and Agile practice in response to exactly these demands.

For me, the beauty and utility of Scrumban is its potential to support a "sliding scale" of risk. There is invariably a spectrum of work to be done by a team, whether it be project based or BAU. That's something which agile practitioners need to be able to handle. True agility requires being able to shift the emphasis from sprint to heartbeat, to flex batch sizes, to rescale team practices, and to be sufficiently introspective to make such adjustments in a confident and controlled manner.

In my next post, we'll look at how to get Scrumban up and running with a new project or BAU workstream, and we'll consider the importance of transparency in agile adoption.