Type III Scrumban: A Journey

Such posturing and fakery is very common. Due to its prevalence we have grudgingly categorized it as "Type I Scrumban", even though it bears little or no resemblance to Scrumban proper. Yet in its mitigation, we've also seen how “Type I Scrumban” can provide value as a forensic tool when treating a fake agile transformation as a "crime scene".

In the last post, we took a step towards achieving a more honest agile practice. We looked at how Scrum Sprints can genuinely be implemented in Kanban fashion by treating them as a closed economic model of production. The "Coffee-Cup Kanban" analogy was used to illustrate the underlying principles. This "Type II Scrumban" demands great rigor and discipline in both Scrum and Kanban, and to a degree which is rarely found in the industry. However, this level of accomplishment is essential if the journey from Scrum to Kanban is to be understood and successfully undertaken.

In this third article, we'll take a look at what that journey actually involves. 

Is Your Journey Really Necessary?

The first thing to consider is whether a journey from Scrum to Kanban ought to be undertaken at all. To certain advocates within the Kanban community this might seem tantamount to questioning an article of faith. In this view, of course a team should hope to evolve from a Scrum way-of-working towards a “leaner” and more Kanban-oriented one. The perceived logical imperative for doing so can be summarized as follows:

• Each Scrum Sprint Backlog is considered to be a batch of work. That “batch” is seen to consist of multiple items, all of which will have been planned for completion within a Sprint time-box that may be as long as a month.

• The “pull” for delivery is thus constrained to the size of that batch and the corresponding Sprint timescale. Pull from business stakeholders is thereby compromised, because it cannot be applied to an individual item within that batch.

• Moreover, the value of work-in-progress will depreciate over the course of the Sprint, and single piece flow cannot be achieved even in theory.

Hence unless the scaffolding of the Scrum Sprint is removed, it is believed, the team’s way-of-working will never be as lean as it could be. In other words the Scrum caterpillar might inch along, but without the chrysalis of Scrumban it can never reach its butterfly potential.

However, a deeper understanding of Scrum will expose flaws in this logic. A Sprint Backlog is not in truth a batch, although it may superficially resemble one. Instead it is fairer to describe a Sprint Backlog as a plan, or as a forecast of work. It is the work the Development Team expect will be necessary to achieve a “Sprint Goal” which has been agreed with the Product Owner. That forecast may be subject to replanning at any point, as the Sprint progresses and as the team’s understanding of the scope improves. Clearly then, if a Sprint Backlog is a batch, then it is a very mutable one, and it stretches the semantics of what is meant by a batch at all.

Remember that although the team may very well commit to achieving the Sprint Goal, they would be very unlikely to commit to the forecast represented by the Sprint Backlog. That isn’t what a forecast is meant for. It’s expected to change. Work in the Sprint Backlog can be modified, or taken out, and new work can be planned in. Furthermore, the team are free to plan for releases of accrued value at multiple points during the Sprint, or indeed to deploy completed work into production on an ongoing basis. The achievement of a Sprint Goal does not necessarily articulate into the delivery of an atomic end-of-sprint increment. The notion of the Sprint Backlog as being a “batch” of work quickly turns to vapor.

We should also keep in mind the essential purpose of a Sprint. In Scrum, a Sprint is not undertaken in order to complete the Sprint Backlog, which is merely the forecast of work, but rather in order to achieve the Sprint Goal. A good Sprint Backlog, as an up-to-date plan and forecast of the work currently believed to be involved, ought to serve that singular purpose. A good Sprint Goal will give coherence to the Development Team’s effort. It will mitigate a significant portion of the development risk which is inherent to the delivery of complex systems, and will encourage team focus and commitment towards doing so each and every Sprint.

Exploring the Significance of Risk

Let’s consider a rudimentary example. Suppose a Scrum Development Team developing an e-commerce site agrees to the Sprint Goal of making a shopping cart available. They might plan items on their Sprint Backlog such as “List contents”, “Add to cart”, “Remove from cart”, “Change Quantity”, and “Total the cost”. Yet those items merely represent a forecast of the work that will be involved. The Sprint Goal may be achieved differently, such as by refactoring those Sprint Backlog items into “Change cart contents” and “Proceed to checkout”. If the team discover that this is a smarter way to achieve the agreed Goal of making a shopping cart available, they may replan their Sprint Backlog in such a fashion. The Goal would still be met, even though the forecast of work in the Sprint Backlog was revised extensively.

If the apparatus of the Sprint were to be dismantled, then we could not expect this operating model to hold. If the largest endeavor that can be undertaken is represented by a particular backlog item of a certain scope, then that also represents the largest development risk which the team can plan to address. A Sprint Goal on the other hand represents a greater coherence of items and makes it immanent. It allows significant risks to be mitigated regularly and on-cadence.

