The Agile Guerilla

While it certainly seems that agile software development has gone mainstream, I still encounter a number of software developers who work in one of two environments:

1. A traditional waterfall process shop, complete with a serial workflow through requirements, analysis, design, implementation, testing and deployment.
2. A "coding by coincidence" [Hunt99] shop, having no semblance of process or standards. A shop where development just seems to happen, and finished software occasionally gets deployed. Plenty of finished bugs get deployed too.

I've seen and interacted with developers from both of these environments, and I've also been in both environments myself. I can tell you from experience that neither of these are very happy places to be if you've taken the agile "red pill."

With this article I'm starting a new series (that will normally appear on Thursdays) entitled "The Agile Guerilla." The focus of this series will be on strategies for introducing change, specifically moving to agility, into your organization from the grassroots level.

"Agile transformation" is all of the rage these days. Everywhere you look a new company is "going agile." Usually this means that a high-level executive in a company sees that #1 or #2 isn't working for them, so they ask their executive buddies for advice. One of them says, "Hey man, you need to go agile." This starts a top-down, mandated transition to agile, all too often focused on purchasing some form of agile project management software, and all too often resulting in an abysmal failure.

My goal in writing this series is to help you, the developer (or front-line manager), use effective strategies to spur on an agile transformation from the bottom up. I've seen this kind of transformation work very effectively. I personally have been one of the change agents that got the ball rolling. I'd like to see as many of you as possible that find yourselves in shop #1 or #2 get to a better place.

We'll begin by looking at a couple of different approaches to introducing change into an organization, and we'll explain exactly how the term "guerilla" fits in.

I can be a bit of a war history buff at times (though unfortunately this has fallen by the wayside as of late), so I'd like to look at two major strategies for introducing change:

1. The Full Frontal Attack
2. Guerilla Warfare

I first tried to introduce agility (specifically Extreme Programming) to my organization in 2003 after reading "the White Book" [Beck00] and attending the 2003 XP/Agile Universe conference in New Orleans, LA (were you there?). I felt like I was some sort of "developer utopia." I was hanging out around folks like Kent Beck, Bob Martin, Ken Auer, and Brian Marick. These guys really got it. They understood what it took to develop quality software that delivers value in the face of continually changing requirements. I had to bring this stuff home and "fix" my team. So I got back to work and painstakingly crafted a Powerpoint manifesto and signed up to present at the next department meeting. The full frontal attack was on.

I'm sure you can guess how that worked out for me. Before I knew it, questions and comments started flying:

• "So who's going to test the test code?"
• "Two programmers? Working on the same code at the same time? That's not very efficient!"

On to Plan B. It was time to become a guerilla.

Our modern word "guerilla" traces its origin to bands of Spanish fighters who fought Napoleon after he occupied Spain in the early 1800's. One of their leaders was a man by the name of Juan Martin Diez. Diez's primary mission was to disrupt the supply and communication lines of the French army by intercepting their communications and by seizing convoys carrying needed supplies, arms, and money.

Diez's bands of guerillas did so much damage to Napoleon's army that Joseph Leopold Hugo, one of Napoleon's generals, was ordered to "pursue exclusively" Diez and his forces.

So what exactly is guerilla warfare? It is a form or irregular warfare, which is any warfare that is waged by a non-standard military group. In this case we're talking about a small group of combatants using mobile military tactics such as ambushes and raids to combat a larger, less mobile army. Their goal is to slowly erode their adversary's power, influence, and will.

So what does this have to do with you? For most of you (I was definitely included in this group), you have a relatively small amount of influence on how your particular organization develops software compared to your most senior engineers, team leads, and managers. You find yourselves in shop #1 or #2, where things are either extremely rigid or extremely chaotic. In either case, your environment comes with a relatively high inertia to changing the way things work. Do you see the parallel? Diez's fighters didn't have a great deal of direct influence on Napoleon's army. And yet, the sheer size of his forces created a great deal of inertia. They were unable to respond effectively to Diez's tactics because they couldn't move quickly enough!
I can tell you from experience that applying these same principles to agile transformation work.

That's it for this installment. Next time we'll take a 50,000 foot view at two key tactics used by an agile guerilla: demonstration and persuasion.

References

[Hunt99] Hunt, Andrew and David Thomas. The Pragmatic Programmer. Addison-Wesley, 1999.

[Beck00] Beck, Kent. Extreme Programming Explained. Addison-Wesley, 2000.

Wikipedia: Guerilla warfare. http://en.wikipedia.org/wiki/Guerilla_warfare