For much of my time working with agile software development I have been fortunate to work with highly motivated teams composed of individuals who have been educated in Agile processes and are anxious to try out the methodology.  (Of course, there are always those who think that ‘agile’ means ‘no process’ and are a bit disappointed to find out that the processes are very structured but of shorter duration.)  In any case, the transitional difficulties have largely been limited to breaking functionality into appropriately-sized user stories and dealing with external organizations unused to the new process.

I have, however, had the…um …  opportunity to work with a few teams whose members were truly not interested in Agile processes and who were largely unhappy with the change.  The vast majority of the unhappy team members have been people who were consistently heroes under some form of Waterfall development methodology.

I think the evolution of heroes is easier in I/T groups than in product development groups – the projects tend to be smaller and it’s easier to push out fixes after the fact.  Additionally, funding cuts often hit I/T groups mid-project and have to be accommodated so anyone who can deliver quickly is rewarded.  I know that there are heroes in product development as well, but any damage they leave in their wake can have a visible impact on the bottom line, or at least on customer opinion, so it’s a harder role to maintain.  So I’m now looking carefully at I/T development groups that I’m helping move to Agile to identify and work with the heroes.

In any case, Agile methodology does not lend itself to heroism – it’s virtually hero-proof.  For those of us championing a predictable process with an equally predictable outcome this is one of the big draws of the methodology.  It can, however, be hard on those who are used to being heroes.

Until I was on a project composed largely of these icons I didn’t really think about the kind of impact they can have (and the kind of impact on them Agile can have).  I’m now convinced that the heroes have to be considered in any project before moving to an Agile process.  This doesn’t mean that the move should be abandoned because there are heroes moving to it, just that they need to be recognized and accounted for.

People become heroes for a number of reasons.  One is the adrenaline rush of making that last fix just in time.  Another is the recognition, sometimes monetary but more often in the form of public accolades, that come with making that last critical save.  Another  less common but occasionally encountered contributor is the enjoyment of the lack of process restrictions while making heroic saves.  Finally, sometimes high performers are forced by poor processes into the role.  (Fortunately, those forced into the role usually welcome Agile with open arms.)  All but the love of process avoidence can be satisfied within the constraints of the Agile process with some management and project management forethought.  In cases where the heroes are not handled adequately you may find formerly star employees sabotaging (deliberately or unconsciously) your shiny new Agile process.

So, how to go about this?

First, identify the current heroes.   This is usually pretty easy – they’re the ones who have ‘gotten us through some rough times’ or ‘always save our bacon’. Ask  the current management, the customers if they’re available, the project manager, and the team.  Don’t ask about heroes, of course – just ask about anyone who regularly ‘fixes’ a release at the last minute, or who is the ‘go-to’ person when the date is slipping.

Once you know who the heroes are, understand what kind of reward they are given.  These are likely to be either monetary or public recognition.  They can take the form of bonuses, good reviews with the saves prominently mentioned, recognition emails, regular mentions to the customer, etc.

Next, talk to the heroes to understand whether they seem to be adrenaline junkies.  Do they talk about the thrill of chasing down that last bug?  Do they wax poetic about all-nighters to get the release out?  If so, you’ll need to provide that adrenaline rush in a different form.  It’s also important to note that adrenaline and rewards aren’t mutually exclusive.  If they’re not getting that thrill, ask about the current process and see if you get an answer that the process is a ‘waste of time’ (meaning they’re probably liking getting around it) or something more like ‘it isn’t sufficient, it doesn’t work’ (meaning they aren’t particularly happy with the way it’s working – or not – now).  Check with current management to see what kinds of reviews, bonuses, and recognition these heroes are getting.

Finally, talk to whomever has to work on the code (or specs, test plans or whatever work products the heroes produce) after the release.  If those folks are less than admiring of the work products, your heroes may also be avoiding process.

With the heroes and likely motivations identified, you now must architect a plan to provide what the heroes need in a different form.  These folks are valuable team members that you don’t want to alienate – the company and the agile team both need them.

If recognition is the main goal, work with management and project management to ensure the following:

1.        Every team member’s contributions are recognized at each iteration wrap-up meeting, either in the meeting or in the meeting minutes (depending on the size of the team).

2.       Every team member’s contributions are recognized publicly at the time of product release.

3.       Management has measurements in place to ensure that excellent work is recognized within the Agile framework at review time.  Ensure that these measurements are made public to the team so they know they will be rewarded.

4.       For those craving adrenaline, set interim goals per user story.  It may mean more tasks than the usual, but that means more deadlines and a constant adrenaline surge, especially for deadline performers.

5.       For particularly talented heroes, consider adding bonus user stories to an iteration – for that person only, and to be addressed only if the hero’s other iteration assignments are complete.

6.       Peer reviews are an integral part of the Agile process, but are a piece that sometimes gets lost in the shuffle.  Be sure to schedule the peer reviews as tasks so that anyone who prefers to bypass formal processes doesn’t have an easy avenue to do so.

Once these are worked into a process, check regularly on your heroes and be sure they’re on board with the new process.  Also, regularly examine the mechanisms put in place to ensure that they are both adequate and regularly followed.