The decision to move from a Scrum way-of-working to Kanban is not a trivial one, and it should not be seen as an imperative or as a stage in gaining agile maturity. The journey only makes sense in certain cases. Remember that the Scrum Framework is based on the execution of a Sprint, and a Sprint stands or falls on the usefulness of meeting a Sprint Goal. Bear in mind too that the very first line of the Scrum Guide says that “Scrum is a framework for developing and sustaining complex products”. The implication is that products with few unknowns - perhaps even otherwise quite complicated products - are not necessarily suitable for a Scrum way-of-working and Kanban may be more appropriate. However, if a team is actually working on a complex product where there are indeed significant unknowns, then Sprints and Sprint Goals might be useful. A journey from Scrum to Kanban isn’t quite the “no-brainer” decision which some assume it to be.

When Scrum to Kanban Makes Sense

There is a clear and well-established context, however, for which a “journey” from Scrum towards Kanban often becomes a rational choice. This is the situation where the product’s evolution has stabilized, and the organizational interest shifts away from the project as a vehicle for value delivery, and towards a “business-as-usual” mode of ongoing operational support.

The defining characteristic of this switch is that significant risk has been mitigated by this point. The original “complex product” has become better understood, Sprint by Sprint, and comparatively few unknowns are thought likely to remain. As a result, it’s becoming harder to find and articulate meaningful Sprint Goals. Instead, work is seen to have become rather “bitty”. Most of the items on the Product Backlog might now be concerned with support matters rather than changes in product scope. The greater part of these incoming “support tickets” may represent administrative tasks, and many of those might be repeatable and easily templated.

One approach to this change is to have a team work on different products in alternate Sprints, possibly in rotation. Each Sprint Goal might then be to service the relevant product. That might provide enough of a coherence to give the team focus. Also, Sprints may become shorter in order to minimize the cost of delay in actioning work for any given product. Obviously this approach is not without its problems. For one thing, a Scrum Team cannot be expected to drop its work on one product in order to deal with another, even if there is a priority incident such as a major outage. A Scrum Development Team must be allowed to focus on its planned and agreed commitment for the duration of the Sprint. A Scrum Team’s quality of service is not expected to vary as it might do for a Kanban, where different service levels and the pre-empting of work can be agreed. However, if the complexity of product scope which defines the sweet-spot of Scrum can no longer be found, then the rationale for using the Scrum Framework becomes less clear. To put it another way, if the Guide’s assertion that “Scrum is a framework for developing and sustaining complex products” constitutes a pre-condition for its use, then of course there will be situations where that invariant either does not hold or ceases to hold. Kanban beckons.

Removing the Sprint Scaffolding

The first step towards achieving leaner flow is to separate the forecasting of work from the observation of cadence. A Sprint Backlog is no longer appropriate when there are no meaningful Sprint Goals to be met, and the value to be had from observing a Sprint at all is weakened. Instead, work can be planned from the Product Backlog into a Scrumban “Team Backlog”. Unlike a Sprint Backlog, where planning occurs regularly on cadence, work is planned into a Scrumban Team Backlog when the amount remaining shrinks to a certain level. In effect, the replenishment of the Team Backlog is triggered once it has been emptied to a certain point. It is not triggered by cadence or by dates on a calendar. The pull on backlog items is allowed to take over.

Ironically, this means that a Scrumban Team Backlog is potentially more batch-like in nature than a Sprint Backlog. There is no Sprint forecast to be made or to subsequently revise. There is no Sprint Goal to replan for, or to serve. Hence the work in the Team Backlog may prove to be rather less mutable than a Sprint Backlog would be. In fact, any such replanning may be seen as waste. That’s the critical point, and there is an incentive to reduce the size of the batch so that the opportunity for such waste to occur is minimized. Ideally the batch size will be exactly one, a situation known as Single Piece Flow. In practice however this may not be optimal, or even achievable. A significant limiting factor is the overhead which is involved in planning. If the trigger point for replenishing the Team Backlog is set too low - such as one or two items - then the team will need to replan their backlog more often, and potentially more reactively. The buffer of work should therefore be just large enough to bring the demand for planning under control. In a Kanban system, maintaining small levels of inventory can help to smooth out flow.

More Empiricism, Less Estimation

Ken Schwaber once told me: “The only reason for estimating is for a team to get its arms around how much they should try to take on. Any more estimating than that is, as Mary P says, waste”. In the context of Sprint Planning, some sort of estimation clearly makes sense. The Development Team are planning to “take on” some work in order to meet a Sprint Goal within the Sprint time-box. The Sprint Backlog is the forecast of work they expect will be necessary, and which they plan to complete. If too much work is planned into the Sprint Backlog then the Goal may not be reached; if there is too little, then an opportunity to deliver something more significant may have been missed and wasted. The ability to estimate - which is to say, to make a good forecast - is an important skill in Scrum, and Development Teams should continually try to improve their ability to do so.

