As Agile as the Next Guy

Like everything else, this isn't a black or white issue. Small teams without any formalized release process can take down a production system that's being used by hundreds of millions of people. And if you're running 500 teams, the laws of statistics say you're going to have those teams in there somewhere. Some percentage of small teams will kill your company if you give them the chance.

Of course they'll be sorry, but that's hardly helping anything.

The problem is that you can't equally worry about everything. People who sit in conference rooms trying to guide the teams don't have to make the trade-offs that the teams have to make. So for them, more process equals less risk. How can that be a bad thing? If a little is good, a whole lot has got to be better, right? Over time, it just keeps growing and growing, this massive amount of things that somebody, somewhere, somehow thought that might be a problem and what every team has to do to prevent it.

I had a QA analyst who used to advocate teams to do more documentation than the team felt they needed to. When I asked him why he would do that, he said, "Well somebody has to remind these teams to do this stuff. If I didn't, the teams wouldn't do anything"

I'm still trying to figure out what he meant. I know he didn't think teams would all sit around under a shady tree wearing big straw hats and chewing on pieces of grass while they they took turns fishing. He meant well, but since he didn't know what the team needed or not, a blanket advocacy of more process docs sounded, well, crazy.

A lot of my new agile teams are converted to agile so they can deliver much faster using agile techniques -- only they're told don't change anything from the way we're used to running projects. We want it exactly the same, only faster.

Many times agile converts do not help things. Once you understand that the team is generally to be trusted more than other people -- that the farther away you are from the value/risk trade the less useful part you play in the process -- many times you start thinking that any kind of documentation, paperwork, or process is ALL geared to get in the way of productivity.

Sometimes the people who agree with you are the worst enemies for your cause.

These are the guys who get into the "I'm agile but the other guy isn't" conversations. To them, there's a list of things you have to do to be agile, and if you're not doing them, you're not agile.

Sadly they don't see that this is the same mentality that got them Big Process in the first place: the idea that as long as you do the process, the ritual, that the risk has been eliminated. It's the idea that there's a "magic formula" for being agile. Just stand up this way at your stand-ups, hold your showcases this other certain way, be sure to do TDD when you code, pair-program always, etc.

Fail? Must mean you're not doing the formula correctly.

Meet the new boss. Same as the old boss.

These guys are the ones that turn off old-timers looking in. From the outside, agile looks more like a religious or political movement -- let's be kind and call it a management fad -- than a serious change in the way software is done.

I've had agile adherents tell me that you don't need any written work at all to run an agile project -- that all paperwork (except agile artifacts, of course) is just a waste of time. Database design? It grows incrementally. Code design? TDD designs the code as it is needed. SCM planning? It shouldn't need any documents. Documents are an indication of a failure for a team to be agile. Process, in any formal form, is bad.

Sheesh!

Agile is an ideal, a philosophy, not a list. The ideal consists of a lot of good ideas that have been around for decades. True high-performing teams adapt and use a lot of these ideas in many different ways. Agile may mean doing a lot of process docs -- if you're building the next space shuttle. Or it may mean TDD and week-long iterations. Or it may mean a combination of phase/waterfall planning with iterative/incremental development, what we call "AgileFall" or "Waterative"

But at it's heart agile is always looking to adapt. It's the ability of the team to adapt that makes it agile, nothing else. The team is always looking to make itself perform faster and always having conversations about how to do that. Good agile teams have great conversations and adapt quickly. Poor agile teams don't talk or trust each other and do things "the way we did them last time"

That's not saying that you can't learn from each project -- you can. But you don't just copy things from the last project forward into the new one. Templated projects don't work.

It's the all-or-nothing guys on both the process side and the agile side that cause the most problems.

Doing your best to identify problems and adapt? Then you're as agile as the next guy. Keep up the learning and adapting and tell the rest to go jump in a lake.