program selection system

With more teams becoming globally distributed it is increasingly important to understand how to develop effectively in such an environment. Such globally dispersed teams face many challenges. Agile methodologies can help overcome those challenges and improve productivity in dispersed teams. This presentation, based on real experience, offers insights on how it can do that. The core elements that an agile methodology should have in order to function well within a dispersed team will be outlined, interspersed with real examples and warnings as appropriate.

Background

Increasingly it is more common for teams to be globally distributed. That is, having each team member in a different location and, usually across multiple time-zones. Working in a distributed team offers many challenges to effective development; challenges that are often compounded in traditional waterfall or loosely iterative methodologies. The communication burden is almost overbearing as the team struggles to maintain tacit knowledge and a shared project vision while keeping in daily step with each other. Understanding progress and providing useful and timely visibility to stakeholders can be haphazard at best. Anyone who has worked in such a team will be acutely aware of many of the issues.

Lessons learned from real experience

I don’t intend to dwell too much on the challenges. What I will do is offer suggestions based on lessons hard learned in a 3 year project in such an environment. Faced with the need to develop a new business critical product, in as timely a manner as possible, the organisation allowed our team flexibility to move away from the company mandated waterfall approach. As a team we identified an agile methodology that we thought would help address our key problems and began our journey.

The warnings and advice offered in this presentation are based on that 3 year journey which departed from waterfall and moved to agile. We didn’t get it right the first time, in fact we continually evolved the methodology through our retrospectives to address our biggest pain points until after a year or so we had coalesced on what I would consider to be the needed core elements of an agile methodology that will work with a distributed team. There is still room for improvement of course, but the foundation is pretty stable. In addition to showing what worked, I’ll also comment on what didn’t work so well and why. I hope that these observations help provide that extra insight into why our methodology evolved as it did and why I recommend the approach I outline.

Throughout the presentation I’ll show real world examples of artifacts and tools that we used to help us implement our methodology and comment on their effectiveness. I’ll talk about how we tried to overcome the communication bottleneck that you experience in a distributed team and how it is important to adhere strictly to certain protocols in communication to ensure a level playing field. Again we could have done better in some areas and I’ll highlight those as warnings to look out for.

In Summary

In summary then the presentation will detail the core elements that we found an agile methodology should have in order to function well with a distributed team. This will be interspersed with real examples and warnings as appropriate.

The hope is that anyone involved in a distributed team, or hoping to do agile development in a distributed team, could take this information and use it to help define for themselves a good starting point for an agile methodology tailored for their situation. By heeding some of the lessons we learned I’d hope it would be possible to avoid making some of the mistakes that we made. Finally, and most importantly, I’d also hope that attendees would have confidence that agile development can not only work in a distributed team, but it can work very well, benefiting both team and organisation.