Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Amr Elssamadisy on Apr 16, 2009
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:
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?
Agile Development: A Manager's Roadmap for Success
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
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.
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.
I disagree; agile teams are in general better at dealing with complexity as they a self-organizing around the problems.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.
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.
In these situations, if you don't have experienced architects, then don't use Agile!
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.
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?
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...
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
5 comments
Watch Thread Reply