The Load-Bearing Walls of the House of Agile
A few weeks ago, I ran across a very provocative post by James Shore called The Decline and Fall of Agile, followed by an equally provocative (and long) string of comments.
Mr. Shore argues that many firms think they are adopting Agile, specifically Scrum, without really understanding what’s essential and what can be safely left out. I heard my first hint of this around the pool at SD West in 2003, with someone saying, “We do XP, except we work 80-hour weeks, scope and schedule are fixed, and we’re not doing any automated testing.” “Here we go again,” I remember thinking.
One of the many commenters pointed out that Agile is merely following the Gartner Hype Cycle, and is now sliding down the backside of the Crest of Inflated Expectations towards the Trough of Disillusionment. That sounds about right to me.
One of the things I tell my clients is that Agile methods are by their nature adaptable and pragmatic, but that they also have the equivalent of load-bearing walls. Destroy the integrity of one of those, and you collapse back into cowboy coding. IMO, the load-bearing walls are:
- Delivery of finished, working software at fixed intervals measured in weeks (single digits)
- Variable overall scope, adjusted to actual rate of delivery of #1
- Quality practices that prevent the accumulation of technical debt
Mr. Shore criticizes Scrum (the most popular of the Agile methods) for lacking #3, and he’s right. I believe the creators of Scrum would agree with him. But, unfortunately, a lot of what another commenter referred to as (FR)Agile methods don’t recognize Quality Practices (automated tests, refactoring, code reviews and/or pair programming) as a load-bearing wall. Technical debt builds up and after a half-dozen or so Sprints their velocity begins to drop and they end up with un-maintainable slop.
Another common error is the adoption of Agile by the technical folks, but without the business folks or customers accepting #2, Variable Scope. Without that load-bearing wall, the inevitable estimation inaccuracies and changing expectations put the team in a schedule-pressure situation where they begin abandoning #1 and #3 just to get through the day, and the whole thing falls down again.
A friend of mine used to say that all warning labels could be replaced by a single label that read, “This equipment is not to be operated by idiots.” He would then go on to say that if you climbed a ladder with a running chain saw, and It Did Not End Well, it would be up to your (or your heirs) to convince judge and jury that you were indeed not an idiot.
The same is true of Agile Methods, and even of the much-maligned Waterfall. Think before you start adding stuff or tossing stuff out, and if you don’t know how to think about such things, or don’t have the time, then get someone on your team who can, and listen to them.