Lessons from Home Remodeling: One Week Phases

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:

1. 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.
2. 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?