Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 535 posts at DZone. You can read more from them at their website. View Full User Profile

Distributed Agile: Communicating Big Design Decisions

11.11.2010
| 3796 views |
  • submit to reddit

Although we mostly split the work on my project so that there aren't too many dependencies between the teams in Chicago and Pune, there have still been some times when we've designed major parts of the code base in Pune and have needed to communicate that to our Chicago colleagues.

I've never seen this situation so it's been interesting to see which approaches work in trying to do this effectively and allowing the people in the other location to have input as well.

Explanation on specific email threads

While it's useful to communicate the approach being taken by email we've found that it makes more sense to have a specific email thread for that conversation rather than tagging it onto something else.

It's surprisingly easy for emails to get lost amongst the hundreds of others that people receive each day but at least if the important messages are all under an email with a clear title then it's much easier to deal with.

While discussing this with Saager, he suggested that an effective approach he's used previously is to include details of design decisions taken in commit messages and then point people towards those particular commits.

Of course however skilful we may be in communicating via email it does help to talk on a conference call as well – that medium seems to work better for explaining the reasoning behind decisions, especially if there's a disagreement in the approach.

Commit early

As much as we can explain design decisions in emails or conference calls it's still not as useful for people as seeing the actual code which is something we didn't totally appreciate until recently.

We're now trying to ensure that we check in more incrementally when making big design changes.

This should help to tighten the feedback loop and ensure that we get the benefit of the design skills of people onshore as well as offshore.

Something which I initially considered as a disadvantage with checking in incrementally is that you will most likely get suggestions/criticism about what you've done even if you had already planned to address some of those areas anyway.

As a colleague correctly pointed out, the intention is generally good and it's not the end of the world if someone suggests something you could have done better anyway.

In summary

These types of things seem obvious looking back at them now but I guess it isn't so obvious to me because you never have to think about them at all when anyone interested in the code is sitting in the same room as you as it's been for me when working onshore.

I'd be interested to hear any other approaches that have worked well for others working in a distributed fashion.

From http://www.markhneedham.com/blog/2010/11/10/distributed-agile-communicating-big-design-decisions/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Emma Watson replied on Fri, 2012/03/30 - 5:01am

As horrible and sometimes draconian as it maybe homogenising working practices and developer environments across your team is crucial in ensuring distributed teams can quickly and effortlessly interact with each other regardless of geological and timezone separation.

JDBC

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.