Optimizing Distributed Team Results

eCommerce Client Leverages Outsourcing Team to Explore Different Approaches

The Challenge

This client had effectively adopted Scrum across a large, robust team of software development and quality engineers. They had vendors in place that had successfully worked with them for many years, but they still wanted to evaluate and add development partners to their development team, which had an impeccable local reputation. They provided an excellent work environment and attracted the best in local engineering talent—but like every other development team, they still struggled to add new people quickly.

With just over a year of leveraging the benefits of Scrum, their very strategic head of engineering was interested in experimenting with new methods to improve efficiencies when working with distributed teams.

The Solution/Outcome

We offered the client the opportunity to evaluate each new member to the team and suggested starting with a small team to take on a “crawl, walk, run” approach. We did our best to add people within 30 days, but focused more on understanding the kind of people they like to hire and matching them with engineers with the right set of both technical and soft skills.

Our initial projects included successfully implementing Kanban for the production support team, experimenting with concepts like swarming, and testing a flavor of pair programming that works great for teams working in two different time zones.

Today, we work for multiple teams on many projects. We continue to experiment with their technical leadership and work together to continuously find new ways to reduce the productivity tax associated with working with distributed teams.

We know what kind of people are the perfect fit for them. We’ve gained their trust and as a result continue to add people to various teams to grow with them.

The Backstory

In evaluating us as a vendor, the head of engineering had a very specific first set of questions:

  • Give me details on how you’ve worked under Agile with other development teams.
  • How can I trust that you really have good engineers?
  • How fast can you ramp up?
  • How do you structure your teams to work with my team and more specifically why do you require a lead on your side when I have one on mine?

We had answers. He drilled us on Agile development, was satisfied that we had good knowledge, and determined we could work well with his teams.

As a leader, our client had mastered the right balance of oversight and autonomy. Technical leads are encouraged to customize the way their team works. All teams follow the basic principles of Agile development, but they all work a little differently. We were allowed the same level of autonomy. The engineering head wasn’t 100% convinced of our need for a lead on our side, but gave us an opportunity to show him the value.

We believe in providing development teams with a technical project lead on our side providing day-to-day and face-to-face management for our engineers. However, we balance this with full transparency and connecting our engineers with the client team for true collaboration in an effort to reach our goal of being an extension of the local team. After working with us, the client-side technical leads came to see and understand the value of having someone they could depend on to lead us, their remote team.

One reason why we like working directly for an engineering team instead of a business unit is we believe everything just works better, which results in higher quality deliverables and a better quality experience. We speak the same language and working under internal technical leadership ensures our success. Another reason why we prefer to work for strong engineering organizations is that they challenge our people, and that helps us retain top talent. We learn from every client, refine our service model, and thus provide a higher level of service.