My esteemed blogging colleague Jonathan "Kupe" Kupersmith took a stance in his last blog post that the term agile had become a something of a fad. He quoted an article with four key points and then a general comment/quote from Scott Ambler that mentioned driving repeatable results. He put those two together to make a case that agile vs. waterfall isn’t the point. Instead, applying practices that work is the point in your projects — driving to valuable results.
So when I first read the post, I was entertained and I couldn’t agree more with the spirit of his message. Kupe had a wonderfully catchy title, a few references, and a short and sweet treatise on agile. I only wish I could be as succinct as Kupe was in this case (as you can see by the length of this post). However, it also struck me that the post misrepresented some of what “agile is” and I found that regrettable. It’s not the Kupe was wrong…but perhaps just a bit too succinct in his selection of references.
So I thought I’d respond to the post, not exhaustively explaining agility, but highlighting a few critical points to get a different perspective out there —
Firby – Fad (say that three times quickly)
I really don’t like the use of the term Fad. Here are two definitions:
- Google Dictionary - An intense and widely shared enthusiasm for something, esp. one that is short-lived and without basis in the object's qualities; a craze;
- Dictionary.com - A temporary fashion, notion, manner of conduct, etc., especially one followed enthusiastically by a group.
After reading those, I don’t think the agile methods, practices and approaches are a fad. The agile manifesto just celebrated its tenth anniversary. Scrum was first used and shared in 1993. XP was formed in 1999. Lean principles were established well before those time-frames.
So the practices, while potentially being practiced with youthful enthusiasm, are not temporary. They’ve also crossed over into the mainstream. And they are certainly not a craze. For example, the esteemed PMI is now introducing an agile certification, and while that’s quite scary to many agilists including myself, I don’t think they’d do that for a mere fad.
Cabbage Patch Kid – Fad
Oversimplifying the Practices
The reference Kupe used represented agile practices identified four agile practices: collaborate, be lean, iterate and visualize. He mentions that he’s worked in teams that did all four of these practices and therefore were agile.
I’m not stuck on the word agile, but I am disappointed that Kupe chose an article with such a short list of practices as illustrative of agile practices. The original author left off a few things; for example: the emphasis on the whole team, trust of your team, a relentless focus on building in quality, the dynamics of transparency, the power of and need for customer engagement and the notion of customer acceptance are just a few of the missed concepts.
I also think each one of the referenced practices can be expanded. Take visualization for example. User Stories, Burndown charts, StoryMapping, Release Planning in various forms, Story Brainstorming Workshops, attending sprint Planning & Daily stand-ups are just a few of the ways for teams and stakeholders to visualize the various states of agile projects. The terse term does the depth, breadth and usefulness of the technique a disservice.
And each one of those techniques requires specific skill levels to do well — so not every team that is practicing agile is really applying the tools and techniques consistently or well.
Tickle me Elmo – Fad
Agile vs. Waterfall
I will take a hit for the agilists falling into the trap of seemingly always badmouthing waterfall teams and approaches. We seem to look at these sorts of projects as being anathema to agile. Holding a position that waterfall is somehow beneath us now that we’ve “gone Agile…”
At least speaking for myself, my history in waterfall-esque projects is fraught with Death Marches and project failures. Only lightly interspersed with the occasional project success. So yes, there are a few scars. But that shouldn’t give me a license to diminish traditional project approaches. Even if I do personally find waterfall-esque thinking to be inappropriate for most of today’s software projects.
I interpret one of Kupe’s points to be that we need to stop getting stuck on the name of the methodology or process, but simply dive into our projects, applying the practices that make the most sense whether derived from agile or waterfall-applicable projects. I would buy this if the agile practices could be individually and easily parsed into equally useful tools. Sort of like a Swiss army knife. But I don’t think they can.
My experience tells me that agile practices are fundamentally diluted when you pull them apart and consider individual practices as options. For example, I can’t tell you how many teams I encounter that consider having a daily stand-up, a backlog, a time-boxed iteration and an iteration review to be an effective agile implementation. They don’t even consider self-directed and x-functional teams, pairing, full transparency, customer inclusion, quality practices, teamwork & collaboration, and retrospectives as important or necessary.
They iterate for a short while — then fail.
Immediately they blame it on “Agile,” implying that the approach doesn’t work. While nothing could be further from the truth, they simply don’t understand that. Here’s the point — agility is not simply a set of practices that can be individually applied. Instead, it’s a holistic set of related practices that work together to reinforce the core tenets of agile teams.
Can there be some flexibility?
Sure. In fact, the methods foster the notion of “Inspect & Adapt” as a core principle. However, you also need to be mindful of the experience of the team and the relational nature of the practices. Many agile coaches recommend that new agile teams adopt all of Scrum or all of XP’s practices and learn them well before they try composing practices on their own. I think that’s my key issue with the reference that Kupe used and his list — he should have mentioned something about it being a subset and that the methods should be leveraged as ‘packages’ for best performance.
If you want to get a better sense for the depth and breadth of agility, please read the following:
- The Agile Manifesto
- The Principles ‘behind’ the Manifesto
- The Declaration of Interdependence
- The Craftsmanship Manifesto
- The Context-Driven
- Lean Software Principles
I guarantee you’ll come away with a renewed appreciation for the depth and breadth of the agile methods. You still may not “buy them,” but you’ll at least understand their scope.
I certainly hope Kupe isn’t offended by this post. I’m one of his biggest fans and we need a diverse set of views to drive discussion and evolution in our profession. I also think he values and viscerally ‘gets’ the benefit of agility from a holistic perspective.
That being said, we all need to be careful about how we characterize methods. If we’re going to do it, we need to err on the side of completeness. Particularly with something as important as a set of practices (methods) that have proven to be so successful in changing the way we attack and deliver value for technically challenging software projects.
And finally, let’s not call it a fad.
Don't forget to leave your comments below.