Now I remember why I blog, the conversation and finding new people. So Richard Banks commented on my post before this one, which led me to his blog, which led me to his post: Fixed Price Contracts and Agile Delivery
Richard asks /comments / rants about / on fixed price / firm spec'ed projects and your agile / scrummy / xpic team.
He asks:
In a recent post I wrote about a not-too-uncommon scenario in which a customer wants a fixed price software project to be delivered, but is still trying to figure out all those pesky details and then I asked the question on wether you would take the project on or not? Even if it meant turning down a massive potential upside for your business and therefore, for you.
So I will tell a story about how we've somewhat successfully dealt with these issues. ... Somewhat.
We do most of our work for government agencies. They love specs. They can't get enough of them. Why? Because it is, as Richard notes, the path of least resistance to blametown.
The only reason to ever use a rigid spec is you:
1. Have no control over your own processes
2. Want to make an airtight legal document
That's it.
I had a VP of Engineering once ask me for a tight spec for a project we were working on. We had this exchange (sorta):
Him: Dude, gimme a spec. I so totally need a spec.
Me: What? Why?
Him: My Mom says I gotta have a Spec or I can't play with you.
Me: How long have you been in software.
Him: 20 years.
Me: When have you ever seen a spec successfully implemented?
Him: Like, never.
Me: Tell your Mom we've got a better way.
Him: Zoiks!
His mom in this case was the internal review group he worked with. They had always had specs. Specs were little holy units of negotiation. That each one inevitably ended up crushed on the rocks of disillusionment meant little. They were each and every one merely fallen, but someday, that righteous spec would rise up and blind all with its magnificence.
In other words, he had no control over his own process.
We have had limited success with rigid scopes. We try to be good at explaining the concepts of feature prioritization and working to the budget and deadline and not the full feature set. We've had mixed results.
We ended up ducking out of the full spec for that project and it's cost us a lot of money. We've taken others that we felt were more predictable with varying results - seldom stellar.
But we have taken them simply for cash flow.
Richard also says:
And then the "other reality" sinks in. The world is run by accountants. Most CEO's come from a finance background, they have profit as their primary goal (not successful projects), their #1 confidant is usually the CFO ... It's this "other reality" that means that fixed price, fixed duration contracts are the norm. It's this other reality that makes the introduction of agile processes so hard and why it's so hard to keep them in place. Agility is about cooperation; "reality" is about combat.
While I can't outright refute this, I do take a bit of an exception given my somewhat CEOness.
We've taken a variety of approaches - from Ghandiesque "be the agile change you wish to see" to more Patton-like "Do your damnedest in an ostentatious manner all the time" - to get our Agile philosophies adopted by our clients.
One of our business partners once chastised us for not adhering to General Patton's quote. We were doing things that we thought were matter-of-course and going on about our business. It turns out people thought we weren't good team-players simply because we weren't being ostentatious. We didn't toot our own horn. He told us, "You need to get credit for what you're already doing."
Agile teams are at the forefront of a movement. But the front lines are the bloody lines. We're going to get knocked around a little. But you need to let all levels of your clients management structure know what you aim to do, why it is good for everyone involved and then that it's done and it worked.
Maybe you do this with a pipe and a scarf, maybe not. But what both CEOs and CFOs really want is totally agile. They want:
1. profitability
2. information
3. reassurance
And Agile will give that to them much much faster than a strict spec and a big stick.
Thanks for the response :-) (and nice post again!).
In my experience cash flow is the absolute number 1 reason companies take on business that doesn't fit within their core area or marry up to their ideal engagements.
That's fair enough too. Without cash flow, all the lofty ideals in the world won't cover your employees next pay check or the next tax bill, etc. But the cash flow excuse is a slippery slope for many. When you take on "pay the bills" jobs too often you can erode who and what you intended your company to be. This can be especially difficult if the cash flow jobs are really profitable. The Jim Collins books (Good to Great, Built to Last) tackle this subject quite well (core values, idealology, etc).
Oh, by the way, "Most CEO's" doesn't mean all. I'd consider you a little left of centre for a normal CEO :-)
Posted by: Richard Banks | 03 September 2007 at 21:54