In The GDM-Agile Paradox: Tips to Tap into the of Agile in the Global Delivery Model Ajay Bhandari and Kumarasivan Veeramuthumoni report on their teams' experiences with Agile development in an offshore model. They cite several factors for their success, one of them being:
The second factor in our favor was talent. We had what we termed the "silver bullet", a do-anything programmer who has unlimited design capabilities. Obviously not every team is lucky enough to have a star programmer, but there are ways to make sure your talent matches the requirements of the project.
They go into detail of why this technical hero was absolutely necessary for their success, and give us advice not to go ahead with Agile in an offshore model if we don't have this level of expertise:
As a general rule-of-thumb, the more engineering content a project presents the more challenging it will be to use Agile Development. Why? More engineering content means more complexity. Take our project, for example. A number of features we planned on incorporating in the website required the use of cutting-edge technologies which, for the most part, our team had little experience working with. Luckily for us, our "silver bullet" was able to quickly develop an understanding of the new technology, experiment with code, and develop an ideal process which the rest of the team could emulate. Sans his abilities our team would have been over its head, unable to make the quick decisions that Agile Development encourages. We have witnessed the death of many projects because of an overabundance of engineering content. In these situations, if you don't have experienced architects, then don't use Agile!
This advice is hard-won by the authors and is based on their own experience. But it does not mesh with main-stream Agile advice:
- In Book Review: The Responsibility Virus Helps Fear Undermine Collaboration heros are considered to be an extreme state that cause burn-out and are unsustainable.
- In Noted Professor Decries "Macro Management" heroic leadership is seen as a pervasive problem in business.
- In Kent Beck: Be Yourself - Create More Value
Beck explored getting off what he called the "genius-shithead rollercoaster," a pattern that requires us to either be heroes at work... or shmucks, because we can't be heroes. His advice: just be yourself at work.
So is distributed Agile development different? Is the hero a pattern to follow or a smell to avoid?