Customer relations in agile development

Question

My management just asked an unprecedented question in my (admittedly brief) history with the organization: "What can we do to help you?"

Simultaneously, we're working several big projects for a fairly new client whose ability to push requirements around mid-project is legend. Developing for these guys is like tap dancing on quicksand.

Seems like a prime opportunity to propose a shift to a more agile approach. The thing I know I'm going to get asked, and that I don't have any idea about, is how to quote/bid/bill for that sort of project. Do you go hourly? Do you bid a range of prices? Do you charge by the sprint?

More generally, the aspect of the Agile Manifesto that reads "We value customer collaboration over contract negotiation" is GOING to scare my management. How do you value that in the real world of customers who want a lot for a little?

Answer 1

We have the same problem in my company. There's a history of fixed-price, fixed-timeline projects, and our clients aren't generally very progressive.

Regarding development with no up-front commitments, I've heard so many fundamentalist agilists say, "I know it's hard, but you just need to push the benefits", or, "They might be skeptical but they'll see how well it went and come back to you next time". In some industries, maybe. In ours, that's a load of crap. I can't see any of our customers agreeing to just let us do our thing with no commitment on scope or price.

What we've found is that it's not always necessary to change the way you quote/bid/bill customers for an agile project. You can keep the agile process while sticking to your quote if you manage it properly.

Quote the way you normally would (with padding), and set some boundaries around the scope of the project. From that point on, follow your agile methodology:

• Prioritise the work with the customer - develop the important stuff first
• Develop in small iterations, showing your progress
• Collaborate with the customer to make sure you're actually developing what they want
• Grow the spec as you write the software

But more importantly:

• If a function turns out to be more complicated than what was originally requested, tell the customer immediately and make sure they're aware it will affect the timeline and/or price.
• Treat major (or even minor) changes as chargeable change requests.

You're still using Agile internally and getting the benefits, but the customer is seeing a more familiar fixed-price, fixed-timeline, fixed-scope project. Any changes cost money and blow out the time.

The hardest part about this is setting the boundaries up front. It's definitely not something that can be done by just your sales guy, BA, or project manager. You need an experienced developer in those meetings. You need to nail down the areas that could cause problems and decide on expectations.

Answer 2

A customer wants to pay little for a lot isn't going to pay more just because you write up a large set of requirments and get them to sign a contract. They will always come back and want it changed without paying. They'll claim they misunderstood the spec or better yet, you misinterpreted. They will demand changes knowing you won't push back. This is a bad relationship that you don't want to keep going.

If you break up a large project, and get them to pay as you go, it is easier to see that this amount of development costs this amount of money. The next componenent is going to cost the same amount and take the same amount of time to build. When it is all together in a large project, they'll want to get some sort of "bulk" discount.

I've hired someone to do work on my home. Started with a small project. Maybe I could have negotiated a better price by bundling a bunch of jobs together, but what do I do when he's in the middle of 3 projects, doing a poor job and taking longer than expected? I saw the quaility and timeliness of his work. And felt very comfortable having him to other jobs and I didn't have to monitor him. You could have a much better relationship with your clients. They may ask for more because they may feel you're taking advantage of them.

Answer 3

Try suggesting that your company negotiate a retainer contract, and then adopt your agile methodology to service the customer needs. You get paid $X for Y number of hours a month from your team. Because the customer is driving the priorities, nobody is going to be out of pocket. The beauty of the retainer is that they get your time regardless of what you're working on for them, and they can basically change their mind without killing you. The customer will get their value sooner for their money, and the model supports driving changes into the mix during development because of the agile methodology.

If the contract is not negotiable, then try the agile model anyways, but then you have to be diligent about making sure you're getting paid for your time.