In our last posting we explained what Agile data warehouse development is.  In this posting we consider a new idea: distributed Agile development.   

Why “Distributed Agile”?

For day-rate reasons, some organisations have adopted a  top-down policy of using off-shore development resource wherever possible.  That  tends to result in Waterfall being adopted because formal documentation is  used to allow remote people to carry out work unambiguously.  Off-shore work in this arrangement is developed by people who have had no contact with business users and are therefore wholly reliant on the written specification as a set of instructions to build against.  The work coming back on-shore then has to be very thoroughly checked in unit testing because those performing the build have no context in which to make decisions.

The trouble is that producing all this formal documentation is very laborious and can still be  ambiguous, and the end result can be that the expected cost savings due to lower off-shore day rates are offset by the additional work to document the requirements, to unit test the results very thoroughly and to address the relatively high level of defects caused by lack of understanding.

So the question arises: is it possible to benefit from the lower effort and higher business satisfaction of an Agile approach while benefiting  from the lower day rates of having some of the team members working remotely, in low-cost countries?

That was the challenge set to us recently by an  important client.  We never like to turn down a challenge, so we came up with  the notion of “Distributed Agile”.  The aims are highlighted with red ellipses on the diagram.  So far we have very little experience of whether this works in practice and we’d be very glad to hear from you if you have tried this.  Please feel free to leave your comments.