The Agile Architect

You Can't Do Agile If You Haven't Seen Agile

Do all the research you want, but according to our expert, successful agile transitions require someone who's actually spent time in an agile environment.

• By Mark J. Balbes, Ph.D.
• November 10, 2011

So I'm sitting at dinner in a crowded restaurant. Across from me is my government representative. Next to me is a contractor from a competing engineering company. We're part of a long table of people trapped in a small town for "meetings."

I'm feeling pretty good. The meetings are over for the day and our software showed well. We're eating at a centuries-old historic restaurant, good food spread out in front of us, a beer at the ready. I start talking with the other contractor about how we do agile software development and I'm laying it all out for him, giving every detail about how we create our magic. Suddenly I feel a kick from under the table. My government rep just kicked me. I ignore him and continue on. He kicks me again. Then he leans over and whispers to me "He's the enemy!" I smile at him, responding, "I know," and keep going.

Later, I take my government rep aside and explained why I had no problem telling our competitor everything about our agile processes: "If he actually tries to implement what I told him, he will fail spectacularly." It wasn't that I told him anything wrong. In fact, everything I told him was said in all sincerity. (If you can't tell yet, I like talking about this stuff.) And yes, this is an absolutely true story.

Here's the issue: You can't implement an agile program if you haven't seen it in a successful environment. It's just too different from traditional methods. If you try to do it without the help of someone who's lived it before, you are very likely to fail because you won't know the techniques to solve the unique types of problems that come up. Agile is not a panacea that will solve every problem. Sometimes it creates problems that you wouldn't have in a more traditional environment.

Here's an example: Imagine you are a member of an agile team. You have two programmers that are pairing on a story. (That means they are coding together at the same computer, sharing a keyboard and monitor, and talking constantly about what they are building. Yes, that really works, but that's a different column.) But they come to an impasse. Each has his own ideas about how to implement the story. They both want to implement their own ideas and refuse to implement their partner's ideas.

In a traditional environment, this is much less likely to occur. Without pairing, the developer assigned to implement the requirement will simply implement it how he wants. By the time you get to a code review and another developer looks at it, it's usually too late to change it. After all, you've got other work to do and what's been done does work, even if it's not perfect.

But now you're in an agile environment where this kind of problem is relatively common. What do you do? You might be tempted to have each developer present his case and then you decide which solution you like better. And you're probably wrong because you don't know the code they are working on as well as either of them. Or you might be tempted to implement whichever solution can be done faster. Again, not so smart.

What would I do? Depending on the situation and who the developers were, I'd do one of two things:

1. Ask the developers to spend, for example, an hour implementing one of the solutions. When the hour is up, switch to the other solution for another hour. After that, revisit the problem.

Most of the time, when you do that, the pair realizes within the first half hour or so which solution they should use, or in some cases that there is a third solution that works even better. That's because instead of arguing about the theoretical validity of their solutions, they spent their time digging into the code together to make something work. And by doing this, they learned something new. It's rare that this approach doesn't work and that you don't rapidly get consensus. This approach frees the developers from worrying about which solution is right and instead focus on getting one of them to work.

2. Ask each developer to spike out their solution independently. That means that they rapidly implement their solution without the benefit of automated tests. They can quickly vet their solution and then present it to the team. As above, its unusual for one of the developers not to realize quickly that their solution doesn't work. Once they understand each other's solution and figure out the right direction, they throw away their spike code and start over, writing production quality code using the test-driven development methodology.

I typically prefer solution 1. It keeps the pair together working on production code. I would use solution 2 if it were apparent that both developers were so stuck on their own ideas that they had to get it out of their system before they could concentrate on something else.

In my last column, I left you with a teaser.

Now just imagine…It's a dark and stormy day. In the conference room, you've just finished your pitch to upper management about why you should move your company from your current development practices to an agile approach. You've laid everything out like a lawyer making his case to the jury. They laughed in the right places. They nodded in approval. And as you wrap up your masterpiece presentation, the thunder outside cracks and the president of the company chimes in. "That's nice in theory but it'll never work in practice."

What do you do now?

The reality is that the engineer making the presentation is right and the president is right. Or maybe they're both wrong. If the company tries to implement agile practices across the board, they are doomed. It's just too hard to change everything at once. People will get frustrated because they will no longer know how to do their jobs, so they will fall back to their old ways because it allows them to make progress.

Instead, it's better to start small. Find a pilot project that is low priority so there isn't pressure to finish in an unrealistic amount of time. Bring in an agile coach to train a small group of engineers and stay with them as they implement agile processes and practices. Get some success and build confidence. Solve the difficult problems that are unique to your company and your environment. Once you've succeeded, move on to the next project. You can seed the new team with your now-experienced developers from the pilot.

Keep the agile coach around as long as possible. It takes years to get proficient and have a clear understanding of how to tackle different issues. Make sure that the projects are staffed with people that truly embrace the new agile paradigms. A single person can poison an agile project if they aren't willing to change how they think and work.

As your teams switch from a requirements-driven approach to a customer-centric, agile approach, you'll see the people on the business side of your company begin to understand the power of this new way. When product managers can change their minds, when the sales team can make suggestions and see them quickly implemented, when customer service sees that pushing out the new release is not a big deal, they will also jump on the agile bandwagon creating more pressure in the company to move in this direction.

Just don't try to do it all at once.

Read more The Agile Architect columns from Mark J. Balbes, Ph.D.:

• Agile and CMMI, Part II: Tips from the Trenches
• Are Agile and CMMI Compatible?
• What Does an Architect Do in an Agile Shop?
• Welcome to The Agile Architect: 3 Agile Misconceptions