Skip to Content

Agile Software Implementation Contracts

As an owner of a software company, I am both a deliverer and recipient  of Agile services.  I guess that makes me schizophrenic 🙂

My  personal confession is that I’ve enjoyed delivering the Agile message as  a service provider a lot more than I’ve enjoyed receiving it as a  customer.

As a provider, it suits me well to convince you that we need  to “explore together”.  That we should use iterations, collaborations  and demo reviews as tools to keep us on track.  That I’ll use continuous  integration to make sure we always have a running code base.  We’ll  both focus on delivering the maximum value with the smallest amount of  effort (aka cost and time).  You’ll only pay me for the time I spend  “exploring” with you. 

Nice.  Little risk on my part.  Guaranteed revenue stream.  You own the results.

As a customer, I want your skin in the game.  I hate hearing  the word “exploration” and the open-endedness of the exercise doesn’t do  me any good when I have to minimize my costs on one end and satisfy my  customers on the other.  I need reliable projections, dedicated  resources and commitment of heart and soul to go beyond just “what I  tell you to do”.  Besides, deep down inside I’m not really sure of what I  want…I need your subject matter expertise and experience…not just  your code slinging abilities, or Agile process mastery.

My solution is that every project I do with my clients is now fixed  price and fixed time.  I guess that only leaves scope as the manageable  variable, which is really a much more comfortable topic to negotiate  than money and deadlines.  I’m trying to get all of my vendors and  subcontractors to do the same with the projects that I solicit.

Fixed price fixed time (FPFT) projects create the perfect dynamic  for me.  Both of us need to really get started with the end in mind and  keep projects as short as possible.  How will we declare victory and  what do we need to do to get it done within 90 days?  Not a lot of front  loaded training required for that one.

I then introduce my methodology which is basically “we’re going to  threaten to put your system into production” every X weeks (where X  usually equals 2) and you need to assemble a customer team that tells us  “why they can’t use it”.  We’ll take those “cant’s”, review and  prioritize them, and include as many of them as we can, as long as we  don’t slip our date.  It’s fixed price so you don’t have to worry about  scope creep.  We’ll tell you what the tradeoffs need to be. 

That’s it.  No other discussions about “real Agile”, “cowboy Agile”, blah blah blah.

How  do we fare?  With respect to profitability, sometimes we win and  sometimes we lose.  With respect to client satisfaction, we never lose.   What that means is that in the long term (we’ve been doing this for  three years now) we always win because our client’s always get what they  want and are very conscious of the role they’ve played in making that  happen…or not.

Bottom line.  I don’t think we need to train customers how to  participate in an Agile project.  For them, it’s natural.  Who wouldn’t  want to evaluate a production ready system every two weeks?  We need to  train ourselves to spend less energy teaching our customers all of the  things we’ve learned about the Agile process and just “do it”!

Sam

Be the first to leave a comment
You must be Logged on to comment or reply to a post.