Note: This blog post was originally written when I was a consultant for OpenSource Connections.
Why do we need to sell Agile?
For those of us who know and love Agile, the benefits of Agile seem obvious. It can be frustrating when someone doesn’t inherently see those benefits, and we sometimes forget that we need to sell our clients or our managers on our process.
For some perspective on the gut reaction many people have to Agile, consider the following quote. John Zachman penned a famous paper on software architecture design in the 1980’s, where he said:
Some kind of structure (or architecture) is imperative because decentralization without structure is chaos. – J.A. Zachman, 1987, framework for information systems architecture
As practitioners of Agile, we need to remember that someone’s first reaction may be that we are engaging in chaos, and so we need to consider beforehand the needs of our client or manager and how we can convince them to follow a better process.
In this post, I will briefly present 12 techniques for selling a traditional client on an Agile project plan. This post is based on a talk I gave at Agile 2009 and to a number of other user groups, and which you can see on Slideshare here.
As part of preparing this presentation, I created a survey of fellow grad students in UVa’s MSMIT program and other colleagues in the field. I asked them how they have sold Agile or been sold on Agile. Not everyone who answered the survey was a fan of agile and many of their quotes are interesting.
Those who answered the survey are all experienced IT veterans who have worked for a wide range of organizations, including Booz Allen Hamilton, SAIC, Capitol One, the International Monetary Fund, Fannie Mae, Freddie Mac, and more.
First, a couple of general comments from the survey that I found interesting:
Agile seems to carry the connotation of ‘codelike-hell’ or just, ‘work faster’.»
I am skeptical of any methods that that could be interpreted as cutting corners
These are common first impressions of Agile, and I hope the following 12 techniques will give you ideas how to convince your clients or managers that Agile is the way to go and their first impressions are not accurate. These techniques are based on a survey of current literature, my own consulting experiences at OpenSource Connections, and the feedback I received from the survey mentioned above.
1. Trial by Sprint
You need to show a success to get adoption.
Consider giving your boss an option. Ask them to give you a sprint or two to try Agile out, and if they don’t like it, then you will go back to the old ways of doing things. Make sure that you pick tasks for those trial sprints which can be successfully accomplished, and will show your boss the value of the incremental delivery of Agile. You should also encourage your boss to play a role in the daily standups and see how communication in your team improves.
2. Case Studies in Success
Do some research on similar companies to yours, and what methodologies they are using. By googling around online, you should be able to find some case studies on Agile success and present those to your boss.
3. Client Testimonials
For consultants, make sure you go back to your clients after a project and interview them. Ask them how your process worked, and gather some quotes you can use in future proposals or client discussions. I did this for one of our recent projects, and the customer gave us some great feedback like:
«Certainly one of the most successful projects ever here … Scrum eliminated my biases of what developers could do by letting them self-select.»
4. Find a Champion
One approach is to let others do the selling for you. This is particularly useful for consultants who already have a relationship with a client, and you can let some of the clients’ employees talk about how they want you to use Scrum. Or, as one of my classmates did, he became the internal champion for Agile:
I highlighted the benefits to the Project Manager: higher productivity and less team management stuff since the team will take care of lots of team-management and updating (burn charts) instead of PM’s managing those details.
Basically, identify a stakeholder in the project who is most in need of the benefits of Agile, and enlist their support to help you sell management on the use of Agile.
5. Use Metrics of Success
Many traditional clients like their current methods because they provide metrics that they can graph and look at. They don’t always immediately understand how they can measure a project using methodology without a lot of documents.
But Agile has its own metrics too, and perhaps you can use those to sway the client. Consider presenting them with information on velocity, story points completed vs waiting, test coverage, unit test success, etc. Some Agile tools will provide these in pretty reports, but you can also fashion them yourself. And don’t forget to show them the benefits of the burndown chart if you’re using Scrum, and emphasize how this gives them a real time view into the health of a sprint without encumbering the developers with lots of reporting.
6. Show how Agile combats common IT failures
One of my professors, Ryan Nelson, has been running a study of project retrospectives over the last 10 years, and has published articles in MIS Quarterly Executive detailing the Top Classic Mistakes in IT projects. The top 3 are consistently: Poor estimation and scheduling, Ineffective Stakeholder Management, and Insufficient Risk Management. Agile can be used to address all those classic mistakes.
Consider why projects normally fail in your organization, and present the ways that Agile combats those common failures.
7. Examples of government/industry leaders using Agile
As one of my classmates pointed out:
Clients, especially the military, are wary of catch phrases and sometimes unwilling to change their habits.
If your client or boss fits that description, then you need to convince them they are not the first to try Agile, and that it has been used elsewhere successfully. Try to find examples of their peers in industry or government using Agile, and point to them as an example.
One example you can use is my previous blog post about the CIA using Agile and Scrum.
8. Comparison to other methodologies
Compare how Agile/Scrum work compared to areas that your client or boss is already familiar with. Try to point out both the similarities and the differences. For example, one of my classmates took the following approach:
I gave an overview of the Scrum process and highlighted the ease of transition since iterative/incremental development has been in practice for a long time (in other forms such as a spiral approach)
9. Listen to their needs and address them.
I am always skeptical of anything that promises it is the ‘only’ or the ‘best’ [methodology]. – Comment from a development manager
Instead of going into the meeting and kicking off the discussion with your rant on why Agile is the best development methodology, take time to listen to your client or manager first.
Ask them how their projects have been going, what challenges they face, and take notes on their common problems. Then suggest how Agile will address some of these issues.
The key here is to spend most of your time listening, and only then talk up the benefits of Agile. This will assure your audience that you have heard their concerns, and that you are trying to present positive solutions to their problems. This can be much more effective than trying to force a methodology on them.
10. Sneak it in
This is a very common approach, and one that I have done before too. One of my classmates is a technology program manager, and they commented that:
I make sure I utilize agile practices where ever I can – I just don’t use the agile terminology.
The point here is not to be deceptive, it’s just that sometimes you don’t need the sign off from the boss to do something. After you successfully conclude your project, you can then point out to your boss that «by the way, all that stuff we did that really impressed you – that was Agile.» Now that they have a positive impression and have witnessed some success, you can work on letting them formally adopt the process.
Note that doing this might require you to temporarily also fill out the same reports or status updates your current process requires, but hopefully you can get those dropped after having showed the benefits of Agile.
11. Compromise
An agile purist may not like the idea of compromising, but I found the following sentiment to be pretty common:
The methodology that has worked in my experience has been to incrementally introduce Agile … Start using a limited set of the practices and gradually start bringing in more.
Similar to the «Sneak it in» approach, this can be done with or without your boss’s knowledge.
12. Agile Project Management Office
One other thought to consider is setting up an Agile Project Management Office, or PMO. A traditional PMO is a very document and regulation intense group, but some Agile practitioners have started to promote the idea of a lighter weight PMO. An Agile PMO focuses less on micro managing teams, and more on providing an interface to traditional processes. The Agile PMO can help Agile development teams by taking ownership of any burdensome compliance requirements which go against Agile processes. This allows the developers to concentrate on developing code how they want, and not filling out checklists of documents.
They can also serve as an educator and coach to the client.
Conclusion
There are many variants on the above ideas, but I hope this quick list has given you some direction on different strategies you can use for convincing people to adopt Agile. Keep in mind that each of these strategies has pros and cons, and you should consider the needs of your situation before adopting any particular strategy.
If you have other suggestions, please leave a comment and I look forward to hearing your feedback!
Recent Comments