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.
I had both sides of the story in my carreer, and personally found the landscape thing literally hell. Even the constant movement of other people distracts me, let alone the humming noise of talking, phones that go off, meetings right next to your desk, and the fact that you lack enough daylight and fresh air when sitting in the middle. I like a rather fresh temperature, makes me think better. Not everybody agrees though.
Currently we're three in one office. It's still not perfect, but it does help that my colleague and I can discuss server-related issues while we're working on it. And it saves office space. But honestly, more than three I hope I never have to experience again.
So in summary, I think it's important to look at :
- modest interruption
- enough light and air
- putting closely collaborating people together, but not more than that
YMMV.
Best Answer
First I'd like to say that the points in the manifesto are not mutually exclusive (e.g.: working product over docs might also overlap with collaboration over contracts)
Having said that, I think the best way to explain where points 3 and 4 don't overlap is by example
In an overly contractual setting each party will usually defend their rights even if it is at their own expense to ensure that the other party knows that they won't tolerate any infringement of their rights. Obviously in a collaborative environment these sort of stances are less likely to be taken.
For example let's say the contract stipulates that all severity 5 defects are resolved in no more than a month, and the vendor hits a really tricky issue that would take months of man effort to resolve. The customer can then chose one of several paths
From experience the last path usually ends up hurting everyone, as the vendor is squeezed they spend less on improving the quality of the product, leading to more dissatisfaction leading to a more aggressive customer posture leading to more squeezing. A never ending cycle :(
Hope that illustrates the point