The Agile Expanse

For my birthday, presumably for my health and not my life insurance, my wife got us an elliptical exercise machine. I call it The Machine of Wishing for Death. It’s brutal, though I have to admit that when we got it I could barely do three minutes on it, and now I can do thirty. But it’s so boring, and did you know that when you get on an exercise machine, time slows down? I think it’s some relativity thing.

Anyway, to entice myself to exercise, I watch The Expanse, a science fiction series that’s really rather good. I don’t let myself watch it except when I’m ellipticizing. Today, the quixotic hero, James Holden, was in a conversation with Fred Johnson, the “Butcher of Anderson Station”, now chief of operations on Tycho Station. It went like this:

James Holden:

Earth, Mars, The Belt, the OPA. It’s all bullshit. There shouldn’t be any teams.

Fred Johnson:

That’s a beautiful dream, son.

I tweeted that. And then I tweeted this:

Ron Jeffries:

Scrum, LeSS, SAFe, … It’s all bullshit. There shouldn’t be any methods.

Everyone:

That’s a beautiful dream, son.

I linked recently to some of my articles about all the different “Agile methods” out there, and I’ll do that here as well.¹, ², ³, ⁴, ⁵ But the point is there are a cubic buttload of them, and they aren’t usually different enough to tell apart in broad daylight, much less in the dark.

But they do have great names. They are safe, they are modern, they are disciplined, they are scaled. They have heart. They are more, they are less, they are fluent. As far as I know, none of them are soulful, dangerous, random, archaic, hesitant or inarticulate, but I suppose it’s only a matter of time.

Most of these strangely similar methods are directly associated with a money-making enterprise. A few of them, arguably, are not. But anyway I have nothing at all against making money, or making money helping people with “Agile” software development, or “Agile” car making, or “Agile” bake sales. I’m all for people helping people, and getting paid a fair amount for that.

But there shouldn’t be any methods. There shouldn’t be any method companies. There shouldn’t be any teams, except for the teams down there in the Code Mines, mining code. The teams we’re all there, presumably, to help.

Because there are multiple methods, Scrum, Scrum 1.0, 2.0, 3.0, @Scale, Large Scale, Disciplined, and of course Scaled Agile Fear [mongering], people think they have to choose. Should we be disciplined, or should we be safe? Isn’t three better than one? How could it not be?

Many of these schemes are aimed at corporations. Arguably all of them are, since it’s rare for an individual to hire a consultant or coach. Sometimes individuals take courses – often to impress the next corporation they plan to apply to. Well, as Willie Sutton said when asked why he robbed banks, “That’s where the money is”. So, yes, to get a chance to help people, you have to appeal to a corporation, or to someone in the corporation who has access to some money. That’s fine. I’m all for appealing to the people who can make the decision to get help. Makes perfect sense.

But nobody in this business has all the answers. Nobody is even qualified, as an individual or an organization, to provide the needed help at all levels, in all departments, of a company. There’s just too much. And yet, because we bought Brand X instead of Brand Y, we’re likely doing business with Company X, not Company Y, and so we limit the learning of our organization right out of the starting gate.

So what’s the alternative, Ron?

Well, I’m pretty sure that ship has left the barn, so I can’t undo the brand proliferation, unless I could go back on my own time-line, which is strictly prohibited and I wouldn’t anyway, because there was this one good thing that happened to me between then and now⁶. So I think we have to do a new thing, or, more accurately, we have to return to doing an old thing.

Michael Feathers put it this way yesterday: “I miss the days when we software types spoke about software”. I’ve pretty much convinced myself with the Dark Scrum series and related thinking, that those of us in the developer wing of “Agile” should turn our attention back to helping developers survive what “Agile” has become, rather than giving attention to pushing “Agile” per se. That’s hard to do, for me at least.

One reason is that I’m old and out of touch with some of the more recent developments in, well, development. From what I’ve seen, much of the original technical foundation for working in an “Agile” fashion remains the same, but possibly some of it doesn’t, and it would be good to have deep and broad enough experience to be sure which was which.

Another reason is probably just that I’ve been working for years to publicize the benefits of “Agile”, and to push the idea that it’s really simple, though not easy. That’s an important message too. At least I tell myself that, and it’s hard to give it up. And, seriously, done well, application of “Agile” methods can improve things both for the company and for its people. So it’s worth pushing, and pushing to do it right. I’ll probably continue to try to straddle the line.

However, for developers to thrive, inside or under any method, the practices that started out as part of Extreme Programming, and that are implied by the notion of iterative and incremental software development, are still the foundation of the best way I know.

Regular delivery of working software allows the organization to learn to steer by scope control, and it gives us the best chance for a reality-based understanding of time and cost and hitting the date.

And working software, delivered on a regular cycle, requires that we learn to build in small slices, test as we go, and improve the design incrementally, using refactoring. To be sure that it does what was asked for, we need to learn to communicate with acceptance tests. To provide a continued smooth flow of development, we need to learn to work together via pair programming or mob programming. And so on.

Yeah, the same old stuff still works, and it’s still needed. It’s just that this same old stuff has been left out of [almost?] all the current “Agile” methods, for what surely seemed like perfectly good reasons.

So, yeah, Michael Feathers is probably right. Maybe we’d better get back to speaking about software. What do you think?