Selling Agile to Your Team and Upwards

I’m often asked by passionate agile champions how to help sell agile within their company.  Selling Agile is all about change management.  As with any change management you need to look to the mindset of the people that you wish to influence and find out what barriers exist and what prizes can be had for those that endorse the change.  Each person on the team or from a management position is coming from their unique perspective.  Typically, we see patterns of behavior that enable grouping of these perspectives. 

• Converts
• Cowboys
• Curmudgeons
• Control Freaks

I’ll start with the easiest group:

Converts

They have already drunk the kool-aid.  They recognize that what has been going on in the past has not been working all that well and welcome the change.  There is no need to continue to try to convince this group.  Instead do what is necessary to keep them from getting frustrated and focus on harnessing their passion and leverage it into convincing others. This group is your ally.  Keep up their passion and leverage it, but don’t spend too much time preaching to the choir.

Cowboys

This group doesn’t need no stink’n process.  They have the mindset that if management and process would just get out of their way then they would be able to work wonders.  Sometimes there’s some truth to what they say.  More often than not, however, the result of cowboys let loose is a chaotic train wreck. 

How to approach this group depends on where your organization is coming from.  If your starting point is perceived by the cowboys to be a stodgy bureaucratic process, then most likely the cowboys can be won over relatively easily by convincing them that agile development is a far lighter weight process and is designed to allow them to flourish.  The danger here is that it is too easy for a cowboy to look into agile only to conclude with “yippee yi yay—I told you that all this documentation was crap.”  So, while it may be possible to get them to convert, the effort needs to be on maintaining their discipline and keeping their focus on value delivery.  The key here is the focus on “potentially shippable product.”  If a cowboy mindset can become “test infected,” then you have an incredibly powerful agile developer. 

Now if your cowboys have been allowed to live like free range chickens, then your problem is quite different.  The challenge is that the cowboys like having free reign, and will often see any process, even an agile process, as an unnecessary constraint and bureaucracy.  If this is your environment and you want to win over the cowboys, keep things light and look for areas where everyone agrees some improvement could be made.  Usually there is something from the agile toolkit that provides a good solution for that area, so emphasize that aspect and gain success to begin to win over some converts.  A common issue with a cowboy dominated culture is quality.  If that is the case for you, then look to introduce practices such as test driven development or just work on truly getting to “done” so that you have a potentially shippable product at each iteration.

Curmudgeons

This group just doesn’t like change.  The old way may not have been optimal when they started using it, but they’ve been doing it long enough now that they think they know how to do it and every time they tried something it has failed (often because enough of them have sabotaged it to make it fail).  This group is dangerous if they really are willing to sabotage the effort.  They can be very difficult to win over.  They see a big prize in keeping things the status quo, and/or are threatened by any change.  The first thing to do is to find out what is the prize that they are holding onto and what are their fears.  If your curmudgeons are intractable with their position, you may need to look to move them off the team or to sideline them so that they are not causing problems for the team.  Ultimately many of them will convert, but they will typically be the last to convert.

Control Freaks

This is the group that typically has the biggest mindset misalignment with agile development.  Unfortunately, the corporate world is often driven by this mindset and as such many senior leaders get promoted based on the perception that they are able to bring control to chaotic environments.  Software development has inherent uncertainty, much more uncertainty than even those within the industry care to acknowledge.  Control freaks don’t like uncertainty.  Uncertainty is a problem.  They don’t like problems, they want solutions.  Detailed plans give them the illusion of control.  Ignoring the uncertainty is a convenient way for it to go away.  Their mindset is that prior projects have been unsuccessful because they did not do enough up front planning.  If only we had spent more time up front we would have learned everything.  It makes a lot of sense, especially in a linear world of thinking.  The problem is that it just doesn’t work.  There are some things which are just fundamentally unknowable until the solution is further evolved.  Frederick Brooks called this the werewolf in his famous essay “No Silver Bullets.”   The irony in the situation is that agile development actually provides more control of the software project than one gets with a detailed upfront plan.  The difficulty is convincing the control freak of that fact. 

Often control freaks can be convinced to try things out, especially now that agile development is getting more mainstream.  After all, there are a lot of things about agile they are likely to endorse.  Agile development focuses on value and how to deliver value effectively.  They will typically like the concept of user stories and planning associated with task breakdown.  They will also get behind the focus on quality and the drive towards a potentially shippable product.  It may be possible to convince some control freaks that agile development is actually more disciplined than where they have been. 

Some common problems with control freaks that start the transition to agile is their tendency to over-plan and their unwillingness to allow the team to self organize.  One common over-planning behavior is the desire to take the entire backlog and allocate it out to iterations all at the beginning of the project.  This is can range from being a potentially harmless waste of effort to being quite dangerous if it also sets expectations that such a detailed plan will actually be followed.  Control freaks must get satisfied that they are doing enough detailed planning.  Try to keep them focused within the iteration and help them avoid their tendency to want to plan everything in detail.  Get to the heart of what they are trying to control.  Probably they feel they need a detailed plan so that they can give predictable answers when questioned.  Help them learn that questions are best answered when there is sufficient knowledge to answer them, and that agile development will surface that knowledge.

Perhaps the biggest problem with control freaks is that they can often get in the way of allowing the team to self organize.  If the control freak is in a management position this can be particularly challenging.  If you are in a position of leadership yourself, then you can sometimes minimize this issue by shielding the team from the control freak.  It puts extra burden on you, but makes the team far more effective.  If the control freak is inside the team then the team needs to work together to help them get over their concerns.  If the team cannot band together to deal with this then it is unlikely that they are going to get much traction on the issue.

Further Reading

For further reading, I recommend a book “Fearless Change: Patterns for Introducing New Ideas” by Mary Lynn Manns and Linda Rising