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?
Community comments
People mean different things by "hero"
by Jim Leonardo,
Re: People mean different things by "hero"
by Amr Elssamadisy,
Not agile
by Mattijas Larsson,
Seems like a misunderstanding ...
by thomas granier,
Any project benefits from stars...
by Ian Williams,
People mean different things by "hero"
by Jim Leonardo,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think there's differences in what people are talking about, hence the debate.
A star is that person that seems to be able to do anything, do it faster, do it with fewer bugs and generally leaves you scratching your head as to how they managed to get xxx done and still manage to take time to help others. Any team can benefit from a star, as long as they aren't a jerk. When the star is a jerk they turn into...
A self-martyr (I'll just use martyr from here) is someone who puts in the big hours, is always trying to "make up for the others", seems to have their hand in everything, and somehow you always get reminded of "how much they do", and always has an excuse ready They often run roughshod over the rest of the team because they are so important, know much more, so much better etc.
Everyone sees the star's code, but the martyr's code is often a mystery only the hero can understand. You don't want to get rid of the star because you know that you're getting 10x what the star is worth. You don't want to get rid of the martyr because you're afraid of all that mysterious code.
The easy way to differentiate the two is that the star usually works close to normal hours and gets more done. The martyr works significant overtime, often on weekends, to get that more done. The martyr can poison the rest of the team if not watched closely.
Not agile
by Mattijas Larsson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I disagree; agile teams are in general better at dealing with complexity as they a self-organizing around the problems.
Here is the smell! Who are "we"? Why are you telling the team to use cutting-edge technology? This "we"-entity is telling the team what to do and how to do it using which technology.
Luckily you had a brilliant guy who could figure it out for you. Next time put a good team together, let the product owner explain what he needs and let the team figure out how to do it. You'll be surprised how people will rise to the occasion when there is no "silver-bullet boy" around to take control.
Seems like a misunderstanding ...
by thomas granier,
Your message is awaiting moderation. Thank you for participating in the discussion.
Would it not make more sense to say: if you don't have experienced architects, then don't do complex development with new technologies ?
Agile doesn't do without technical leadership, as long as the tech lead is here to empower the rest of the team.
Also my experience is different about heroes: Agile collaboration and discipline tends to replace the lone hero dragging along the team with the senior people helping everyone else to raise the bar and take on more responsibilities.
Re: People mean different things by "hero"
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Ok. Point well-taken. So does an Agile team require a star or a hero? And, does an Agile team benefit from a star or a hero, or possibly, are they both detrimental?
Any project benefits from stars...
by Ian Williams,
Your message is awaiting moderation. Thank you for participating in the discussion.
Fundamentally if you've got a big technical challenge then regardless of methodology you will need very talented people to deliver. Technically complex projects are more likely to fail than technically simple ones. Full stop, end of story. If you've got a few really really good people you'll deliver more, faster and better than a larger number of less talented indiviudals.
I'd contend that the failure rate on technically challenging agile projects is lower than on traditionally organised projects, and when the do fail they do so at lower cost.
If anything agile projects are less demanding of single heros to deliver technically challenging projects because they are better are increasing the skills of the team members to deliver the project. In particular:
In contrast traditional techniques can lead to premature fossilization of design and knowledge silos where the shared understanding of the solution is lower.
Any team with a star programmer delivers better than the same team without...