Where is estimation left though, if there are no longer any Sprints for which a forecast might be made? That's exactly the situation we would expect to see in a mature Scrumban implementation. The scaffolding of the Sprint has been removed in order to achieve a leaner "pull". Do Scrumban teams still need to estimate work, or is all that now waste?

Let's remember that "forecasting" isn't just about Sprint Planning. A Scrumban or Kanban team might still be expected to make a forecast in another context. For example they might be asked by stakeholders when a certain backlog item is likely to be actioned, and when it will be completed. The team will look to its metrics in order to give an answer, such as by considering latency, throughput, and cycle time.

Estimation in the classic sense of "story pointing", which is to say the sizing of individual backlog items, may or may not still be useful in that context. If backlog items are of varying sizes, where the effort, time, and complexity of work can substantially differ, then an investment in sizing those items may still be of value. Metrics can be assessed on the basis of their relative sizes, and not merely on the raw count of items, so as to provide a more accurate forecast which reflects their variation. Of course, this begs the question: if the work at hand is really so varied in scope, has the complexity of the product truly been brought under control in the first place?

Remember that in a Kanban implementation, the work which is undertaken ought to be well-understood and unlikely to create exception conditions in its handling. Small and repeatable changes are the order of the day. If a Kanban team is faced with a large and complicated support ticket, they may choose not to action it at all, or to break it down into smaller discrete tickets which can be individually prioritized and then actioned. That activity of breaking work down into smaller items, to assure a lean and predictable flow, effectively replaces estimation. A team may have a Kanban station specifically for this analysis and to thereby enumerate work which is subsequently "ready" for actioning. The count of roughly equivalent-sized items, in the sense of measuring the rate of work actually done, will then be sufficient and appropriate for the purposes of forecasting. Arguably, you could also say that it is a better method, since any forecasts which are made will more closely reflect the empirical evidence of value delivered.

New Room to Vary the Quality of Service

We've seen how a Scrum Development Team must be allowed to focus on the agreed Sprint Goal. Having a Sprint-based commitment is important, and the quality of service a team provides is not expected to vary in this regard. In Scrum there is no concept of an overriding "priority incident" which would cause the team to drop one product to work on another, or of differing service levels which would allow work unrelated to the product to pre-empt its development.

Where there are no Sprints or Sprint Goals, the notion of "commitment" takes on a different form. The team might focus on improving cycle time or reducing defect rates, for example. After all, there is no longer a Sprint within which a single product is to be uniquely served. Many products may be dealt with in rapid succession, and a priority incident relating to one may well pre-empt work on another. Different qualities of service for those products - or indeed their customers - can be afforded, such as Gold, Silver, or Bronze level service agreements.

It can be seen that in the journey from Scrum to Kanban, the emphasis shifts from mitigating complex risks towards achieving a leaner way-of-working. The consquences can be at once both subtle and profound. For example, team sizes may grow larger, as collaboration becomes more about optimizing flow than handling uncertain situations with clarity and focus. The Daily Scrum will also change. No longer will there be a Sprint Goal to be met, or three questions to be answered in the huddle. Instead, team members are likely to focus on the pull of work, and to "walk" their Kanban Board from item to item so as to expedite progress.

Conclusion

In this series we have looked at three kinds of Scrumban. Firstly we have examined the fake ("Type I") Scrumban which dominates the industry. We then examined the lean implementation of Scrum using a Kanban system, a much more mature "Type II" Scrumban which demands great discipline. Finally, in this article, we considered Scrumban proper - a "Type III" model in which the Sprint scaffolding is removed, and which comes closer to the genuine Scrumban Corey Ladas originally envisioned.

That "genuine" Scrumban is very rarely encountered, and the Type I version is much more common than Type III. There are multiple levels of irony to be found here.

In his Scrumban book, Ladas expresses sorrow for Winston Royce and the irony of his position. Royce presented the waterfall-style model as an example of a broken system, not as a proposal for a good one. Yet his name has become linked to this flawed approach.

Now we find a greater irony yet, because "Scrumban" has also been misunderstood and vilified. To many, Scrumban amounts to the broken "Type I" version, and the path towards a genuine implementation is lost in the weeds. As Ladas felt sorrow for Royce, so I now feel rather sorry for Ladas. I can only wonder if the same thing must happen to me in my turn. Having described Type I Scrumban as a "crime scene", I suppose I shall be remembered as a chap who was in favor of crime.