Type I Scrumban: A Forensic Approach

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.