Successful Outsourcing in an Agile World : A Retrospective

Today’s Community Contributor is Eric Hodge, Software Engineering Manager at Waters Corporation. He is a Certified Scrum Master and has written several detailed reviews on TrustRadius of the tools he uses at work. Here, he takes a look back at his most recent experiencing working with an outsourced Agile team and shares some advice on how he made their partnership a success.

Choosing the Right Outsourcing Partner and Knowing When to Re-Evaluate

At the start of our software development project, I selected a team whose statement of work said all the right things about Agile, while having a good mix of technical skills. At our first sprint planning meeting, however, it became apparent that the team, while technically competent, had no formal Agile experience. Sprint planning quickly turned into a crash course in Agile 101, and we were off to a rough start. After a couple of weeks of playing the roles of Agile Coach, Product Owner, and Scrum Master, I realized the project could not continue like this.

I had previously raised my concerns about the lack of Agile experience to my colleague managing the business relationship, so I was well supported when I decided to cut ties and move on to another outsourcing organization. This was the first success of the project – both knowing when to move on from an ill-equipped team, and having the support of management to make that move. Struggling through Agile ceremonies would only have slowed the project down, or resulted in a return to Waterfall, neither of which I wanted for this project.

I engaged a second outsourcing organization, whose team immediately demonstrated working knowledge of Agile. They quickly ramped up on the project and delivered repeatedly in the initial sprints. During this time, we built trust based on their Agile experience and ability to deliver. While playing the role of the Product Owner, I became part of the team, not just a U.S. based overseer. As part of the team, I could engage with the team as an SME, while providing direction, insight, and priority as a product owner.

This two-way engagement built the rapport that enabled critical conversation and accountability. Agile imparts the ability to hold the team accountable to itself for delivering on stories, enabling the team to have conversations about the “doneness” of a story without it ever becoming a personal issue. Building that trust and rapport by being an engaged team member enabled critical, story-focused conversations.

Introducing Flexibility into Teamwork

Due to timezone issues between the Eastern United States and India, we limited our ceremonies to a Backlog Refinement meeting and a combined End of Sprint Demo/ Sprint Planning meeting. Using Agile meant that meetings had a set purpose and were well focused. End of Sprint Demos were very typical, however, we found that it was difficult to demonstrate all of the planned stories during our scheduled demo. To address this issue, I asked the team to start recording demos of less-complex stories earlier in the sprint.

As product owner, this allowed me to review the demos, and either accept or provide early feedback. Providing early feedback enabled developers to address issues with acceptance prior to End of Sprint. We reduced story cycle time by 47% and cut story rejection down to 3% from the 26% we’d seen before introducing the videos.

I also engaged onshore stakeholders to attend end of sprint demos. Stakeholders were able to provide real-time feedback on demonstrated stories and that feedback would become new stories on the backlog. Our stakeholders also participated in an onshore-only Backlog Pre-Refinement meeting, where we’d collectively prioritize the backlog, based on demo feedback or which stories gave us the most value going forward. Having engaged stakeholders helped drive the success of the project by ensuring that the team was building the product the stakeholders wanted.

The ability to incorporate feedback and re-prioritize features based on the needs of our stakeholders is a central principle of Agile. When compared with other methods of running outsourced projects (waterfall, for instance), the value of change becomes clear. In an outsourced waterfall project, any change results in a cumbersome change request process, along with changes in cost and schedule. Eliminating change requests and their associated costs and overhead alone justifies Agile as a successful framework for outsourced projects.

With a feature set changing as a result of shifting stakeholder needs, I wanted to ensure that the team continued to deliver working increments of software with each sprint. I asked the team to produce releases at the end of each sprint once it was feasible to do so. With each sprint release, I was able to deploy that sprint’s stories out to our production server for consumption by our stakeholders. This enabled our stakeholders to gain immediate value from delivered stories while ensuring that the delivered product was production-ready.

By the end of the project, the delivery of the finished product was a simple upgrade from a previous sprint’s deployment. Continuous delivery of working increments of software ensured that the project could be deployed to production with a high level of confidence, again contributing to the success of the project.

Each of these successes represent a principle core to Agile and how they can be applied in an offshore context. As one can see, almost nothing changed from traditional Agile, illustrating the robustness and adaptability of Agile as a framework. More than any other training, this implementation of Agile proved out the effectiveness of Agile for me. With this hands-on experience, I remain convinced and committed to the value of Agile going forward.