What I wish we had done ...

Some readers whom I respect did not get a clear message from this article, and in fact some even got a mistaken message. Other readers, whom I also respect, really like the article. I don’t know whether they got the right message or not. In any case, I’m leaving this one roughly as it originally was, and writing another. I’ll add some footnotes to this one in the hope that it’ll be more clear as well.

As a faithful reader, you’re probably aware that I believe that the word “Agile” should mean “consistent with the Agile Manifesto”. And, of course, it doesn’t mean that at all. Instead it means whatever the word’s user means at that moment. There’s great confusion as a result. Ah, well, life is tough, then you die. Quickly, I hope, but not soon. But I digress …

An important contributor to the confusion is the proliferation of branded or named methods and frameworks. At the time of the Manifesto, if I recall, there were Scrum, XP, Crystal, and DSDM. Anyway right around that time, Jim Highsmith came out with Adaptive Software Development, Mike Beedle began a series of names like XP@Scrum, and it went on and on. It continues to this day.

The more popular “Agile” became, the more named methods and frameworks we got. Now we have lots more: DAD, SAFe, LeSS, FAST, and so on. For a more comprehensive list, check out this article. Point is, there are a lot of them. I don’t think we really need a “method” at all. I feel quite sure we don’t need a dozen. Read on.

Then we have a cubic bunload of companies named for Agile this and Agile that, and Agile Method this and Agile Method that. It was the thing to do. It seemed to make business sense to get into this hot new thing called “Agile”.

Added:

Note that I am not impugning the motives of the people who have entered the “Agile” business in any way at all. Most of the key players are known to me, and I believe them to be sincere in their interest in “Agile”, and in trying to help people. They have a right to make money doing so, and I’m all for it.

I do, however, regret that we have such a long list of “Agile” methods, which are more or less all the same. My initial thought here was “What if we had said the right thing about practices? Might that have reduced the need for so many nearly-identical methods?” Since I am not allowed to edit the past – as far as you can tell – I moved on to think about how a greater focus on practices might help us now.

Brian Marick once suggested that, instead of “Agile”, we should have named it Chronosynclastic Infundibulum or something. No, wait, it was “Artisanal Retro-Futurism with Team-Scale Anarcho-Syndicalism”. Part of his idea was that the name would seem so undesirable that people wouldn’t want to fly that flag, and maybe there could have been a focus on the valuable ideas rather than on branding.

All these ships have sailed, of course. Bye-bye, ships.

For of all sad words of tongue or pen, The saddest are these: “It might have been!”
– John Greenleaf Whittier

Well, I’m not allowed to go back on my own time-line – as far as you know – but sometimes reflecting on what might have been can help us with what might still be. And here’s what I was thinking when I started this article:

There’s too much branding, too many so-called “Agile” methods, and not enough attention paid to what it takes to excel, namely a continuing exploration and adoption of better and better ways of working. As I use the word, better and better practices.

What if, instead of just Values and Principles, the Authors had gone on to speak about Practices? And what if, instead of creating brands and businesses around “Agile”, we had all focused on discovering, supporting, and advancing the practices that we liked best and were best able to help with?

(Added) Might we have had fewer methods, and better results? Maybe. What does that mean for today? Here’s an example of “Agile” without “method”:

When I’m coaching a team, or when in the course of a training experience¹, questions come up, I think in terms of the forces acting on a team, and refer to things they might try to better balance the forces. I’m not really teaching Scrum or XP or any method: I’m helping the team figure out what to do.

Sometimes, the answers are really clear to everyone but somehow need articulating. Maybe the team has a separate testing group. Maybe they’re building up a larger and larger list of defects, or maybe they’re having trouble scheduling their iterations because they don’t know how many high priority defects will have to be fixed this time around. Someone needs to do the math and point out that if we shipped fewer defects to the testing people, we wouldn’t get so many defects to fix, and we’d be better able to know how much work to take on.

Then, we have to talk about how that would slow us down because we’d have to, I don’t know, maybe actually test our code. Then we have to observe that we’re spending 45% of our time fixing bugs and that it would surely take less time to prevent them than fix them, plus it would be less embarrassing. Then, and only then, we can get around to figuring out how to test our code in ways that are not unpleasant. That leads us to TDD, and to ATDD, which are both rather fun and certainly nearly painless.

Most of the solutions to a team’s problems are probably already known. Sure, there are details and nuances that will have to be figured out. Sure, there are things that will have to be learned. But we have to begin by looking at what’s going on and realizing we could make it better. Maybe we need “permisson” to make it better. Nothing spells “permission” better than having an expensive but strangely charming Agile Manifesto Author sitting with you helping you figure out how to improve your life. (Just sayin’)

I don’t need no stinking badges …

My point here is that I don’t have to say “Agile”, or name my brand name method – have you noticed that I don’t even have one? – in order to help these people, and in order to get a bit of work from time to time. When a team gets help and starts getting results, I often get called back to help another team, and word spreads and I get invited to visit other companies. Sometimes I get calls from third-generation companies, where people have wound up two jobs later after a place I’ve visited.

All this is not intended as self-promotion – though you should feel free to get in touch. It’s pointing out that it suffices to be recognized as being helpful, and maybe as being helpful in an “Agile” or “Scrum” context, to find plenty of work to do, and to be able to help lots of people.

Now there is some package of practices that I’m fairly expert in and I’m happy to bring those to bear anywhere they’re needed. And if someone were to ask me to help them with TDDing their JavaScript, I’d recommend someone else, perhaps James Shore, who knows more about it than I ever will. Doing things with embedded? I’ll suggest James Grenning, or Nancy Van Schooenderwoert, because they are expert in that area. Human-to-human concerns? Maybe Esther Derby or Diana Larsen. And so on. I know lots of people, so I don’t have to know all the things.

Truth is, everyone who’s out there, every company out there, selling “Agile Solutions” or whatever they call it, is really only expert in some small set of the useful practices that are needed in order for a team to grow, improve, and ultimately excel.

What if the Manfesto Authors had gone on to create a focus on discovering, supporting, and advancing specific practices? But instead people, starting with the Authors, created separate Enterprises, offering what they tout as complete solutions. These Enterprises perceive themselves as being in competition with each other, and they fan the flames such that their poor customers are deluded into thinking that they must choose one or the other.² Why do we need to choose this one or that one? Why not choose both? Why not choose all the things that will help us?

What if you and I, all of us working with these ideas, did that starting now? What if we were all to make a point, each and every time, that capital-S Scrum, capital-K Kanban, capital-A Agile, are rudimentary staring points on a long journey, and that the real learning comes once you begin doing these rudimentary things and paying attention to what happens next?

Might we be able to turn the tide against Big Agile, or Agile In Name Only? Might we end the useless Scrum/Kanban war, or the useless SAFe/LeSS war? No, probably not. But I bet we could help a lot of people along the way.