Current Articles | Categories | Search | Syndication

 

How to Sell Agile Software Development

By Ryan Doom on Wednesday, October 08, 2008

How to Sell Agile Software Development
By Ryan Doom @ 9:32 AM
4336 Views :: 3 Comments :: :: General

I have found that Selling Agile Development is easier than I would have initially expected it to be.  The selling process is usually so complex.  In the more complex cases it starts with a Request for Proposal.  You will then wade through dozens of pages that may specify technologies, and how much load they are expecting, what type of hardware it will be on and usually only a single page of bullet points that is designed for you to try to grasp what it is they really want.  It will often have items for connecting to this system or that API and all these seeming small details that have high amounts of risk.  From this they want you to give them a number and sign your name agreeing to that amount.  Ack.  If it’s a project I’m interested in I will do it, but these are the sales I dread the most because you have to write so much, you really have to outline exactly what the system will do and also what it won’t do for that price.  Then if you do get the project you have to be extremely conscious of cost, features and your change orders.  Things the client and I hate.  Agile selling doesn’t work so well in these cases, I would have a hard time selling agile if I’m in a position where I cannot be in front of someone explaining it to them.

How my recent Agile pitch went.

I received a call from a Michigan company who found us on the internet and were looking for bids on their project. Normally I don’t get very excited about leads who start off saying they are getting bids, and shopping around but this project sounded interesting.  I try to be pretty straight forward and asked them what they had budget for this project, he told me, and I promptly scheduled a time to meet with some of their VPs. 

They had already talked to a couple companies by the time I had meet with them, and I know I was the only one who pitched Agile, they loved it.  There system was rather complex, they had a couple phases in their mind and they described them all and I could quickly see that they were outlining both mandatory features and the nice to have features.  After going through everything they said all the other companies were delivering their proposals on Tuesday next week.  It gave me three days, I looked at everything they had went over again and dreaded making that proposal.  No way was I going to be able to take everything we discussed and in a couple days outline a price and timeline to take it all on.

So, I began my Agile pitch.  I started off by explaining that we do software a bit different then other companies.  I discussed the Waterfall model, where everything was attempted to be outlined out front, and then they probably wouldn’t see the project until a month before it was due.  What happened then when they realize that there are many critical things missing that they couldn’t think of when they originally scoped the project.  Change orders, lots of cost and delayed project.

I then proceeded to discuss the Web Ascender team, each individual, their skills their experience and said  I could have one developer, a part time architect and part time designer on the project for X dollars an hour.  We would meet with their team at least weekly, and every two weeks deliver a working piece of software they could actually use and we would encourage their feedback.  Every two weeks we would reprioritize what is important for the next phase, they would always determine what they needed next in their application.  I couldn’t tell them exactly what their system would cost them, but if the loved what we had in eight 2 week sprints then we end it there, if they want the super whiz bang features then we continue on working a couple more months and wrap those up. 

They got it, they understood that we would be an extension of them.  They could see how they could essentially build their software by us just being an extension of them.  By working closely with their staff every week or multiple times a week their voice would be heard and the application would have a higher success and adoption rate in the office.

After talking to them about it, unfortunately I still had to write a proposal but it was only 8 pages rather than 35. 

The agile developers manifesto was one of those pages.

Rating
Comments
By Casino Hilfe @ Friday, March 12, 2010 10:10 PM
Thanks for the great article Seth. I found the information to be quite informative, very little fluff and very realistic. Please replace Max as soon as you can. :)

By Janice @ Monday, August 01, 2011 8:00 AM
How did you manage their expectations at the end of each two weeks? The problem I run into is that I may not get everything finished within the two week timeline. So the client is unhappy and begins asking why I spent 3 hours doing this or 4 hours doing that. Then they get scared of what the costs may be and ask for fixed pricing. I have also had a client hold payment until I got things to a level he was satisfied with. Sometimes it works great but most of the time, it seems there is a lot of nitpicking going on by the client.

By Enrico @ Monday, January 30, 2012 8:21 PM
Janice - not sure on all of the specifics in your situation, but our experience has shown that there are a couple of things that are challenging to get right - mostly because of the discipline required: being honest about the amount of work per iteration/sprint; and building only the minimum functionality necessary (an extreme example is hardcoding in cases) to complete the stories.

If you're not completing within an iteration/sprint you should be adjusting your point estimates - your velocity should typically waver over time.

If you find that after an honest assessment (always do retrospectives and evaluate/adjust) that you are building more than you need (extra layer of abstractions, configurations, etc.) to just fulfill the stories (and not build for the future), then this can be relatively easily corrected by simply assessing yourself closely for the next few sprints while you do your work. The discipline for this is mandatory - agile doesn't work well without it.

Now I would agree that keeping the customer happy is key - and I have found that if you don't have an excellent trust relationship with the customer, then all of the typical issues with any SDLC done offsite will surface. The client must be made to be a part of it - daily interaction is key through validating criteria, authoring/approving acceptance tests, etc. Once you begin that process there's actually very little to explain to the customer - but, yes, if we make mistakes they see that too :)

Click here to post a comment
Software development and sales blog