What's your point?

A recent twitter thread got my attention yesterday. The subject was story points, and the main notions were pretty standard:

• Story points are an old-fashioned, inferior way to do things;
• Apparently you live on some strange planet where story points are not needed;
  • and by the way your mother dresses you in an unprofessional fashion;
• Context is important, maybe sometimes story points are needed;
• Story points helped me one time in the distant past;

All the usual suspects, in other words. This morning, I tweeted this:

I think this story point question revolves around whether you’re trying to disrupt business as usual with Agile, or just support a little change.

The Manifesto was meant to be disruptive.

I think that at the time of the Agile Manifesto, we had disruption in mind. I know that I did. The things we held in common were fewer than those we disagreed about, but more powerful. Stating them today, I might emphasize:

• Working closely with those who have a need for software;
• Producing working software very frequently;
• Adjusting our path continually, based on up-to-the-moment observations.

However you parse it, this was a way of working that was quite counter to the then-current business-as-usual way of doing things. And, unfortunately, although many business now claim to be “doing Agile”, the ideas are still quite counter to today’s business-as-usual way of doing things.¹ There are many more people working in a style that could fairly be said to follow the Manifesto, and there are many people contributing to understanding what it means and how to do a better job of working in that style. Nonetheless, the majority of software development, the majority of the organizations, may be trying to adopt the Agile ideas, but they are not at all far along. Many of them, I am sorry to say, are more “Agile in Name Only” than anything else.

Now, I have written before, and I really do believe, that even very superficial adoption of Agile ideas² leads to some benefit. Trying to pick features incrementally, and to deliver working software regularly, delivers some benefits, no matter how wistfully you do it. And a few organizations get all the way to something that fits with what we had in mind way back in 2001. Unfortunately, very few make it.

Why do so few teams and individuals get all the way there?

Let’s think a bit about why Agile ideas have turned out to be useful in supporting business as usual, rather than disruptive as I had hoped for.

Most people are just getting by.

I think that most of us, in most of the things we do, including our work, may be trying to improve, but mostly we’re just trying to get by. We’re trying to live some kind of pleasant, if not happy, life, not burning the midnight oil trying to become king of the hill. And that’s OK: software development is pretty cool but it’s not the highest goal one could have.

The same is true of most organizations. Even if they are almost entirely a software development organization, these outfits are trying to grow, or trying to survive. We can argue that excellence in software development is core to their success but the organization as a whole is more likely to think that selling better, or supporting better, or choosing better products is more important.³ And don’t even get me started on building up a popular internet presence and then selling out.

So part of why Agile ideas have not disrupted the world as I had hoped is that most people and organizations don’t really want to be disruptive, or disrupted.

Agile ideas are an easier way to just get by – but change is hard!

Switching what one does can be hard, but it’s ironic⁴ that if you just want to get by, using Agile ideas is easier than the old way. Adopting iterative delivery and close cooperation with the business will make anyone’s life at least a bit better if they’ll just do it. Of course, change is difficult and painful, so for a time maybe your life has to get worse before it gets better.

Reminds me of exercise, if I remember what that’s like.

Most people in the “Agile biz” are not there to disrupt.

I believe that there’s a more significant reason why Agile ideas have not been as disruptive as I foresaw and hoped for: most of the people pushing those ideas are not trying to disrupt the way things are done, they’re just trying to improve things, or trying to make a buck.

That may be OK. You can’t really go around all the time with squirrely hair, raving like Emmett Lathrop “Doc” Brown, Ph.D. No one listened to Doc, and no one would listen to you. Besides, Agile ideas are all about incremental change, so it makes sense that if you’re coaching a team, helping to transform an organization, or selling courses describing a method, you’re going to make it palatable, make it seem easy, take it step by step, inch by inch, hoping that slowly they’ll turn to full-on Agile thinking …

Unfortunately, the result, most of the time, is what Martin Fowler called “Flaccid Agile”.

Maybe someday those individuals and organizations will truly be transformed, truly adopt Agile ideas, but most of them do not. Perhaps they never will.

What’s your point, Ron?

Yes, well. Let’s imagine that Agile ideas, well applied, can in fact be disruptive to the style of software development we often describe as “waterfall” or “business as usual”. Suppose it is true that moving to the style the Agile Manifesto recommends can really make a substantial difference in productivity, happiness, quality, and all that jazz. What should we expect to happen in response, if it’s even true?

Since “Agile” is just an idea, not an actual product or technology, we should expect that the ideas will only be partially understood.⁵ Even to the extent that the ideas are understood, adoption will always be partial. We should expect some kind of curve of “Agile Uptake”, from very low to very high. And that’s what we’ve got. So that’s all good, right?

It’s not all good with me. I think that Agile ideas, taken to heart, can greatly improve the lives of programmers and the lives of those who have to work with them. I think the ideas can substantially improve productivity, quality, even the applicability of a product to the market.

Slow uptake, and half-assed uptake would be inevitable even if everyone was behind disruption. But everyone isn’t behind disruption: most folks are just trying to get by. That’s OK. People get to choose what to do and how hard to try.

So if you want to keep story points in your Scrum, if you want to do Scrum without actually producing software, if you want to produce software using silos instead of teamwork, well, you have a right to do that. I wish you wouldn’t call it “Agile”, but you have a right do do that as well.

But don’t expect me to smile and nod.