Type II Scrumban: Going Straight

"To rule a country of a thousand chariots, there must be reverent attention to business, and sincerity; economy in expenditure, and love for men; and the employment of the people at the proper seasons” - Confucius 

Goodbye to Crime

In the previous article we looked at Scrum as it is all too often found in the field, which is to say, when it is broken. We’ve examined the evidence of agile transformation as a "crime scene", where dysfunctional organisations latch on to agility in the hope of gaining advantage, while failing to sponsor the deep and pervasive change which Scrum in truth requires. We’ve seen how development teams end up being squeezed, as competing commitments and contradictions are pushed downwards from management and left to employees to deal with. Hornswoggled out of the promised ability to commit to and focus on a Sprint Goal, teams find that they must still support the reactive demands of an unchanged enterprise which continues around them.

We also looked at how teams might respond to the swindle by combining Scrum and Kanban practices, so these competing demands can be better supported, or at least made a bit more transparent. Perhaps controversially, we’ve further accepted that such a hybrid operating model can be referred to as a variant of Scrumban. It's a dirty way of doing things, and very different to the framework envisioned when Scrumban was first proposed by Corey Ladas. In fact some may choose to see this variant as more of a “Scrum-But" anti-pattern, rather than as a good-and-true pattern for use by decent and upstanding agile citizens. I’m not going to pass judgment on that matter here. All I’ll say about the controversial “Type I Scrumban” variant we saw last time is that agility can be a bit like the martial arts. There are certain techniques for the dojo and there are other methods best left for the gutter.

In this post we’ll rise above the crime scene and turn our gaze towards a nobler agile practice. This may be referred to as "Type II Scrumban”. In fact, what we are about to see broadly corresponds to a foundational level of the genuine Scrumban which Ladas originally articulated. Remember that Scrumban is meant to be a journey from Scrum towards a “leaner" way-of-working, one in which the scaffolding needed to operate a Sprint is gradually removed, and continuous flow is achieved. Clearly, this supposes that a team and its supporting organisation have the agile maturity to implement Scrum properly in the first place, and that they have developed the competence to challenge essential rules, and know when to do it. It won’t be enough to have “simply” mastered Scrum, enormously hard though that is. It takes genius to dismantle the Scrum Framework around you while still delivering value, assuming you have implemented it correctly at all. The key inspect-and-adapt opportunities of Sprint Planning, holding a Sprint Review, and conducting a Sprint Retrospective will no longer be there. A huge breadth and depth of experience is needed if this is to be done without compromising the flow of value. This includes being able to recognise that a domain has become non-complex, that Sprint Goals are truly no longer useful in a particular case, and that Sprints are genuinely emerging as a constraint to lean flow. Back in the gutter, Scrum can’t be challenged in a useful way because it is never mastered properly to begin with, although there is no shortage of rats who think they’re experts.

Implementing the Scrum Framework with Kanban

The foundation for Type II Scrumban can therefore be laid out as follows. First and foremost, it is Scrum. It is Scrum with nothing taken out, and implemented very well. It is an implementation of the Scrum Framework which has been optimised, by expert team members, into a superlatively efficient expression of lean practice. At this level of performance, each Sprint will be a case study in the achievement of lean flow. The delivery of value will be empirically evidenced, and the value added at each stage of development will be transparent and well understood. To achieve and demonstrate this accomplishment, each Sprint will be implemented as a Kanban.

It’s worth pausing to reflect on what Kanban actually means for most Scrum Teams regardless of their degree of agile maturity. Most teams do in fact try to emulate a Kanban in some form, often quite unwittingly, by approximating the associated behaviours. For example, they will usually make an attempt at providing an information radiator, and at modelling stations through which work is expected to flow, and at limiting work-in-progress once a Sprint has begun. However none of these are technically Scrum practices. The Scrum Guide does not prescribe them, nor indeed does it have much to say about them at all. Rather, they are left as an implementation matter about how to best apply the Scrum Framework. Of course these particular techniques have proven to be very useful, and as such they have become something of a convention. As a result, most teams will either use them or aspire towards doing so, perhaps even assuming that they are part of the framework itself.

In Type II Scrumban - which is the foundational level of Scrumban proper - we can discern a Scrum-Kanban model at its most fully accomplished. A Kanban system will not be merely emulated in some way, but genuinely realised. Each Sprint will demonstrate the leanest possible flow, and minimal waste will be incurred when attaining the Sprint Goals that were agreed upon. Now we’ll look at what this greater accomplishment means in practice.

