Time was ...

Time was, you got a spec, got browbeaten into saying you’d do it in 6 months, then got mostly left alone for 6 months. Now, they get to **** with you every ******* day!
— Ron Jeffries (Twitter)

In Dark Scrum, developers rightly feel like the quote above. At least in the olden days they got time to try to deliver what was wanted, with maybe only monthly status reports and the occasional beatings to improve morale. Now, it seems that every Sprint Planning, every Sprint Review, every Sprint Retrospective, and worst of all every Daily Scrum is an opportunity to rip the team up by the roots to see how it’s growing.

Now this is certainly not what Scrum is really about, but too often, Scrum becomes Dark Scrum and the world becomes unsafe for programmers. This series of articles talks about what we can do about that.

Now the thing is this: Scrum (well, really, Extreme Programming) is the best way to develop software that I’ve ever seen.

I’ve been developing software for over a half a century, and I mean developing. I most recently worked on a program yesterday. I program almost every day. Not working on stuff as hard as you and your team do, but plenty hard enough. And really and truly, the basic Scrum / XP cycle can be great:

Work actively with the Customer or Product Owner to understand the problem;

Decide every week or two what to do next;

Agree with Customer on concrete examples of what’s to be done;

Do the work, meeting among ourselves frequently to make sure we’re on track;

Show a running shippable version of what we’ve built to our customer and other stakeholders every week or two;

Meet among ourselves every week or two, to look at how we work and find ways to improve.

This is really good stuff. This cycle is the best way of working that I’ve ever experienced in over a half-century of writing software. When we can show real running software to our stakeholders, conversations can change from vague explanations and threats into productive looks at what should be next and how to do better. Oh, we do have to have the conversations, and we have to know how to guide them to talking about reality, but we can do it, because we have reality — real running software — in hand to talk about.

This means that there are a number of things we, the developers, have to become good at. We’ll talk about all these topics at length as this series continues. They include:

How to turn the conversation around using the Increment, if we had one;

What the Increment needs to be like to be an effective agent of change;

How to guide planning into more sensible paths than just “do it all”;

How to ensure that the Customer and developers are on the same page;

How to build a solid running application over time;

… and many more. We’ll be iterating over these topics in this series, exploring ideas on what we need and how to get it. But for now …

Imagine that we could

Suppose that there was some way, however magical, to agree on Monday with our stakeholders about what to do, and then by Friday, to have our best understanding of that in hand, running, integrated, so clean and complete that they can use it or ship it if they want to. So good that the only reason not to ship is that the product doesn’t yet contain something important that they haven’t yet asked for.

Imagine that we could build software incrementally, feature-by-feature, well tested and integrated, ready to go at any time.

Now, of course our stakeholders would still wish we could do more, go faster, produce more and more features. It’s their job to want more. And yet we could say, truthfully:

We’re going as fast as we can. We meet weekly to figure out ways to go even faster. Meanwhile, this is what we have, and every week you get to tell us what’s most important to you, and we’ll tell you what we think we can accomplish. A week later, you have it in your hands. Today, this version is in your hands. It’s clean, tested, ready to go. You could ship it out if you want to: here’s a copy on a CD and an envelope. The manual’s on the CD too, up to date.

The stakeholders would have to be pretty opaque not to get the drift of how to work this situation: tell us what’s most important, agree with us on what’ll meet those needs, and stand back and see it done the following Friday. They’d have to be pretty opaque not to see rather soon that if they would trim down their fancy ideas, they could soon have this thing in real customers’ hands, solving problems and bringing in revenue. And we’d be equipped to help them figure that out, instead of just standing with our heads down, tugging our forelocks, enduring yet another beating.

We could collaborate for an earlier shipment of a better product. We could become a real product development team instead of a bunch of serfs being measured by how much muck we could move every day.

How do I know? I’ve seen it happen many times. I’ve seen it happen often enough to be sure that it can usually happen. Besides, if you’re trapped in the Dark Scrum nightmare, changing the conversation is your only real hope, other than moving to a new job or profession. And programming can be fun. Do you remember when it was fun? It can be fun again.

At the core of this is the Increment. The running tested software that we set before the stakeholders as the center of the conversation about what to do next. We’ll talk at length, as this series continues, about some specific ways of getting the Increment. But you have already heard about those ways, and you even know fairly well how to do them. The main thing is to start using your regular retrospectives to see what’s in the way of delivering a real Increment, and improving how you work to get closer.

Work on that. I’ll be back with some hints soon. Or get in touch. I’ll try to help.