Article

Agile Considered Harmful

Dietrich Kappe

Published on: September 10th, 2010

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Daniel Markham is seriously pissed off about Agile. In his most recent blog post, Agile Ruined My Life, he takes off his belt and beats the crap out of all those agile loving hippies. 😉

But seriously, there does seem to be a backlash against agile development methodologies in some quarters. If you read Daniel’s post carefully, though, you’ll see that despite the sensational title, it isn’t really a rant against agile development, but rather an indictment against imposing agile practices in a corporate, top down way.

I’ve had the pleasure of working in a company that I started more than 11 years ago, and from the beginning, we tried to practice agile development. But not everyone was on board in the beginning, and, aside from myself, there was little culture or buy in. It took us quite some time to bring in motivated “A” players with agile experience. (Thanks, competitors, for trying and abandoning agile, leaving us with a pool of qualified developers, product designers and PM’s.) It took us even longer to hone and productionize our process to where it is flexible, reproducible and highly efficient.

The key is that our agile culture grew organically, over time, and the people who we now attract as employees are highly motivated folks who have heard about the way we do things. We didn’t slavishly follow any one school or type of agile, but instead focused on a few core concepts:

The feedback loop
Self-organizing teams
Short iterations
TDD
Pair programming
Continuous improvement

Contrast that with one of Daniel’s observations:

One of the things I hated most about agile is when management decides to “be” agile, only they don’t want to change anything. So then you’re teaching a team that they are in control, that they are responsible for important decisions about how much work they can do in each iteration and how to do it — only they aren’t. This destroys morale faster than anything. A while back I turned down teaching TDD to a team. Why? Because somebody up above had decided the team was doing TDD, not the team. The class would have been three days of me trying to share things that the team had no desire to hear and wasn’t going to practice. A lot of other coaches — the vast majority, probably, would have taken that gig, but I’m not going to be part of the problem. Courage isn’t just for teams.

Key concept: teams have to be in control; you have to let them choose how they are going to develop software; they have to have the capacity to take ownership of their own destiny — that isn’t for everyone. Provided they have all of these conditions in place, they may decide to develop software in an agile way or not. Ownership and self-organization is going to give you better results than imposing agile from outside. Once a team has settled on a way to develop software, adding new people into the mix and integrating them into the process is much easier. Of course, in the corporate environment, the long term presence of the above conditions is laughably unlikely, even in good organizations.

Small Steps

We’ve also had experiences introducing agile practices into other organizations. Some of those efforts have been qualified successes. Most of them have had some beneficial effect for the client, but to call those organization agile would be overstating the case by a mile. To be truly successful, the entire organization has to change, to embrace an agile business and operation process, not just one for software development.

The ones I would consider successes are those where we developed a product for the client — essentially leading by example — and they liked our process so much that they introduced some agile elements themselves. We’ve had clients introduce pair programming, TDD, and scrum into their organizations. Yes, the scrums can turn into an hour long status meeting, and TDD can turn into test after development (pair programming, surprisingly, tends to stick much better). But some benefit does seem to accrue. People see a way out of some of the dysfunction that has bedeviled their organization for years.

More often, the organization picks some aspect of agile (corollary to Daniel’s “Cargo Cult Agile”) and works it to death. I can tell you stories of the 300-page user story document that got thrown in the trash, or the 6 months ever expanding iteration.

In truth, most organizations aren’t capable of this kind of change. That’s why many companies spin up internal skunkworks, such as the one that developed the PC at IBM. Or an insurance company that I know of that acquired another company for their business lines, but ended up throwing all sorts of development projects over the fence, not because that acquired company’s development chops were that strong (they weren’t), but because they weren’t as moribund as the parent company’s IT department.

Anyhow, lots of good things in Daniel’s post. Lots of things to chew on and examine in your own agile development efforts. Go on over and give it a read.