Kanban as a closed economy

The first thing to understand about a Kanban system is that it isn’t just a glorified To-Do list on a whiteboard. Yet that is typically what we find across the software industry today - a pseudo-Kanban of work with two or more columns added to the right hand side of a “backlog". Work is taken out of the backlog, moved to an “in progress” column, and eventually moved into a “Done” state. The only concession to lean or agile conduct might be the limitation of work-in-progress to a definite quantity, so that some sort of team focus can be applied. Even that small exercise in discipline may be absent.

In truth though, a Kanban is far more than the outward expression of value and flow. It’s a model of production in which the size of the economy is managed and optimised. At a geopolitical scale, this is done by means of national currencies - such as dollars, pounds, or euros - which are generally recognised as being placeholders for value. Each banknote is a placeholder for work done in an economy in which value is added. That’s also what a Kanban card is, or should be: a placeholder for value which is in circulation. The clear implication is that if a Kanban is implemented properly, then each card will also circulate. No new cards may be added until an existing one becomes available. For example, no work will be brought into progress unless a card for doing that work is released from the “Done” column. This discipline, of course, is one in which many teams are found wanting. They just add cards like an incompetent government might simply print money. The amount in circulation increases, but the value of each token is reduced, because less is going to be done in a timely manner. Irrespective of demand, the economy still has a finite capacity for supplying work. The trick is to have just enough currency in circulation to satisfy the pull in the system. Any more or less will result in waste.

A simpler and more immediate metaphor can further reinforce the principle. Corey Ladas uses the example of “Coffee Cup Kanban” to illustrate how a well-managed economic model of production can be applied in a localised way by small teams. We’ve all seen it. Go into a coffee shop during the morning rush hour, when demand is high, and you’ll likely see a Kanban system in effect. The queue of people waiting to place their order is the backlog. When a customer reaches the counter and places their order, the essential information will be recorded on the cardboard cup with a marker pen - coffee type, how many shots, black, skim or whole, decaf or real. The cup itself effectively represents the work to be done. Only a certain number of cups can be worked on at any time, because there will be a finite number of baristas and espresso machines. Hence if the person taking the orders allows them to be pushed through without regard to this constraint, the cups will build up in-process and will sit idle between stations until they are worked on. That’s waste. If a cup has been filled and is waiting for a lid to be put on and handed to the customer, it’s getting cold without delivering value. The work done and the investment made is depreciating as the cup sits there.

A well-run coffee shop will have enough staff and equipment to handle demand smoothly, so that a new order is taken as soon as an existing one is fulfilled. The flow of value will be determined not by the push of customers at the entrance, but by the pull of newly available capacity as each one receives their order. The difficulty the coffee shop faces is that demand is not always consistent throughout the day. After 9am it will most likely tail off until the lunchtime crowd rolls in. With finite staff and equipment at the shop’s disposal, the optimisation of the flow within the system is therefore critical. Hence staff ought to be cross-trained in all of the disciplines needed in the shop. No job can be too complex or trivial, whether it is crafting the fanciest coffee, clearing spills, or putting the lid on a regular black decaf. If there is any hint of work backing-up in the system, someone will move to progress it further before any new work is taken on.

Lessons for us all

The well-run coffee shop does not therefore merely provide us with our morning fix, but can also offer us lessons in value, flow, and quality. There’s a certain irony in the situation where managers espousing lean practice, each earning perhaps £100,000 a year or more, are out-skilled by those bringing in maybe a tenth of that. The most efficient Kanban system in a large enterprise is often to be found in the cafeteria.

What this shows is that the implementation of a Kanban system in the context of a Scrum Team, where each Sprint is managed as a closed economy of a certain size, is both achievable and may indeed be desirable. Work isn't just cards or sticky-notes on a wall, or represented as electronic tickets in some form. Each item betokens a corresponding discipline in the production and delivery of value. Work in progress will be limited. The delivery of value will be pull-driven. Team members will be able and keen to help their peers. Scrum is a framework to be implemented as effectively as possible, and the considered implementation of lean practice will increase the chances of each Sprint Goal being met.

In the next article in this series, we’ll look at Scrumban in its most mature form. We’ll see how a skilled team can learn to distinguish between the engineering contexts which are appropriate for Scrum and Sprint-based delivery, and those which may warrant a different agile way-of-working.