Adopting Agile by Piloting Projects

Problem

Only a couple of weeks after arriving at a new company as the product director, I was able to identify three big challenges:

• The product management team was not very experienced and was largely driven by Engineering. They were completely overwhelmed and were a bottleneck to the release, because they were finding it hard to keep up with the detailed requirements that were expected of them.
• The company and people I reported to were certain that our processes were already Agile because we were releasing once a month. But, they hardly were.
• There was little or no flexibility on the part of the dev team. Whenever we needed to change something, even though we had strong reasons to do so, they would reject it, claiming it was too late.

In this circumstance, adopting a true agile methodology seemed to me to be the most effective solution. My practical experience with Agile, though, was scarce. But nevertheless, I felt that I had a good conceptual grasp of what it means to be agile from my previous job, to the extent that I could champion it at my new company.

Actions taken

I went to the executive team and described the above challenges. I did my best to articulate that there was much more to Agile than the frequency of release. I explained three clear benefits including:

1. Ability to more quickly adapt to changing market conditions and customer needs leading to increased customer satisfaction
2. Greater collaboration between PM and Dev, which results in much better products
3. A more efficient and transparent development process.

"There was much more to Agile than the frequency of release."

In all honesty, it took persistence on my part for the other product leaders to entertain a possible process change. Once they agreed to give it a chance, I went to our team in Romania to discuss the approach with them. Not surprisingly, some PM, Dev and QA managers were also convinced that our approach was not "true" Agile and that we should adopt a more agile methodology.

The team knew of an Agile consultant who we brought in to do training for us. The entire product and development team, including the product leaders, attended a two-day-long workshop. The consultant helped us identify our process challenges and explained how Agile could help us solve them. The next step was to adjust some of those practices to our unique needs. The product leaders left Romania and returned to the Bay Area, where we designated a person in charge of leading a team to customize Agile to match our needs.

However, during our status meetings, we realized that once we left progress was being stalled. There were other competing projects to deal with, so the agile working group leader put it lower on his priority list.

We did two things that made the difference to turn it around. First off, we added a steering committee meeting on top of the Agile working group meetings. The CPO and I, as a product management leader, spearheaded the committee -- and brought the agile working group leader, dev leaders and the pm agile representative together every single week initially to discuss timeline, status, challenges and next steps. This sent a clear message of how important this was and that we were committed to getting it done.

I also found out along the way that our development leader didn't want Agile to be introduced. Many developers were happy with the status quo and their reluctance to change was blocking the progress of a company-wide rollout of the new process. At that point I came up with the idea of having two teams pilot the process, rather than trying to roll it out to everyone at the same time. We chose the teams who had good working relationships, where the PM leader and Dev leader respected each other and saw the potential of Agile.

After one quarter of a successful agile process, these two pilot teams achieved remarkable outcomes. They loved the process and did a post mortem in which they invited the other leaders to attend. The working committee captured the process and results, what worked, what didn't and made additional enhancements to the process. They communicated their findings to the rest of the dev organization with the recommendation that the entire dev team roll out the process within the next two quarters. The rollout of agile was a tremendous success, and the process is continuing to evolve each year.

Lessons learned

• Don't take what people are telling you at face value. I had people telling me, "We work in Agile," but that was not what Agile was about. Explore things for yourself -- go beyond what people tell you is happening.
• You have to support your team, which often means coming up with new processes. People tend to oppose new processes, but including the executive steering committee made a difference. When people realized that executives were on top of it and interested in the outcome, they started to take it much more seriously.
• Pilot projects. When people disagree on the approach, take one or two smaller projects to prove your approach. Pilot projects will help build acceptance, especially if you include others who may be initially opposed to the idea. It's always better to have teams share their positive experience and ask for a change instead of having executives impose it.
• Introducing Agile brought many positive outcomes: product became better, more flexible in terms of product development, improved cross-team collaboration, etc.

"Don't take what people are telling you at face value."