Going Guerilla: Where to Start

Welcome back to another episode of The Agile Guerilla series. The focus of this series of articles is to to help you introduce change, specifically moving to agility, into your organization from the grassroots level.

In our first episode, we defined guerilla warfare and looked at why using guerilla-like tactics can be an incredibly effective way to spur on an agile transformation from the bottom up. Then, in episode two, we zeroed in on the two fundamental tactics employed by the agile guerilla.

In this episode, we'll examine where to begin. A brief survey of the agile literature will uncover a plethora of ideas about how to "do" agile. Some of these ideas are quite similar and compatible, while others are quite different and oppositional. Should you focus on the dynamics of your team and how you manage your work? Or should you stick to engineering practices and how you can write better, cleaner code?

My own agile journey took an interesting turn when I first read one of my favorite books of all time, Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt. The second chapter of this book is entitled "Beginning Agility". Venkat and Andy take a slightly different approach than I had seen before, asking us as agile developers to turn inward and look at ourselves and our own behaviors. They state:

Agility works only when you adopt a professional attitude toward your project, your job, and your career. Without the right attitude, these practices won’t help all that much. But with the right attitude, you can reap the full benefits of this approach. Here are the practices and advice we think will help.

They go on to address four different behaviors, which I'll name and summarize below. If you take their advice and engage in these behaviors, you're guaranteed to be more agile, even if your team never adopts an agile practice. Believe me, I'm not a salesman; I'm a satisfied customer.

Work for Outcome

The idea here is a shift of focus. So often when a problem occurs we rush to defend ourselves and find someone else to blame.

• "That's not my code that's causing the problem, it's yours!"
• "If the customer had just told us what they really wanted, we wouldn't be in this mess!"
• "It works on my machine!"

It's unfortunate that we behave this way, because it is intensely counterproductive. The problem isn't you, your teammates, your manager, or your customer. The PROBLEM is the problem. Your focus should shift from who caused the problem to working to resolve the problem. Or, as someone as so aptly spoken, "Fix bugs, not blame."

Quick Fixes Become Quicksand

There's no such thing as a free lunch, and this axiom is especially true when it come to your code. It may seem like you're saving time by "kludging in" a quick fix, but you're actually borrowing time. Code that's too hard to understand is code that's too hard to maintain, and make no mistake about it, you (or some other poor soul) will have to maintain that code.

A 1994 study showed that the average Fortune 100 company was then maintaing approximately 35 million lines of code. The measured rate of growth showed this amount doubling every seven years. Based on this research, we can only assume that these companies are now maintaing somewhere around 91 million lines of code. If you're going to maintain that much code, you'd better make sure it's understandable.

Furthermore, it's not enough that your code works. Make sure you understand WHY it's working. Every quick fix you add to your code without fully understanding the true problem is like building a mine field around yourself.

Criticize Ideas, Not People

It may surprise you, but developing software has nothing to do with massaging your own ego. Your ideas aren't the best in the world, and there are people out there that write far better code than you do!

So the next time you feel yourself getting torqued while a teammate is explaining his "obviously inferior" design, step back for a bit. Be polite and courteous. If you've got concerns, lay them out constructively. Defuse any emotional tensions by being conversational. Focus on solving the problem at hand, not on whose idea is better.

And then, when it's your turn at the whiteboard, don't be afraid to receive feedback.

Damn the Torpedoes, Go Ahead

It was Civil War Admiral David Farragut who famously said, “Damn the torpedoes! Captain Drayton, go ahead! Jouett, full speed!” Yes, there were mines in the way (called torpedoes at the time), but they had to get through, so full speed ahead they went.

We often talk about managing risk in software development, and we're almost always talking about project-level risk. But there's personal risk involved too.

Have you ever been in a situation where you knew that the right thing to do was to toss the crappy code that you were looking at and rewrite it rather than try to wrap yet another bandaid piece of functionality around it? What did you do? Did you keep quiet? Did you complain behind the author’s back? This practice says no - that’s ineffective. Instead, be courageous. Present the pros and cons of working with the existing code versus rewriting it. Show, don’t just tell, how much more effective it will be. Give your boss and colleagues reasons that will help them properly evaluate the situation and come to a good solution.

Now, have you ever been working steadily on a feature for several days and realized that you’ve been "barking up the wrong tree?" That you should really toss your work and start over? No matter how nervous you may be about the static that you’re about to get confessing the problem and asking for more time, always communicate the truth. Don’t try to cover up the issue. Admit that you’ve taken the wrong approach and give some ideas on how you might fix it. Ask for suggestions. Just like with criticize ideas, not people, you’re diffusing a potentially emotional situation.

Summary

Before you begin trying to change your organization, turn your focus inward. Address your own flaws as a developer and as a person. Follow the wisdom of Jesus: "...first take the log out of your own eye, and then you will see clearly to take the speck out of your brother's eye" (Matthew 7:5b, ESV).

I highly encourage you to pick up a copy of Practices of an Agile Developer and learn more of Venkat and Andy's wisdom about "Beginning Agility" and much more.

That's all for this episode of The Agile Guerilla series. Check back next week when we'll start looking at how you can transform your personal workflow and become more effective at delivering on your tasks.