Type I Scrumban: A Forensic Approach

In the last article, we considered Agile transformation as a "crime scene" in which managers, who are often derelict in their sponsorship for change, merely pass the problem on to their subordinates. It is left to the teams doing the work at the coal-face to somehow find ways to "become more Agile," and thereby implement a strategic vision for enterprise transformation. This is an undertaking in which they are expected to not only succeed but to accomplish while still doing their day jobs; and all for an organization which does not stop, but which continues in flight. In other words, they are expected to not only implement deep and pervasive change but to continue delivering value, uninterrupted, to an organization which remains essentially unchanged and vested in its old established culture.

This is an unrealistic policy since those teams are typically burdened with extensive dependencies upon organizational resources which are still framed in a non-Agile context. For example, teams may not entirely own their Sprint Backlog and be able to take it through to completion without impediment. Stakeholders may continue in the old vein, with no expectation of having to liaise with, and be represented by, a Product Owner. The overriding imperative is that the old order and its "standards" must be maintained. Yet while this approach to transformation is both contrarian and unrealistic, it is also largely unrecognized. After all, a difficult issue which has been pushed downward can fall off the radar as far as managers are concerned.

The result is that teams have to make do as best they can in order to satisfy the irreconcilable demands which are placed upon them. Agile practices will be emulated as closely as possible, but without fundamentally changing - or threatening - the established order the workforce is still expected to serve.

This is Agile transformation as a crime scene, where Agile initiatives are worn down by friction and no longer bring any hope for real change at all. Instead, a state of hypocrisy and cynicism about Agility becomes the new normal. Agile words are used to describe non-Agile practices. The toothless wheels of a failed transformation can spin for years like this before it is finally admitted that there has been no traction for improvement.

The evidence of this problem can be exposed through transparency. Actual releases into production of empirical value are then shown to be rare, and when they do happen, no hypothesis is validated and no timely lessons are learned. Teamwork is divorced from the outcome of a team's work and Agile practices become unclear or attenuated.

Gathering Evidence

First published in The Agile Zone, 1 March 2017

"The worst crime is faking it." - Kurt CobainBack to the Crime Scene

When investigating an Agile crime scene like this, one of the first things to look for is an information radiator, such as a Scrum task board or a Kanban board. Irrespective of how poor its implementation may be, it still constitutes evidence and allows transparency over problems for those who can interpret it. The majority of teams will have made an attempt at a board of some kind. A team board is an Agile totem and may be politically useful in so far as it lends itself to public display. Remember that a board can be employed for the purposes of Agile theater and play-acting, just as surely as it can be used in the service of genuine Agile practice.

The optics of a fake Daily Scrum held in the general vicinity of a totem task board can look convincing to a naive or desensitized observer. However, the truth will quickly out. For example, you might find:

  • Strange swimlanes and stations with no clear flow.

  • Too much work in progress, with no WIP limits.

  • Odd user stories and tasks left unactioned.

  • Bottlenecks and broken pull.

  • Weak acceptance criteria.

  • A vague understanding of Done.

  • Little evidence of backlog refinement.

  • Poor evidence of ownership.

  • A poor indication of throughput.

  • No evidence of collaboration.

  • No hint at all of any team focus.

That's before you even start looking at the team's actual practices and behaviors, the usefulness of which may have degraded over months or years of succumbing to organizational gravity. In many cases, the Agile crime scene can become more like an archaeological dig. You can find many damaged Agile artifacts, and many broken roles and events. Some of these eventually find their way to the surface, like the scattered evidence of ancient struggles from a plowed-out field.

Faking It: Type I Scrumban

One very important thing to look for is evidence of a team's work-in-progress being pre-empted by unplanned tasks. This can indicate that the team is having work pushed onto them by third parties and that they aren't empowered to self-organize with a clear focus on a shared team commitment. For example, certain team members might be obliged to support products or services they have worked on in the past. In Scrum terms, this can put a Sprint Goal in peril.

Sometimes teams will try to manage these conflicting demands by including an "expedite" or "fast track" lane on their task board. While this might simply be an acknowledgment that not everything can be anticipated in Sprint Planning, it might also indicate that work on the Sprint Backlog is not valued appropriately, and can simply be suspended if a management-level voice shouts loudly enough. The team is still expected to meet their Sprint Goal commitment, but the "real work" of a reactive organization, unchanged by Agile practice, continues to be thrown at them.

In effect, the team has varied their quality of service. Certain value streams are handled differently than others, essentially by giving them a different priority. This is utterly at odds with Scrum practice, where a team should have a clear focus on a single product, and on a Sprint Goal agreed upon with a clear Product Owner.

A variable quality of service is, however, quite compatible with a Lean Kanban way of working where there are no Sprint Goals to violate. A Lean Kanban operation can support multiple value streams, each of which may encompass different terms of support, such as might be represented by a service level agreement. Different products or customers may be afforded a Gold, Silver, or Bronze level resolution time, for example. This is quite typical of Business as Usual (BAU) work, where the risk presented by each change request is expected to be low.

Scrum Teams are best employed in project-type work where complex products of uncertain scope are being developed. In this situation, the ability to set time-boxed Sprint Goals in order to mitigate significant risks is of real use. But when a team is hobbled by the need to vary the quality of service it provides, and to shift its focus on to unrelated activities, it can no longer meet those goals with any degree of surety. Nevertheless, this mode of operation is very common. Sometimes it is referred to as Scrumban, as it combines elements of Scrum with Kanban characteristics.

In truth, this is a bit of a misnomer, since Scrumban was originally proposed as a quite different way-of-working, and was designed to address a different kind of problem, as we shall see. Unfortunately though the name has stuck, and this compromised creature, sewn together of different animals like a Feejee mermaid, is the "Scrumban" we most often find today. We shall, therefore, refer to it here, perhaps a bit too generously, as "Type I Scrumban." It may be seen as a constructive variation on the Scrumban pattern, and not as an anti-pattern, in so far as it can be used as a forensic tool which yields a measure of transparency.

Toward a Better Scrumban

Scrumban was originally described by Corey Ladas. Corey postulated the gradual elimination of Scrum practices in order to achieve a leaner and more Kanban-like way of working. For example, Sprint Backlogs, which can exhibit certain batch-like characteristics, may be challenged and removed in order to improve pull and flow. Corey wanted “…to incrementally enhance Scrum with more and more pull-like features until all that remains of the original process is vestigial scaffolding.” When this is done well, single-piece flow and a very rapid throughput can become achievable. “If your iteration backlog contains 20 work items," Corey argued, "then that’s still about 19 more than it needs to be in a pull system.” Although the term was not in common use at the time (this was 2008), it is evidently a way-of-working which would resonate with today's DevOps movement.

Of course, a Scrumban implementation isn't appropriate in all cases. Sprint Goals do genuinely add value where complexity is high and there are significant risks to be mitigated. Complexity is the very sweet-spot which Scrum is aimed at. But where risks are low or getting lower - such as might reasonably occur as products transition into service and a BAU support mode - then a Scrumban approach can become a rational option.

In the next article, we'll look at Type II Scrumban - the actual implementation of Scrum using Kanban techniques. This is a more mature way of working which can lift an organization out of the crime scene, and set it on the straight and narrow towards honest agile practice.