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
