No, I don't buy into The Construction Metaphor
A few times a year, someone will write about how software
development is like building construction, and shortly afterwards a
bunch of people will write about how software
development is very different from building construction, but the two
disciplines can inform eachother. I'm squarely in the second camp. I think
software development is easier in many ways - our only real raw material is
time, and we don't
suffer from pesky constraints like gravity. I'm always happy to learn from
anyone who will teach me, though, and in this case it's a guy who spent decades
remodeling homes.
Short iterations all around!
Greg
Young just wrote about the impedance mismatch between agile development and the
fixed price contract mindset our clients are used to. Businesses like to
allocate a chunk of money to a shiny package, but we've realized that good
business software solutions usually don't come in shiny packages. We're not
alone in this problem, though.
This reminded me of a recent discussion I had with my father in law. Lenny is
a very wise man, and I always respect his opinion. This guy's always thinking -
he's put his philosophy degree to work. He's done carpentry and construction for
decades, and he's an accomplished singer-songwriter-publisher. Both industries
(construction and music) require some contract smarts, and Lenny's spent years
fine tuning the process of working with others in a way that keeps everyone
happy.
I was recently griping to him about the difficulties of keeping clients happy
on fixed price web development project. He just chuckled and told me it's
nothing new. He shared several parallels in his custom remodeling work - clients
who don't know what they want until they see what you've built, clients who tell
you exactly what to build and then are unhappy when you build it, the perils of
taking orders from someone and later finding out that the spouse who signs the
checks.
Interestingly enough, he shared with me that a lot of the people he
knows in the custom remodeling business have moved to one week phases.
This has tons of advantages, and while one week may be a bit short for a phase
in the software development world, the value of short phases plays well
here:
You identify requirements misunderstandings early
In almost 10
years of custom software development experience, I think one of the hardest
tasks is to build the software the customer actually wants. Not the software I
think they should have, and not the software they think they want, but the
software they'll actually use and be happy to pay for. There are a lot of
obstacles, but the worst seems to be
communication. The only thing that seems to help
is short delivery cycles. As with any inherently instable process, the
only thing that can keep us on course is frequent feedback. It's hard - software
developers don't like it because we find that the brilliant algorithms we've
been crafting have nothing to do with what the clients want, and clients don't
like it because they'd prefer to assume we've read their minds and are busy
conjuring up the accounting system of their dreams. The problem is that we don't
know exactly what they want, and we need frequent checkups to stay on course.
Early and often (as Micah often says) is the
key to eliminating the impedance mismatch between software developer and
software user.
Most software fails because it's a well implemented solution to the
wrong problem. We fine tune the aiming process, but we don't spend much time
defining the target. Good software is frequently used software, and the
only software that gets used is the kind that does what the end users want. Our
only hope is to push software as close to the end user as possible, as often as
possible. Real feedback is the lifeblood of successful software!
It's hard to get end users to evaluate software. We ask for feedback and they
roll their eyes - "Oh, okay, you guys have your little bureaucratic
checklists too, huh? Where do I sign so I can get you off my back and get to
work? And when is this thing going live again?" The best way to encourage them
to do what's in their best interest - evaluate the software at each checkpoint -
is to tie it to a payment. People seem to really check things out when they have
to pay for them.
You identify cash flow problems early
As Phil often
reminds me, cashflow
is king in a startup operation. We software developers have put a lot of
thought into optimizing the disconnect between what clients say they want and
what we build for them. We haven't solved it, but at least we know it's a
problem. Those of us who have ventured into the business side of software
development know that you can have a happy client and still be waiting
around a while for your money. There are a number possible kinks in the
money hose:
- The client you've been working for has a boss who turns out to be the real
client at the last minute. In the remodeling business, this game's called
working for the wrong spouse, but it can be trickier in the business world
where great-great-grandbosses can suddenly take interest in a project at the
last minute.
- The client doesn't actually have the money. The best credit check is a
cancelled check.
- The client has the money, they just don't put a high priority on paying
bills on time.
- And on and on and on... I'm sure you can think of several more.
You train the client on one of their most important jobs - paying their
bills
The small deliverables - with a payment at the end of each phase - helps us
to train and evaluate the client on one of their most important project related
duties - funding development. It's actually easier to (successfully) ask a
client for money if it's routine and the checks are small. Instead of waiting
for "opening night" to see if we've all got our financial act together, we
rehearse it over and over, and then we scale back opening night since we've
already delivered just about everything long before the final deliverable. Final
signoff is then kind of anti-climactic, since there's little risk of drama, the
client's familiar with the product, and they don't really owe very much at that
point. The stakes are low, and we can all focus on finishing the job.
You've never more than a week away from a "happy place"
Despite everyone's best intentions, clients may get upset. They assumed a
feature would be included due to some unspoken business rules, an
unexpected technical issue caused the deliverable to crash during a demo,
etc. The client is upset: "This whole project is a disaster!"
Small and frequent payments include both implicit (and with software
development, usually explicit) acceptance. So you always have something to fall
back to: "I understand you're upset. We'll get this fixed up and keep moving.
Now, you remember sitting with me just last Tuesday, right? You paid me
for the last bit of work, and we both agreed that things were looking good,
didn't we? So we've only got at most a week's worth of problems to sort
out..."
Client and developer interests are more closely aligned
The goal at the beginning of the project is usually clear to all parties. The
client has a business need, wants some software to make life easier, and is
happy to pay for it. 25% up front, 25% at midpoint, 50% on completion. Sounds
good.
Fast forward several months and the project is stuck in the 90% complete
phase. The development team is unhappy because the client keeps complaining. The
client's unhappy, but they're not going to pay a huge chunk of money and sign
off on this thing until they're happy with it, right? The only thing that often
forces the client's hand is a deadline, but that's pretty lousy for all
concerned. The development team works like crazy up to the deadline, and the
client grudgingly accepts it because they have no choice. Worse, though, is when
the deadline keeps getting pushed, and you find yourself in one of Zeno's
Projects.
There are two problems in this case, and they both stem from the fact
that the contract terms are divisive. In a project where a client pays
a chunk of money on completion, the contract pits the client against the
development team during that "90% complete" time. The problems here:
- The client doesn't really review the work until the last moment, so the
development team's been working under the false impression that they've almost
completed the software the client wanted. Maybe they were wrong, or maybe the
client didn't know exactly what they wanted until they started clicking, but
either way the problem is that the development team hasn't built
what the client wanted when they got around to reviewing it. As
mentioned above, this is solved by regular review and payment, since it forces
regular client review. Now they've been part of the decision making
process early on, which is great - they've had some time to correct
misunderstandings, fall in love with the product as it is. Any large
requirements gaps are obviously partly on their hands, too. The point is
that the client is no longer in an adversarial role in determining
requirements gaps as the project's in the "wrapping up" phase.
- The client's forced into a position which encourages them to get as much
as they can in exchange for a big chunk of money. Once that 50% chunk is paid,
the project's done, right? But until then, the development team is held
hostage to that final payment, so they may end up having to do what they
consider is extra work just to finish the project up and get paid. The
contract has succeeded in breaking up our happy team. Contrast this with the
case above - the stakes have been lowered. Then everyone keeps focused on the
task at hand - the client has much less incentive (or power) to
get feature greedy. This is just another weekly iteration, and they've been
reviewing the project all along so major feature requests at this point just
make them look foolish. There's no huge ransom for the last little bit of
work, just a fair payment for a week's work and the hope of future maintenance
work or projects together. The development team feels good knowing that
they're about to deploy what the client really wanted, and doesn't get too
worked up if the client decides they want a bunch of new features - fine,
we'll need to add another two iterations, and we'll be glad to do it for
you.
Can it really work in our world?
Well, one week phases are pretty short. Depending on the project, I could
see 1 to 3 weeks as a good range. Sam
Gentile posted about his recent switch to one week iterations, but did say
it's at the low end.
But how about the contract side of it? Our clients still want a big bid for
their project - that's how their budgeting process works. They have budgets
for office supplies and office parties, and policy says they need a budget for
their software projects, too. Well, just as agile teams sometimes have to
use a blocker to adapt to byzantine waterfall development policies, we can
sometimes benefit from some strategery on the contract
side as well. On a recent project for a large client, Micah help give the client
a contract they could understand, but with some solid iteration and
re-estimation included. The client has an overall budget estimate, but each
iteration starts with a re-estimation for that phase. He explained to the
client that in most cases the estimates will decrease, since the early estimate
includes some worst case factors which can be eliminated as the product takes
shape (see Jeff's post on the Mysterious Cone of
Uncertainty). Some clients may benefit from education on just how inaccurate
most software estimates are, and how both lowball and high estimates ultimately
hurt them.
What do you think?