A Distributed Team working out of a Common Backlog

Even though working out of a common backlog might seem the most obvious thing to do, a lot of teams I worked on previously did not do it, or do it that effectively.

Having a common product backlog of stories enforces at the very fundamental level that it is one team spread across multiple locations than two teams.

Benefits

Having a common deck of stories for both locations has the following benefits

Strong levels of trust and collective ownership across people at both locations

Since people across both locations are looking at the code written by each other regularly, it ensures that there is strong collective code ownership. Consistency in coding styles, metaphors, development processes, etc... all fall in place in the long term.

Having a common standup, iteration planning meeting, developer huddles, showcases, retrospectives etc... helps to synch up the team across both locations.

If teams are working on different backlogs, there are always late integration issues along with trust issues when things do not fall in place.

Knowledge distribution across distributed locations

Having stories for a particular feature distributed across both locations ensures that not only people across locations touch/refactor each others code, but it also ensures awareness of features and areas in the business domain across the team.

Allows for team scaling across both locations

Having a cross functional team across both locations who work on the same product backlog provides flexibility to scale the team across regions depending on availability of skill. This model is also very useful in a client-supplier model where the client wants their developers to work with the supplier as well. A good mix of people across both locations ensures that the team can easily scale when needed.

Concerns

However the common backlog model comes with its share of concerns

Very high level of day to day communication across all roles

The basic premise of working with a common backlog is to ensure both locations of the team are always on the same page during their working day. This means a lot of communication via multiple channels such as video conference calls, emails, voice chats etc.

One key factor is the overlap time across both locations. If the overlap time is anything close to half a day then it is advisable that the team at a location has a continuos video stream of the remote team. With the right hardware investment, this can create a very powerful "one team atmosphere" for the overlap time.

If the overlap time is much less (1-2 hours) then a lot of communication has to flow through offline emails and chats. It becomes critical for the team on both sides to communicate the critical pieces of proceedings at a particular location so that the other location is on the same page.

Business and IT stakeholders not being distributed 

Even though the delivery team might be nicely distributed, there is always the common case of the business stakeholders sitting in only one location. This could also apply to the network infrastructure, IT security etc... Because of this, the delivery team in the same location as these stakeholders will end up having a lot more context (e.g. business domain context) and a lot more meetings to deal with than the remote/satellite team which is fairly isolated.

This could cause some uneven knowledge distribution over the long term and should be fixed with adequate rotations across roles within the delivery team.

Conclusion

It will be painful initially to communicate using a common backlog, but dealing with the pain more often (daily) puts the team in a much better place long term than each team going their own way.