Ken Schwaber, co-developer of Scrum, just gave an interesting talk at the Agile Project Leaders Network. Scrum, he explained, is not a methodology, but a framework for developing complex products.

The thing about complexity is that the more of it we have, the less likely it is that an external entity can dictate our way to success. There are just way too many variables and too many unknowns. Instead, what we need is a safe, supportive environment in which the team can generate ideas to dynamically deal with this complexity.

Scrum serves as a container for this environment. It’s not a methodology, it doesn’t tell us what to do (we still have to figure that part out). Instead, it exposes the weaknesses and, dare I say, failures in how we’re doing it.

“Do you have a mother-in-law?” Ken asks one of the men at the session.

“Of course,” the man laughs. “Now imagine that your mother-in-law believed her daughter could do better,” Ken proposes. “And then imagine that she moved in with you. That’s what Scrum is like.”

You see, the other thing about complexity is that it’s really hard (as a customer of mine recently reminded me). No matter how smart we are, we’re still going to get some things wrong – either because we misunderstood, or the conditions of success changed, or just because that’s what it means to be human rather than a machine. And so which is more helpful? A process that pats us on the back and tells us everything is going to be just fine (see, it says so right here in the plan!)? Or one that provides us with immediate feedback when we get something wrong?

Think of the red x‘s in our IDEs that show us errors before we even request a compile. Or, the squiggly red underlines letting us know that “squigly” is misspelled (it has 2 g’s). It may sound counterintuitive, but if we can be notified of what’s wrong before we even think to ask; in a simple, non-intrusive manner, it allows us to to correct problems so easily that we hardly have to stop and think about them. Before those errors can domino out to impact other, larger things that are harder to fix. Before incorrect assumptions can kick off a trail of bad decisions. Before they grow to be complex problems in and of themselves that require massive amounts of rework and frustration.

Our goal is not to avoid all errors in software development (the mere act of creating new things requires a process of trial & error). But rather to spot them as quickly as possible, before they become a problem. Scrum is not as automated as our IDEs or text editors. But then, building software is a lot more complex then just banging out code or documentation. It requires really hard things like understanding what the customer wants. Which, of course, is never the same as what they say they want. So, there’s a bit of mind reading involved, which can be rather challenging. And then there’s making sure our code works. Not just on its own, but also with other people’s code, which of course is never as good as our own, so that’s a challenge as well.

So, we have these really hard parts in software development – and they’re mostly the parts that involve other people. And since we can’t just pull out our red sharpies and go around marking red X’s on people’s foreheads when they do things we don’t like, we have to find a different approach. In Scrum, we do this by putting a framework into place that makes detection of errors as automatic as possible:

1. Scrum forces us all to work on the same pieces at the same time until each piece is completed to everyone’s satisfaction. This is done quickly and efficiently – the pieces are time boxed to fit into sprints that are, at most, 30 days in length. So, if there is an error or misunderstanding (you wanted the software to do what?!), it will be caught while we are working on the item. Each sprint produces production ready software, so we can move forward with confidence, knowing that we can reliably build upon what’s already in place.

2. We can’t automate error detection in human communication and understanding, so Scrum builds in human inspections at regular intervals that are designed to catch these types of errors as quickly & non-intrusively as possible:

• Each day, we inspect our progress towards meeting our commitments in the Daily Scrum.
• Each sprint, our customers inspect what we’ve developed against the product they want at the Sprint Reviews.

I say non-intrusively because in Scrum, these inspections are done as such a natural part of the process that they become second nature, like those red squiggly underlines (hey, something is wrong here if you’d like to fix it

And so, Scrum’s benefit is not that it tells us how to do things. But, rather, that it recognizes that only the team is in position to adapt and respond quickly enough to the unknowns and changing variables in order to drive the product to success. Scrum instead focuses on ensuring that feedback is always available to keep the team on track; moving in the right direction, closer and closer to their target.

—
Ken says when people do Scrumbut (We’re using Scrum, but… we don’t do X), the “but” often removes the parts of Scrum that expose problems (we’re doing Scrum, but… we don’t do Daily Scrums every day), thus defeating the purpose of Scrum. Does your project do Scrumbut? Does your but negate your Scrum?