Back to resources

Adopting Agile by Piloting Projects

Collaboration
Productivity
Convincing
Agile / Scrum

14 April, 2021

Sophia Broomfield
Sophia Broomfield

Product Management Coach at Coaching PM Leaders

Sophia Broomfield, Product Management coach and leader, explains how piloting smaller projects convinced the whole organization to adopt a more agile methodology.

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: i) ability to more quickly adapt to changing market conditions and customer needs leading to increased customer satisfaction ii) greater collaboration between PM and Dev, which results in much better products and iii) a more efficient and transparent development process. 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
Leadership
Collaboration
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer

Dealing with Uncertainties and Adapting as You Go

14 June

Muhammad Hamada, Engineering Manager at HelloFresh, addresses the uncertainties brought on by the pandemic, how these have affected our work environments, and how we can adapt.

Goal Setting
Internal Communication
Collaboration
Roadmap
Stakeholders
Prioritization
Muhammad Hamada

Muhammad Hamada

Engineering Manager at HelloFresh

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

The Importance of Effective Communication Skills in Technical Roles

3 June

Dursun Mert Akkaya, Software Development Manager at Product Madness, encourages a change in mindset for heavily technical individuals as he explains the importance of communication skills.

Different Skillsets
Personal Growth
Leadership
Internal Communication
Collaboration
Convincing
Career Path
Mert Akkaya

Mert Akkaya

Software Development Manager at Product Madness