Oh We have advanced beyond Scrum

Introduction

Sometimes i hear, "Oh, those Scrum practices of timeboxes, etc., are too basic or wasteful. We've advanced far beyond Scrum!"

First, if that's really true, i'm really happy to see a group that's done so much deep improvement. There are exceptions to what am about to describe, and for those exceptions, i say, "Good for you!"

But what I actually see when i go to gemba (not in a room with managers telling me their state) in almost every one of these cases of claimed advancement is not that they have advanced beyond Scrum, but that something else is going on. What's that?

It's that adopting real by-the-book standard Scrum exposed weaknesses that the group did not want to deal with. And as a variation, the group is demonstrating Larman's Laws of Organizational Behavior and hiding the self-serving efforts by specialists and managers to maintain their privileged status-quo positions. How? By shifting attention away from their desire to cling to the status quo by claiming, "We are more advanced than Scrum", which really means "We don't want to change in any way that would challenge our positions."

So for example, a group of 5 teams working on one product together is actually unable to be disciplined and efficient and effective enough to work in a 2-week timebox and deliver a "done" product increment and ship it. Rather than fix the root cause problems, they shift the problem and say, "Scrum doesn't work here, let's try Kanban." Or, "We're more advanced than Scrum."

Another reason for "being too advanced for Scrum" is not understanding the benefits of the practices.

Timeboxing

For example, consider timeboxing. Timeboxing is not a panacea for all product development problems, but it has advantages:

• Timeboxing enforces cadence, a useful synchronizing tool in a large group

• In small-group products with naturally tiny requirements (such as many Web applications), a two- or four-week timebox can sound like a step backwards... “You want us to deliver a working system every four weeks? We already do that every week!” But consider a 300-person group that is accustomed to a ‘single’ requirement taking 18 months, and a release every three years for an embedded-system product with sites in São Paolo, Oxford, and Warsaw. A suggestion such as, “Start to continuously develop micro-requirements with a continuously integrated and tested system so that you can always ship the product” is light years away from their capacity. In this context, “deliver a working system exactly every four weeks” provides a compelling and unambiguous attainable improvement goal, and starts to introduce cadence into a system that had little.

• Research and development work is often fuzzy unbounded (or weakly bounded) work. When the team knows that the Sprint Review will be in two weeks on March 15, it bounds the fuzzy work and increases focus. One game company doing Scrum observed that timeboxing the art work provided an immediate benefit. In short: Timeboxing limits scope creep, limits gold-plating, and increases focus—one of the Scrum values.

• Timeboxing reduces analysis paralysis.

• Suppose you are in university and have an assignment due on Monday. When do you start? For many, the answer is, “Close to Monday.” This is called Student Syndrome and timeboxing is a counterbalance.

• If teams must deliver something well done in exactly two weeks, the waste and ineffectiveness in current ways of working become painfully clear. For example, parallel development (rather than serial development) leads to faster delivery of value, shorter feedback loops, and other benefits; therefore, timeboxing creates a change-force to improve toward parallel development with cross-functional feature teams.

• In large multi-team development, a planning meeting is some- times needed between several teams. Sprint Planning on the first day of each timebox simplifies their coordination.

• Timeboxing simplifies scheduling—you know when to show up for planning and reviews. This is especially useful for a meet- ing-challenged busy Product Owner; she can schedule long into the future when to attend predictable events.

• Humans are probably more sensitive to time variation than to scope variation—“It was late” is remembered more strongly than, “It had less than I wanted.” Timeboxing avoids the erosion of confidence that happens for business stakeholders when product development people say, yet again, “... maybe in one more week it will all be done.”

Beyond Timeboxing within Scrum: Type C (Type 3) Scrum

Although there are various advantages to timeboxing, little known except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. AFTER a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run

Oh, Scrum is Too Inefficient for Analysis, Estimation, Planning, etc.

This excuse is most often used to avoid deeply improving and revolutionizing practices. For example, I'll visit a group that says, "Having teams doing the requirements analysis (refinement) is so inefficient." But on looking closely, the real problem is lack of skill, lack of participation, lack of good techniques. Or they are doing complicated and slow planning and estimation techniques; rather than retrospect, revolutionize, and improve, they shift the blame to Scrum.

Sometimes, this complaint comes from not understanding what is and is not part of Scrum. For example, a group will say, "The planning and estimation techniques in Scrum are too heavy." I'll ask them, "What techniques are those?" And they will give some answer. It doesn't matter what the answer is; the key point is that Scrum does not define any technique for planning or estimation. But the group does not know that, incorrectly associates some technique with Scrum, and then blames Scrum.

Oh, Scrum Teams are Not Efficient

Another common shifting of blame to Scrum is related to new teams. The organization previously had single-function teams and there is an extraordinary knowledge and skill debt in the group as a result. And massive levels of WIP and handoff waste. But all this is hidden within by organizational systems other than Scrum, which is based on cross-functional and multi-skilled flexible workers. When the group moves to Scrum and the huge knowledge debt (and weak workers) is exposed, there is a lot of learning and improvement to do to addresses those weakness. In the pre-Scrum (or "post-Scrum") group, there's the illusion of local optimization and it seems all very efficient from a local perspective. But from the systems perspective, there are massive weaknesses. But groups don't want to pay down that knowledge debt or address these weaknesses, and then say, "Oh, we have advanced beyond Scrum." Sure. ;)

Really Advanced

You've got a group of 5 teams working on 1 product, with true continuous delivery, great code, a real flow of value without pause or impediment, continuous learning and improvement, simple practices, etc.? Great. We in the Scrum community salute you!