Dark Scrum: Hills and Affordances

These articles about hills to die (or have a nice nap) on are in response to a continuing trope on Twitter and elsewhere, to the effect that X is bad, or Y is better than X, and therefore don’t do X do Y. These are amusing, provocative, and rather frequently … mistaken.

Sometimes I think of the world–the system we live in–as a network of forces pushing and pulling in different directions. Not so much a mind-map as one of those web messes you get when a zillion spiders have been making webs in the woods and you can’t remember which spell makes fire shoot out of your wand.¹

As we coach a team or as a team tries to improve their world, everything they do is tugging on these strands. They’re trying to arrange things more to their liking. But the stuff is all interconnected! Just as you get the code working better by bearing down on tests, they start asking why you’re doing fewer features, so you speed up on features and the code starts pushing back, so you begin to refactor and you discover you don’t have enough tests and the ones you do have are fragile and then the database server changes version and all your scripts stop working and the real DBA is on vacation and so you have to send your best gal over and now all the stuff she was working on lands on your desk and you have no idea what she was even trying to do and the phone is ringing off the hook and and and …

When we make a change to our process, we have in mind certain improvements. “If we had a few more tests the code would work better.” If we’re any good at all, the change will at least help with that. But there are other, interconnected effects.

This is particularly fraught when we think we have a better idea and recommend eliminating another idea in favor of the new one. We’ll explore one that’s going on right now. I spoke briefly about this before, and apologize for hitting it again, but I feel the nail needs another whack.

At Industrial Logic² they have “discovered” that creating a “walking skeleton” has often worked well, “better”, they think, than “Sprints” work.

I quote all those words for a reason: we don’t all agree on what they mean:

• Discovered - They’ve done some kind of work with teams and have used “walking skeletons” to good effect.
• Walking skeletons - Well, we probably all think that means some kind of minimal program that does the thing. But what was the thing, what was the skeleton, how well does that apply to our lives?
• Better - To really know if X is better than Y, we would probably have to do a lot of comparisons, controlling a lot of variable, etc etc blather blather. How was it better? What were they paying attention to?
• Sprints - What does IL understand a Sprint to be? Did they replace the planning, the stakeholder review, the retrospective with something? Did they just not get together a week from Friday? We don’t know.

This is in no sense a criticism of what IL has done. They’re brilliant and they’ve done something that was almost certainly very sensible and they’ve had results that were almost certainly good. They’re suggesting, it seems, that if we’d just do this walking skeleton thing, we could, and should?, get rid of Sprints.

I’m not even certain they are saying to do walking skeletons instead of Sprints, but that’s what I heard and what I think other people will hear. And I’m not at all sure whether, or at best when, that advice would apply.

But here’s my real concern: it’s that darn web. Sprints offer a number of affordances. They do a number of useful things. They tug on certain threads in the web and they relax others. Let’s see what Sprints might be good for.³

Again, we touched on these in that other article, but we were making a different point. So let’s look again:

Sprints cause us to do some important things on a regular cycle. Both “important” and “regular cycle” matter here.

Important

Planning

Planning is important, even though plans are not. In Sprint Planning, we have a brief meeting with our empowered “Product Owner”, where we talk about what’s needed, what’s most important in the mind of the PO and our stakeholders, and then we decide what to work on for the next week or so. After the first time out, we’ve got our “walking skeleton” and we’re adding flesh and bones to it. Sprint Planning, part of the Sprint concept brings us together on what we’re trying to do.

Review

Many people in the organization want and need to know what’s going on. At the end of the Sprint, there’s Sprint Review. At this meeting, our stakeholders–customers, our PO’s bosses, the Marketing VP, all kinds of people who are interested–look at our real result and see what we’ve accomplished. They provide feedback on what they see, and what they’d like to see next. This meeting informs our stakeholders. It keeps them aware that we’re actually accomplishing things, which gains us needed support. It gives us valuable feedback about their thinking, and it gives them a real hand on the steering wheel. When people feel their concerns are heard, and being addressed, their support rises. In my view, the Sprint Review is often the most important meeting in Scrum.

Improvement

There’s always room for improvement. At the end of the Sprint, we have the Sprint Retrospective. Here, we think about all the things we did in the past week or two, and about what we could do to make things go better. Now, in a really good team, some of our needed improvements have already been identified and put in place. Those will usually be fairly direct and immediate discoveries. The Sprint Retrospective gives us a bit of a larger perspective to assess. And, truth is, many teams don’t even do one retrospective per Sprint, much less one every day or so. The Sprint Retrospective is the main driver, in Scrum at least, of continuous improvement.

Understanding

It takes time to adjust plans, and to get ready to build new features. During the Sprint, teams do Backlog Refinement. They discuss what they’ve been hearing from the stakeholders and elsewhere, and they talk about the backlog items that might be undertaken, and they work out details. Wise teams often pre-write acceptance tests in Sprint N, to be used in Sprint N+1, because having those tests ready helps developers know what to do and when they’re done.

The core point, so far, is that these elements of the Sprint provide valuable affordances for guiding and improving the product and the effort. We probably don’t want to drop those things, so if we do decide to “drop Sprints”, we need to provide for those needs.

Regular Cycle

Now, some will argue that these things, planning, reviewing, preparing, and improving, can be done any time. And that’s true. However, you’re going to get a different set of attendees if the Review is every two weeks than you’ll get if it’s called at random but interesting intervals. You’re going to get a different planning perspective if you plan ever week or two than you get if you plan on demand.

Habits are important. Reaching people on a regular basis gives them more comfort than if they hear from us randomly. We want to seem reliable, not random.

The Kanban people, of course, call this notion “cadences”, and I’m happy to adopt that term. The cadence itself has value in terms of giving people opportunities to contribute, and giving them confidence. So if we do provide some Sprint affordances another way, we’ll do well to consider doing so on a regular cadence. Soon, we have something that looks a lot like a Sprint.

Summing Up

Here, I’m not trying to settle the issue of Sprints. They’re just a convenient example that’s on my mind because we’ve been talking about it on Twitter.

What we’re looking at here is the larger issue of adjusting our process, especially if we look to eliminate some practice because we see a possibly better way to do part of it. We need to look at the whole nasty web of interactions and see which ones are improved by our new idea, and what may be diminished.

In the context of hills to die on, this suggests to me that we need to think hard, and deeply, about existing well-known practices, and about the things we’ve tried that seem to have worked well, and how they all connect together.

And we need to think about who is going to use our advice and how they’ll use it.

A successful team is a very complex system. If they have expert coaching, they can try things pretty safely, because the expert coach will detect problems and help them compensate. A team on its own may hear some new idea, especially if it sounds like it would simplify things, or eliminate something they don’t like, like that darn meeting, and jump too far too soon. In their enthusiasm, they may try something that needs to be done delicately, and in a context of careful combined changes, and in their well-intended inexperience, make thing worse.

We don’t want that. None of us wants that. To me, that means we need to be careful in our thinking, and in our advising, especially when do to it in the hearing of people who don’t have the advantage of lots of contact with experts.

Of course I could be wrong about all this. Maybe this is all easy, and I’m just doing it wrong. You can die on that hill, if you want to. I’m going to take a nap over here on mine.