Comments on: Building a House Agile Way

By: LameBigCOMgmt

LameBigCOMgmt — Wed, 04 Aug 2010 04:47:14 +0000

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.

By: Pawel Brodzinski

Pawel Brodzinski — Thu, 24 Sep 2009 19:43:56 +0000

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.

By: Mark D.

Mark D. — Thu, 24 Sep 2009 16:49:05 +0000

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.

By: Pawel Brodzinski

Pawel Brodzinski — Fri, 18 Sep 2009 09:30:01 +0000

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.

By: Susan

Susan — Wed, 16 Sep 2009 20:33:42 +0000

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

By: Pawel Brodzinski

Pawel Brodzinski — Wed, 16 Sep 2009 07:54:53 +0000

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.

By: Tonio Grawe

Tonio Grawe — Tue, 15 Sep 2009 19:53:10 +0000

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...