Some time ago I wrote a series of posts where I compared specifics of my private project of building a house with my professional experience in project management. It would be hard to say these situations look the same although usually the same mechanics applies.
Talking about that, one thought struck me some time ago. When you build a house for yourself it’s most likely a purely agile project. I haven’t yet heard about investor who hasn’t changed anything in their house during its construction. Of course we rarely change outside walls etc, but inside a house there are loads of changes.
That’s pretty much expected since at the beginning no one really thinks where they would place furniture and what kind of furniture would even be there. We don’t think where exactly lamps or power plugs should be. These are details which we leave for later. Hey, who cares where exactly would save button be placed on an edit form while we don’t even know what kind of data would be edited there?
So agile, isn’t it? At the beginning just architecture design and then, through each iteration, planning in details what’s going to be done in short term. Embracing change. Actually while not every company which were working on my house were excited as I (actually my wife most of the time) was changing conceptions, I can say virtually every single one embraced change.
And charged for that.
And I didn’t really object.
Actually somehow that’s natural in construction world. Guys get plans. They build according to plans. If you have better idea and they have to, well, ctrl+x and ctrl+v a wall or something you’ll know they did the job twice when it comes to pay.
I don’t complain. If I told them earlier they’ll put it in the right place at the beginning. Except until I saw the first version I couldn’t tell I wouldn’t like it. What a pity walls are so hard to refactor.
This brings me to a point. Being on a client side I treat the agile way of building a house as a mixed blessing. OK, I admit I can’t imagine building a house according to BDUF specification with no changes at all so agile is a natural choice here. On the other hand it doesn’t come for free. I pay for each change which generates additional work. In other words I can’t define how big my budget should be to achieve functionality I want since I can’t say how many changes my vendors would have to embrace and how many iterations it would take to satisfy my (beloved wife’s) expectations.
Unfortunately shit happens and I actually had a fixed budget for the project, which in my case means I’ll run out of money before everything is done. And this is the place where agile sucks. Ten months ago a construction company came and said they would adjust reinforcement for this amount of money and they would change bricks to better type for that amount of money. And I was all “yeah, we should do it since we’ll have more freedom in arranging inside walls and the house will be warmer.” With this huge stack of money we had it didn’t look like a big deal anyway.
And no, I couldn’t plan how much exactly I needed for the rest of the project. I didn’t have all the details to be able to do that. You know, other way it would be old-school up-front design project, not the agile one.
Having said that, while building a house agile approach is the best possible option. One just needs to understand advantages and disadvantages of choosing this path.
One more thought for the end: I wish IT business were as aware of costs connected with change as construction business is (even though it’s far from perfect there too).
PS. If you happen to visit me and would be curious where the heck a balustrade is or is this some modern way of finishing off stairs the answers is: this is the price of agile.