Once again, it seems, many are intent on fanning the flames of the methodology wars. A few years ago at Agile 2013 in Nashville, one of the great tweet wars was “SAFe is unsafe.” During a luncheon, a colleague was doing his best to egg me on to lob my own hand grenade into the fray and, for one childish moment, I was thinking of simply tweeting www.the-new-deal.org to remind the warring factions that “Faith-based bias in selecting and using methods negatively affects outcomes.” However, I resisted, much to my colleague’s disappointment.
A spirited debate about methodology and practice is the very essence of what a good software conference should be. Out of debate comes learning, and comes an understanding of which context practices work and where they may not be applicable. Out of debate also comes lessons learned, and the emergence of new ideas. But there is no place for broad brush methodology bashing, which sometimes take on the traits of a holy war. Personally, one of the biggest pet peeves I have with some people in the agile movement is the broad-based bashing of a waterfall caricature. Anyone who is familiar with waterfall also knows that the step-like graphic frequently presented is not actually the waterfall model, it’s merely a caricature of it. These strawman wars serve no purpose other than to get everyone’s defences up, which means very little listening is taking place, and therefore very little learning. But I digress…
I admit it: I like SAFe. I worked with Dean Leffingwell and Chad Holdorf at John Deere ISG, and watched how we were able to reinvigorate a team of nearly 150 dispirited people from what they believed was certain failure to feeling like they had a fighting chance. And no, I do not believe it was SAFe that “saved” them, it was the hard work of those 150 people which got that project back on track. But having a new focus for how to apply their energies certainly helped. This does not mean I think SAFe is the magic silver bullet, and that I want to use it with all my clients. There are even many things about SAFe I’m not really fond of. But at least its there, publically available and well documented, enabling us to have that spirited debate about what we like, what we don’t like, and why.
Personally, I think a lot of these methodology wars are driven by a desire to artificially differentiate branded methodologies from one another. I’m not going to criticize someone promoting a product or methodology they have invested work and effort into developing. But these wars are sometimes becoming the technology equivalent of a jihad, with extremist factions insisting that organizations adopt inappropriate, or even damaging, solutions just because of some misplaced sense of methodological purity. I have seen too many “agile” projects fail because those who are consulting and coaching to the organization limited their interpretation of agile to a rigid application of branded agile practices. I have even seen organizations out right rejecting agile, or eventually de-agilizing, because the practices did not work in their context and environment. Often, in these situations, responsibility is laid at the feet of the organization itself, with a trite “well, they didn’t follow Scrum/XP/Kanban properly” cited as the reason for failure.
As coaches, consultants, and trainers, we may be forgetting a simple truth: our job is not to make organizations “agile” — rather, it is to make them better, and agile is a pretty decent philosophy for achieving that goal. Seeking conformance to a branded agile methodology is not. It’s time to learn and to understand why and when these practices and ideas work and, most importantly, why and when they don’t. These methodology wars serve no purpose and it’s time to call a truce. In the end, we will much better serve ourselves and our client.