Do We Really Need Another Method?

A sometime colleague, who I believe still owes me a year’s supply of rice or something, from a Y2K bet, sent me a writeup on his new “Agile” method, complete with dreams of certifying coaches and such. This on top of the recent emergence of “Nexus” and “FAST-Agile”. The latter isn’t really supposed to be a new method, but it is indistinguishable from one in its description.

Not much before that, we had the appearance of SAFe, whose market acceptance appear to have triggered the appearance of LeSS, and shortly thereafter the aforementioned Nexus.

The list goes on and on. Down at the end of this article, I’ll provide the list¹ of methods Chet and I could think of. There are a cubic boatload, you can be sure of that. And by the time you read this, there will probably be a couple more.

Stop that! Just stop!

We have more than enough “Agile” methods. The issue is to do an existing one well. As I wrote in Nature, most “scaling” problems are best addressed by one or two teams doing agile well. Diana Larsen and James Shore make the same point in their “Agile Fluency” model.

So don’t buy a new “Agile” method. Don’t buy “SAFe”. Don’t buy “FAST”. Don’t buy “LeSS”. Don’t buy anything. Start doing what some decent “Agile” method says, and repeat until you’re good at it. After that, it will be obvious what else to do next.

If your managers and executives need something to keep them busy, they should apply some elementary principles of Lean, looking to the overall value stream for product development. They’ll find two things, almost always. First, they have too many irons in the fire, resulting in delays for everything. Second, there will be built-in delays in the overall process, whose removal will speed up delivery substantially.

That’s it: Do “Agile” well, and look to your value stream.

Yeah, boss, but what is “doing Agile well”?

Doing Agile well requires a very few things. These are:

• Put business people and developers together, with real authority to decide what to build and build it;
• Produce a product increment at short intervals, building the right thing the right way;
• Review product to decide what to build next;
• Review process to decide how to build it more the right way.

That’s all it takes. You really do have to grant the authority, build the right things the right way, and review what you’re doing and how you’re doing it, continually improving. That’s hard enough, but it’s simple. You don’t need a giant method to do this.

Yeah, boss, but which method should we use?

There’s only one that really matters. It’s often called Scrum plus XP in today’s parlance. Scrum productivity requires XP practices, according to no less than Scrum’s creator Jeff Sutherland. Mike Beedle was talking about XP@Scrum way back at the beginning of the century. SAFe, the marketing triumph of everyone else’s ideas, asks for Scrum+XP in all SAFe teams.

Iterative planning and building, with solid technical practice. Continuous improvement. That’s all there is.

Scrum plus XP. Or just XP, if you have the spheres to call it what it is. Mainly don’t call it, do it. That’s all you need. You don’t need no more.