The Agile Architect

Picking an Agile Pilot Project: First Impressions Matter

This may be the most important decision in getting agile implemented in your shop long-term. Mark J. Balbes breaks down all the criteria to help you make the right choice.

• By Mark J. Balbes, Ph.D.
• January 24, 2012

It was my first day on the job. One could argue that it was my first day on any job, having just finished five years of graduate school and three years as a post-doc.

I sat at my computer staring out the window in front of me. I was in a large cavernous office with space for 20 people, deserted except for my single desk, the only desk in an entire empty wing of a large manufacturing facility. Next to me was a vacuum cleaner.  Though I had no human companions, I was not without company. The wasps were everywhere. Those that were alive circled the room above my head. The dead corpses that had littered the carpet were now safely entombed in the vacuum cleaner given to me by the company president.

It was my first day on the job. What the hell had I gotten myself into?

First Impressions Matter!
Recently I've been thinking about how to choose a pilot project for a company that wants to transform its business to agile.  In such an undertaking, first impressions matter. The pilot project will be, for many in the company, the first time they've seen agile, let alone be so close to it that they can touch, taste and smell it.

Based on my experiences with agile transformation, here are some general guidelines and best practices to choosing a pilot project:

Start Small
Pick a project that is small and self-contained. Build on this success with other projects that are progressively larger and more entwined with the rest of the company. The scientist in me likes to think of this as a crystallization process. Each crystal of agile success will lead to the entire enterprise being transformed.

When starting a pilot project, there will be confusion. Team members don't know how to do their jobs. Some every-day tasks no longer exist. (No code reviews? Really??) Others are transformed beyond recognition. (What do you mean I have to write a story? You mean like "Once upon a time…?")  Starting small reduces confusion, allows the rest of the company to continue as usual and buys time for the pilot to be successful.

If too many people don't know how to do their jobs, you'll see the crystallization process break down as people return to their old ways so they can get their work done.

Choose the Right Team
Make sure you are staffing the team with members who are excited about the new direction. The pilot cannot succeed if the team members do not believe in it. Any members that are not on board with the changes should be reassigned. Project members need to be committed, willing to learn new techniques and take the time to apply them. A single negative voice can poison the atmosphere for change. And God help you if there is more than one. That's when the conspiracies begin.

If you are bringing in outside consultants or contractors, or are hiring new staff with agile experience, make sure it is the right kind.  I've interviewed many people who claim to have agile experience but when asked detailed questions either don't understand what it really is or are very shallow in their knowledge. They may be more of a hindrance than help.

Get Support
It is equally important to get buy-in from other departments. Product management, marketing, customer service and others all have a stake in the pilot, whether they recognize it or not. It's easy for them to be threatened when it looks like the pilot project is trying to usurp their authority. Explain to them what you are doing and their role in it. Be non-threatening and ask how the pilot can help solve their current problems. You can't solve all of their problems at once, but maybe you can address one or two that will have a positive impact for them.

Choose a Project With Minimal Risk
Choosing a project with the right level of risk is tricky. You want the project to have some hurtles. Otherwise, nay-sayers will point to it as a trivial accomplishment. Too much risk and the project may not succeed. We always claim that agile methods can deal with risk more effectively than traditional methods. This is the time to show it. But not too much!

Choose the Right Level of Criticality
Choosing a project with the right critical nature is an art. You don't want to choose a project that is so critical that the pilot doesn't have time to get established before unrealistic deadlines and expectations are set. On the other hand, you don't want a project that is so unimportant that no one cares if it gets done. In that case, you won't get the support you need from other departments and you may find that the project slowly dissolves from attrition as team members are pulled onto more critical tasks.

Choose a Project With the Right Schedule
As with criticality, you want a project with a schedule for delivery that is quick enough that the rest of the company sees change but long enough to absorb the loss of effectiveness of the team as they initially ramp up on the new agile techniques.

Choose the Right Technology
Don't try to use new technologies at the same time you are changing your software development methodologies unless those technologies are part of that transformation. For example, if the team hasn't done automated testing before, then learning to use an automated testing tool is a must. On the other hand, changing to a brand new programming language is probably a bad idea. The team will have enough difficulty adapting without adding extra complexity and unknowns.

Create the Right Work Environment
Set up a war room. Rip out the cubicles. Create pair programming workstations. Put up a lot of white boards.

Location matters but it will depend on the culture of your company. Ideally, you'd like the war room visible so that everyone sees what you are doing. Invite them in. Explain everything that's going on. Ask for their input so they have a vested interest in the success of the project.

Stick to the Plan
This advice looks like common sense, and it is, but you would be amazed at how easy it is to be seduced by conversations about conquering the world. Keep to the original objectives of the project. Different department heads and managers have their own take on what should be done, and if you lose focus off the small software development pilot project, you may find yourself trying to transform the entire enterprise all at once.  Stick to the original scope of the project, show success and, bit-by-bit, you will see the transformation you are looking for.

Final Thoughts
First impressions do matter.  The best way to make a good impression is to have a successful project with a happy team that likes how it is working. While verbal communication to outside stakeholders matters, showing them real progress through big visible charts, Kanban boards and, of course, regular demos is a much more visceral way to communicate.

And about my first job... It turned out that my first impression was dead on. I left after 11 months and the company was out of business shortly afterwards. There were two good things about the job: It prepared me for my next job, which was awesome, and it gave me a lot of good stories to tell. But you'll have to keep reading to hear them.