≡ Menu
Pawel Brodzinski on Software Project Management

Building a House Agile Way

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.

in: project management

7 comments… add one

  • Tonio Grawe September 15, 2009, 12:53 pm

    Looks like this will be a nice house – once it is finished. Seems like the agile method is a good approach for the vendor to make extra money. Is that way it is so popular with software developers?

    To be honest, I always sticked to the conventional project methodologies. And I rather spend some more Euros in planning and go the extra mile for the bottom up approach. Also when I build a house it was like this. I'm surprised you didn't think about the furniture. For our kitchen I even drilled in a level deeper and planned on what shelf the plates will be, in which closet we will store the bread and what drawer is reserved for the sweets. Just to make sure we have enough space in the kitchen.

    Anyway, that doesn't mean we didn't spent much more money than we should…

  • Pawel Brodzinski September 16, 2009, 12:54 am

    Agile is not a good way for a vendor to make extra money. When client has fixed budget this is it – it's fixed. When money runs out there aren't iterations anymore. If something isn't done it's probably unfinished for good. And what's already done, no matter how, is here to stay.

    This means the client can be forced to make difficult decisions about cutting out features and a final version can be pretty far from ideal. On the other hand, with detailed specifics up front it's equally far since it's almost impossible to design every detail well at the beginning of the process.

    Talking about house I can't imagine going to that level of details while still being on paper. I don't have problems with imagination and I can quite easily visualize how furniture would look like but until I can touch everything I can't really say whether I like something or not.

    Not to mention all decisions we have changed along the way because we've learned more or just changed our mind.

  • Susan September 16, 2009, 1:33 pm

    From my perspective Agile works when the client knows exactly what they want. Sadly you quickly find when the business requirements documentation is being detailed that this is not the case, and then you are heading for a world of pain particularly if it is fixed price.

    The important thing to remember is that the process of software development can be flexible but this is only a benefit if it leads to a higher quality product which meets the client's expectations. Sadly this rarely happens.

    Regards

    Susan de Sousa
    Site Editor http://www.my-project-management-expert.com

  • Pawel Brodzinski September 18, 2009, 2:30 am

    Susan,

    It's a rare situation in IT when a client exactly knows what they want in terms of software requirements. They do know what they expect from software business-wise but it doesn't correspond well with defining lower-level expectations (let it be requirements or user stories or whatever).

    What more, as I understands agile it's a method to respond to this uncertainty since, unlike in BDUF projects, you can change things along the way.

    The problem I see is simple – if you have fixed budget (a strong constraint) and much freedom in inviting changes there's a big risk of spending too much time and money on looking for the perfect solution at cost of running out of budget and not finishing all important things.

  • Mark D. September 24, 2009, 9:49 am

    The problem with the agile approach to construction (as it seems you've encountered) is that you must factor in the cost of building materials, as opposed to software where the "building materials" (lines of code) are free. Now, in this discussion I'm totally ignoring the cost of labor and tools, which you have in both instances. This critical element, the cost of building materials, is what automatically pulls the house building process toward the BDUF end of the spectrum. Which isn't to say that construction projects are entirely BDUF. For instance, you have structure models that can be built/tested before the actual construction begins, etc. But there's no getting around the fact that construction projects can never be nearly as agile as software projects. I'm reminded of an old episode of the Simpsons where Homer is building a dog house, and right when he thinks he's done he realizes that he built it without a door :-) In that case he didn't just waste time but also the cost of the building materials.

  • Pawel Brodzinski September 24, 2009, 12:43 pm

    Mark,

    I do agree that construction process are predestined to be closer to BDUF end of the spectrum than software projects. After year of house building I couldn't say anything else.

    The point I completely don't agree with is labor cost. Lines of codes never comes for free. In software companies you can have up to 90% of total costs sunk in money you spend on labor.

    An hour of writing code you'll throw away is equally painful as an hour of building a wall you're going to demolish. Yes in the latter case you pay for cement which is lost (bricks can be recovered) but it's negligible.

    If a customer doesn't know what they want it's costly in both cases.

    To be honest most of the time cost of materials wasn't a problem. Actually you can pretty easily decide up front whether you wand floor for $80 per square meter or one for $30 per square meter.

  • LameBigCOMgmt August 3, 2010, 9:47 pm

    Building a house in 3 week sprints:
    –End of Sprint 1: Deliver a tent (a left over from an intern’s project)
    –End of Sprint 2: A tent with windows (holes cut in the side).
    –End of Sprint 3: Move tent on top of some wood planks (the new floor).
    –Start of Sprint 4: project canceled due to external factors. Agile worked great, velocity was high and managers had lots of metrics to play with.

Leave a Comment