Well would you? I don’t think most people would, and it would be really interesting to see how the agile houses would look. We’d work in iterations, so I’ll probably start with the smallest deliverable object, a tarpaulin across some trees and build from there. Need another bathroom? Just add a few more walls, knock a hole in the wall and raise four walls and put the tub down. Feeling cramped? Tack on another floor. After each week the builders could sit down and talk about how to alter the building standards based on the mistakes of last week and provide a new set of building standards.
Does this sound ludicrous to you? Of course it does. But why?
Because houses aren’t software. And the environment they work in is not agile, and it never will be. You submit your plan and get planning permission, which can’t be changed without considerable effort and cost. You can’t change the standards on how to build exterior walls halfway through a project, or decide that you’d like more rooms after the foundation is done. It won’t fly. Pictured is the bent pyramid of Dahshur, in which the builders realized that the angle of the pyramid wouldn’t work halfway up the top. So they, predating the agile movement by some 4600 years, changed the design and rolled with the punches. I bet the pharaoh wasn’t too pleased about the end result though.
A hegemony of scrum
About two years ago I was at Öredev , which is the largest developer-centric conference in my region. Someone had the brilliant idea of putting a large note on the door to the mens bathrooms proudly proclaiming them to be site of the “waterfall classes”. Such is the state of the software industry in here that the venerable old waterfall model is more ridiculed than respected as a real technique. And yet if you were building a house, I’d wager you would use the waterfall model to build it, and you’d use the agile methods to build anything made out of software.
But really, are all software software? Are, in fact, some software more like houses? And are we really doing ourselves a favour by applying an agile method to something that isn’t suited for agile development.
Consider writing a software application for a washing machine. Is it more like a fast moving web development scenario, or is it more like building a house. You’ll never be able to change the software after your product has shipped. If you have bugs in your software the costs could be astronomical (think water leaks, electrical fires whatnot).
I’m not saying that there aren’t things in agile that our prospective washing-machine-software developer can take home with him, but I’d wager that even if he chooses an agile method for the daily tasks, it will be strengthened with the inclusion of a waterfall-like model on top. And that’s not a bad thing.
How much of a house is your software
I believe that this has to do with the cost of change after shipment, and the agile adoption of the rest of organization. If the cost of change is very high, or the cost of running your agile process within an organization that simply refuses to conform to an agile model then you’re probably better off doing a different kind of software development methodology. Preferably one of your own design.
Scrum is a very strange beast, since it is one teams evolved plan that worked for them that has been codified and subsequently adopted by people across the software development world. Sometimes it works, often it doesn’t – or at least it doesn’t get fully adopted. If you’re in any way think that the software you’re building or the organization you’re building it in has some characteristics of a housing business scrum as it stands probably will never work out the way the evangelists say it will.
Roll your own
I’ve a feeling that when the case for scrum isn’t clear cut, we often go about process change the wrong way. And by wrong way, I mean by bringing in agile consultants that are supposed to implement a codified scrum. They constantly tell us that we are supposed to modify things as we go along while at the same time telling us how it really should be done. Why not just evolve things on your own?
The only thing you really need is the current baseline, i.e. what you have going right now – even if that is nothing at all, and a whiteboard. Take one thing from scrum, the retrospective and sit down. Rank all the crappy things in your working environment and address the worst one. Don’t even bother with anything else. It’ll take a while, but you’d find the best way of doing things given your situation and your software.
How are your thoughts on this, are you also experiencing a move towards just taking a boxed implementation of what has worked for someone else instead of actually doing the pretty easy task of finding out what would be the actual best method for your organization?