This past Monday, OSC had a company hackathon day. It is not our first, but we have been trying to make this sort of activity a more regular thing for us. Unlike our previous hackathons, this one was more flexible on the rules. Previously we had the entire team work on the same technology or goal whereas this time was more free form. We each had the opportunity to work on either a new or old technology (by new and old I mean something we’ve worked with before or not), on new or old projects and to collaborate or work individually.

The day featured work on things like Google App Engine and the Android application platform. I took this chance to get myself out of the PHP world I’ve been stuck in for about a year now and get back into some Rails development. I had a little tool in mind that I wanted to develop which would help us internally do some things a bit more efficiently. I used that as an excuse to try out some of the Rails plugins or gems that I have wanted to use for a while, which are:

• Mocha (http://github.com/mislav/rspec-rails-mocha http://mocha.rubyforge.org/)
• Factory Girl (http://github.com/thoughtbot/factory_girl)
• GChart (http://github.com/jbarnette/gchart)
• Open Flash Chart (http://github.com/pullmonkey/open_flash_chart)

I have to say, the buzz around Mocha and Factory Girl is very old and I wish I had the opportunity to use these tools before now. New things come out everyday and it is tough to keep up with everything. My advise to you is to dedicate a “playing time” often for you to try out the newest and greatest thing that comes out. Do this in groups where each one can be working on a different things and share your findings at the end of the day. Even though I didn’t work on the Android app, I did get a feel for it from Arin through his experience with it. One of the things that helped take this experience further is our presence all together in one conference room feeding out of each other.

Looking forward to the next OSC hackathon.

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, “A 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 beforehands 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.

You can see the survey yourself here, and add your own feedback to it:
http://www.tinyurl.com/SellingAgileSurvey/

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!

I’m very pleased to be speaking to Richmond SPIN (Software Process Improvement Network) next Wednesday October 14th, at 6:00 pm at Anthem BCBS in Richmond.  The address is 2015 Staples Mill Road in Richmond.  You can find more details and register online at:

http://www.richmondspin.org/home22222

Here’s the brief on my talk, which is based on my recent talk at Agile 2009.  I hope to see you there!

“Strategies for Persuasion on Adopting Agile”
By Arin Sime, Senior Consultant with OpenSource Connections

Do you want to know why Agile is sometimes a preferred methodology over a Waterfall method?  Arin will present 12 different methods for convincing a “traditional client” to use an Agile project plan. Based upon his own experiences with a wide variety of project styles, he will also present several definitions of each of the environments, well as results gathered from a survey on how to sell Agile. Some stories and best practices from other sources will also be covered.

Arin Sime’s presentation last week at Agile 2009 on how to sell a traditional client on an agile plan made a good impression, apparently.  First, his presentation was featured on the front page of SlideShare.

Now, he’s received an excellent writeup from Adam Goucher (we were pointed to Adam’s writeup from here).  Many thanks to Adam for the kind words about Arin’s writeup!

Arin’s next speaking engagement is at the University of Virginia’s EdUI conference on September 22, covering the Facebook API.  He’d love to see you there!

Scott Ambler wrote a very interesting article for Dr Dobbs Journal recently entitled “RFPs the Agile Way — or — Fear and Loathing in the Procurement Department.”  I first came across the article when Deborah Hartman Preuss wrote an excellent commentary on InfoQ about Scott’s article, entitled “Using the RFP Process to Hire Agile”.

As Ambler points out, the use of a formal RFP often implies that the client uses a traditional development method like Waterfall.  Procurement writes an RFP, and then the consultant responds with a detailed proposal dictating timelines and cost estimates, and perhaps an up front design.  All before ever meeting with the client.

The RFP process is a necessary evil of the consulting world, particularly in government contracting.  But RFPs don’t lend themselves well to the very collaborative discussions you can have with a client when you are using an Agile process, or if you are securing the contract in person rather than electronically.

This topic relates somewhat to my upcoming presentation at Agile 2009, “How to sell a traditional client on an Agile project plan.”  Although a lot of the advice I give in that talk can be done in proposals, most of it works better in person.  And so I think that’s a real challenge to accurately respond (in an Agile way) to an RFP that assumes a waterfall development model.

At first I didn’t quite find the answers I was looking for in Ambler’s article.  I don’t say that as a knock against the article at all, because it is well worth the read and I think it frames very well the problems with RFP processes.  However, Ambler is mainly encouraging procurement people to change the way they structure RFP’s so that Agile people can respond to it better.

I’m not sure the procurement people are going to read his column or see the incentive to do so (which he acknowledges, and asks readers to send this article to procurement people they know).  And so while I believe my Agile 2009 talk offers some strategies for how to positively discuss Agile in a proposal, I’m still in search of the holy grail.  How exactly do you respond to an RFP “the Agile Way”?

But after reading Ambler’s article again, perhaps he does lay out some of the answers I’m looking for.  He just does it from the opposite perspective.  He suggests this advice for what procurement people should look for in an Agile response to an RFP:

(rather than lift all his text, I’ve just included the highlights below.  I suggest you read his article for the full explanation)

The supplier should provide resumes

Follow a reasonable set of rights and responsibilities for both the customer and the supplier to adhere to … how they will collaborate together.

Propose how they will work with the customer.

Produce potentially shippable software to the customer every X weeks.

Allow the customer to monitor their work and work products.

Follow the customer’s corporate development guidelines.

Do full regression testing throughout the lifecycle.

Provide a minimal set of deliverable documentation, particularly user documentation, operations documentation, support documentation, and high-level systems overview documentation. The customer should provide examples of such documentation if they’re available.

Shared-risk strategy [for payment] which is fair to both customer and supplier.

Indicate rough estimates and schedules, in the +/- 30% range.

That’s a great list of ideas for consultants to incorporate into proposals, even if the customer is not looking for them.  I’m glad to see that we already do many of them in our standard proposal template at OpenSource Connections.  In particular, we always talk about our “Open Approach” to projects, ie, the highly collaborative and open way that we work with our customers using Scrum.

This is all a sign of the increasing maturity and adoption of Agile processes, and if nothing else, that’s a good thing.  Perhaps the procurement people will sign on eventually after all.

Last Thursday I had a great opportunity to speak at AgileCville, and give a dry run of my upcoming presentation at Agile 2009.

Eric took this photo of me speaking.  It looks like I’m doing The Robot.  I’m not, but that would have been cool.

I’d like to thank all those who attended. I really enjoyed the chance to share my thoughts on “How to sell a traditional client on an Agile project plan.” I got a lot of great feedback from everybody. I’m flattered how much of it was positive, and I also got a lot of very helpful constructive feedback that I will definitely incorporate as I polish my slides for Agile 2009. Most notably perhaps, I’m going to take a crack at improving the quality and consistency of the graphics in the slides.

The slides are available online here. I also brought my voice recorder with me, and I’ve posted very roughly edited audio from the meeting here. The presentation was about 35 minutes long, and then we had a very interesting and valuable discussion session for about an hour after that. If you try to listen to the audio, be forewarned that not everyone’s voice comes through clear in the second half when we’re having our discussion.

I’m really looking forward to seeing everyone at Agile 2009!

I’ll be speaking to this Thursday’s #agilecville group meeting, about “How to sell a traditional client on an Agile project plan.” I have 11 strategies that I will go over for how to convince your clients that Agile methodologies are the way to go, and I think they cover a variety of different styles so there should be something for everyone.

When: Thursday July 16th, 6:00 PM

Where: Jefferson Room, 3rd Floor, Charlottesville Central Library (http://www.jmrl.org/li-meeting.htm)

More info and signups are on the AgileCville Google groups page.

This is all part of my lead up to speaking at Agile2009, and I’m really looking forward to tapping into the experiences and brilliance of my fellow Agile practitioners here in Charlottesville.  If you haven’t already, please take a moment to fill out my survey on how to sell Agile.  I’ll use the information I gather from this informal survey as part of my presentation.

I hope to see you there!  OpenSource Connections will provide pizza and soda!

Well … famous in one room of a conference at least.

I just posted a google form survey looking for feedback on how people are “selling” the use of Agile in their companies and with their clients. You can see the survey and fill it out here:

http://tinyurl.com/SellingAgileSurvey/

I will be using the data and stories I gather from this survey in a presentation I am giving at the Agile 2009 conference in August entitled “How to sell a traditional client on an Agile project plan.” By default, all quotes I use from the survey will be used anonymously unless you specifically want me to make you famous.  So feel free to tell me what you really think.  :^)

You don’t have to be a developer or consultant to participate in this survey!  If you are a project manager and someone has tried to convince you to use Agile methods, there are questions for you here too.  In fact, if they were unsuccessful at convincing you to use Agile, you probably have a story even more valuable to me.

If you have the chance to answer this survey before Wednesday July 15th that would be wonderful since I’m doing a dry run of my presentation on the 16th to AgileCville.  But in reality, if you can answer anytime between now and the end of the month that would be awesome.  You are also more than welcome to forward this on to others you think may be interested.

http://tinyurl.com/SellingAgileSurvey/

I’ll post some of the results on this blog later in August (respondents names and other identifying information will be removed from any results that are posted).

Thank you!