Distributed Teams – Problem or Opportunity?
8 December 2015
One of the first DSDM / Agile projects I worked on was what we would today term a distributed project. The project was for a major newspaper group in the US, based in Boston MA.
We had just acquired a company that made software for the newspaper industry and inherited one of their failing projects. They had used waterfall to define requirements and then went away for 18 months to finally deliver something that the newspaper did not want. The situation was serious – the newspaper was about to take legal action.
We persuaded them to try a different technique – then called iterative development, now called Agile. We undertook user workshops to set firm foundations and to start to build relationships. We also set up teams in two locations to produce the solution – one based in the offices of the newspaper and one based in our head office in Cambridge, UK.
So how did we manage the distributed teams?
Setting up firm foundations is key
Taking the time (but only enough) to understand the problem and to define the prioritised high-level requirements enabled us to partition the development between teams in a way that made sense but also ensured that all the teams understood the overall vision, plans and architecture.
Having a core team at the customer site.
This team were our ears and eyes into the real, constantly changing, world of the customer. It gave us a form of colocation. We were able to resolve issues quickly, whether they were issues of understanding requirements or political issues brewing which you can only sense when you are in the same location.
Most members of the off-shore team in Cambridge also visited the customer site – this helped them bond with the on-shore team but also gave them a deeper understanding of the customer and their situation and requirements.
Regular daily meetings between teams
Even though the teams were separated by 3,000 miles and 5 hours, it was still possible to organise daily, short meetings (I guess called stand ups these days) at the start of the US day and the middle of the UK day. These were invaluable for building cross-team communication and collaboration.
The technology of the time was teleconferencing but today we would use video conferencing when required.
Constant ad-hoc communication between teams
Each team took the responsibility to communicate (via an early UNIX instant messaging and telephone) whenever they needed to resolve issues. This speeded up resolution, and consequently development, immensely.
Facilitative Project Management
As project manager, I felt it was my role to let the teams get on with things, but also to ensure that we would meet the requirements of the customer and the vision of the project. It was also invaluable to travel between the sites, as some issues, either with the team or the customer, only become apparent when you meet them face to face.
Face-to-face meetings at key points
Although remote conferencing tools work for a large percentage of communication, it was still desirable to hold face-to-face meetings at key review or development points.
As well as ensuring real understanding and facilitating fast decision making, they are an opportunity for all teams, including members of the customer, to reinforce their relationship and to resolve any conflicts that may build up.
The DSDM Framework
The DSDM framework really helped in this project. It gives good guidance on setting up firm foundations and in multiple team structures. This makes the challenge of distributed teams that much easier.
So how did it go? Within three months, the first increment of the system to track pages was live in Boston, closely followed by the sister newspaper in New York. The second increment, which added a graphical user interface (quite technically challenging 20 years ago) followed three months later. The customer was extremely happy and all legal threats disappeared.
Project Manager Today March 2015