February 4, 2014

User Manual for Distributed Software Development

Having worked as an offshore software development team leader for ten years I’ve often seen the same situation arise when engaging with new clients, and it’s no different at Waverley. It goes like this: a company (client) decides to hire an outsourcing company to help their internal team with product implementation. As business terms are ironed out, the client’s internal team checks the technology knowledge of the offshore team and if everything seems alright they start working together.

Almost immediately the problem of trust arises. In the first stage of building the relationship there is no trust for the new offshore team. This is absolutely normal, it is a given, a matter of human nature. To fill this “trust gap”, the client often names a trusted engineer as the intermediary between his company and offshore team. Typically, this technical person is busy enough with tasks that pre-date the engagement of the offshore team, has little idea how to manage a remote team or how to set up a productive distributed development process. Moreover, these “management” activities are just boring for an engineer (having been an engineer myself I understand this perfectly). Now add 7-12 hours time difference between the client team and the offshore team and you have a perfect recipe for disaster.

The question is how does one make the “Business owner <-> Trusted engineer <-> Remote team” model work effectively?

The short answer is: with the trusted engineer you have to introduce an Agile development process and the entire team needs to embrace loosely-coupled system design.

Now to make a short answer longer…

When we buy something complex it typically comes with a user manual which explains how to use and troubleshoot it. And when you hire a remote team you are buying something complex. So you should check not just business terms, technical parameters and qualifications but also ask to see the offshore team’s “user manual”. Any remote team that’s been on the market for more than a couple of years has its “client interaction patterns”. Understanding those patters is a very good starting point for building a new relationship. The converse is also true!

Here are a few questions you might ask the remote team leader:

  • What will you do to build my confidence that you are going in the right direction and building the thing I need?
  • How can I know current status of the project at any given time?
  • How can I know what you are working on right now?
  • By what procedure will be manage system changes if (when) we decide to make them?

I’m not going to write another SCRUM handbook! But from my experience on the offshore side of the equation I can say that having a “Vision & Scope” document, a product (user story) backlog, sprint planning meetings, sprint backlog, daily standups, and demo and retrospective meetings helps a lot to make the development process transparent and predictable.

So the first thing to do with a remote team is align around a transparent and tailorable development process. This is a must – without a development process things will fall apart very soon.

Now imagine you have that user manual: you’ve agreed on a development process, you’ve created a “Vision & Scope” document where you’ve captured your goals and metrics to understand which goals have been achieved, and you and your off-shore team have started moving toward those goals.

Here a second problem arises: working on the same project requires a lot of communication amongst members of distributed teams. While there are strategies for organizing this communication there is also the question of how to work in a way that doesn’t require permanent communication. How, in the day-to-day, does a distributed team share a codebase in a way that does not have members block each other?

Loosely-coupled design to the rescue!

How, in the day-to-day, does a distributed team share a codebase in a way that does not have members block each other?

This is the time to ask your in-house project leader, “Is it possible to split system development into independent chunks that could be implemented in parallel?”

If the answer is anything but “yes” – it’s a cause for concern. “No” likely means that system components are very dependent on each other, thereby making the system tightly-coupled. And a tightly-coupled system is an unscalable, hardly maintainable, inflexible system.

One of the key factors driving this grim reality is that Object Oriented Programming is, by nature, tightly-coupled. To meet this problem, the software system architect (project leader) has first of all to employ loosely-coupled design techniques to achieve system scalability, maintainability, flexibility and testability. If this task is solved – incremental and independent development will come by itself.

The main point is this: a properly architected system consists of fairly separate and independent modules or classes that have little to no knowledge of each other. Given such an architecture, it becomes easy to split the work by components and avoid interference amongst team members.

An optimized distributed team development process can be boiled down to the following 5 points:

  1. Define task, describe, discuss and estimate it
  2. Define team (project) roles and agree on formal communication paths
  3. Balance implementation efforts of one portion of the team with code reviews from the other
  4. Demonstrate (ongoing) results to the project stakeholders
  5. Retrospect and review: what went well, what went wrong, identify points for improvements.

And there are many smaller, but still important points that will enhance the remote team’s output:

  • Trusted engineer is interested in remote team’s success
  • Both sides understand and appreciate a transparent and tailorable development process
  • Trusted engineer provides feedback to the remote team regularly
  • Use technology to improve collaboration (screen sharing, video conferencing, etc.)
  • Leaders of both teams meet in person to align their vision on project goals, create an achievement roadmap, and, ideally, build the project backlog together.

If you decide to use an “external muscle” to strengthen your product development, don’t forget to ask the remote team for their “user manual” and development process before things get going. Then make the investment to move your system towards loosely-coupled design principles and practices. If these things are done right, the “trust gap” will be bridged very soon, typically in 5 to 10 sprints. And it will result in a pleasant sensation as you lay down to sleep each night, knowing that your project keeps growing and moving in the right direction while you are sleeping.