Monday, June 28, 2010

Agile: Average Developers Need Not Apply?

This post continues on the theme I started in the "Agile - An Elite Game Only?" post.  This installment discusses the notion (or myth, in my opinion) that agile methods are meant only for the elite or superstars of software development and that the gains promised by Agile are not attainable by the merely average.

Agile teams are expected to learn and experiment and teach and grow.  All the time.  The argument goes that developers of average skill just can't keep up with that and therefore agile is not for them.  Further goes the argument that Agile should only be applied to small teams of superstars and more structured processes should be used to keep the developers of average skill "on track" (or, less kindly, "in line").  I've also had some developers express to me concern about "fading into the background" of a team if they are not allowed to continue as single contributors (although it's almost never a superstar who expresses this concern to me). 

Over the past 8 months I've been working with a small team of 6 software developers.  I don't think there is a single person on the team who would describe themselves as a superstar.  Rather each of them are "just" solid performers who want to do a good job and make a living.  I'm also working with a team 4 of business analysts who possess varying depths of knowledge in the various products that are needed.  This team of developers and BAs has done some amazing work over the past 8 months while transitioning to agile methods.  By just applying the following core principles they have enjoyed higher productivity and, from the feedback I get, much higher job satisfaction all while working on much the same software they had been working on 8 months prior. 
  • Direct and active developer contribution to planning including requirements breakdown, estimation, risk identification
  • Competent business analysts who value the skills and knowledge of the development team
  • Daily and continuous collaboration between and among developers and business analysts
  • A development manager who trusts the team and inspires a culture of learning
  • Automated unit tests (although this has only been added in the past 4 months)
This team is readying themselves to move to the "next level" by adding in better automated builds, better source control, and better automated testing.  They have developed an energy for learning and a spirit of collaboration that has elevated everyone's game.  In other words, their attitude is influencing their behaviour which are both having a major positive impact on their aptitude.  Superstars?  We'll call one if we need one.

So What About Those Superstars?

Still, there's no question in my mind that superstars are fantastic assets.  They develop at 10x (or more!) the speed of other developers, produce top quality, and generate new ideas all the time.  They live and breathe their profession.  They are also, unfortunately, rather rare.  I've worked with maybe a half dozen directly (i.e. in my organization) and maybe a dozen indirectly (in partner organizations) over my entire career. 

Whenever anyone suggests that we keep the superstars separated from the rest of the team so that they can "do their thing" I just shake my head.  Why would any company want to keep all that goodness locked up away from everyone else?  My experience has been that superstars bring up the game of the team they are on.  They become teachers, role-models, inspirational leaders.  The effect is multiplicative!  Good developers become great developers when they are on teams that have a superstar.  Only once have I found a superstar (in the productivity sense) that truly needed to remain an island.  All other cases have resulted in higher performing teams without eroding the output or visibility or "aura" of the superstar.

In summary, teams, whether they have a coding wunderkind on the team or not, have always benefited from agile methods in my experience.  What's important is that the team developers their own passion for quality and growth.  Leaders can influence and inspire this attitude but it cannot be mandated.  So choose your leaders carefully!

Coming Up - The Evils of Management


Kimota94 aka Matt aka AgileMan said...

Another great post, showing just how much insight you've gained into this topic through your various experiences of the past 5 or 6 years.

Like you, I've seen many teams raise the games of individuals through the implicit peer pressure / infectious enthusiasm that often permeates a team once they truly feel empowered to do the best job they can. It's the sort of thing that you can't (unfortunately) make happen; all you can do is set up the right environment and then encourage it through your values and actions.

Anyone down on Agile may, in fact, have experienced it in a situation where leadership "talked the talk", in that sense, while failing to "walk the walk."

cjg said...

I think your comments on "superstars" is great - and you should extend the terminology to its sports origins. If I have a sports team, a true "superstar" will elevate the entire team, starting with the players on the same field at the same time. In sports like soccer or hockey, the superstar inevitably provides opportunities for their linemates by setting up the linemates directly or by drawing defender opposition to themselves, giving the linemates a chance to shine.

Plus, it is well understood in sports that if you are the best on your team, you can't get better - it is difficult to rise above a certain plateau because you can always defeat your opposition. That is why the best players are pulled into leagues composed of "the best" from all around. Now the relative skill level has gone up, so you may not be the best anymore. But you will see and learn new things from those around you and achieve that "next level". Surely this principal extends to the "superstar developer" as well.