There are a number of ways that we try to compare software development with more concrete things in our lives, such as building construction. We have software architects, analogous to building architects. We've borrowed the idea of Patterns from the architect Christopher Alexander. 

While there are some benefits to viewing the world in this way there are differences. (One of the interesting thing about Patterns is that patterns are about organic growth rather than the traditional "master plan" approach to city planning and architecture, so borrowing Patterns from architecture works better than analogues with the building world because it's about a different way of looking at buildings than is traditional.)

A recent experience while renovating my house had me realizing that many of the issues that I was worried about were very analogous to issues I dealt with daily in my role as Scrummaster for a software team. During the past year my wife and I decided to basically gut our 1890s era house, undoing a poor addition that had been done in the 1950s, reconfiguring the existing space and adding a room. During the initial phases things seemed to be moving along. We had plans drawn up by an architect who understood our needs at a high level, and the general contractor made visible progress. It was towards the end of project that things got frustrating.   Things weren't happening as we expected. We fell out of the rhythm of weekly meetings. I felt out of the loop about some things and what started out as a team of Architect, Homeowner and Contractor moving towards a goal started to feel like a circle of blame, where everyone was upset at each other. 

I thought about this a bit and realized that what was missing from the building experience was the main thing that makes agile software projects successful: feedback. I would have been happy if I knew at the start of each week what would and would not get done. That we would be making progress, and that the progress would focus on my priorities would have been as good as everything being done on schedule.  If we had had daily scrums that would have gone a long way towards keeping the project moving, but that was too much of a culture change introduce!

So, if agile values like: Customer Collaboration over Contract Negotiation add value to a construction project and other aspects of "real life" why isn't it blindingly obvious that agile processes and values help build better software projects?

Comments (1)

George Dinwiddie: ... Nice insight. There's been a bunch of discussion about the construction analogy in the past year, and I've added some of my own at http://blog.gdinwiddie.com/2006/12/27/the-construction-analogy/ 1 December 27, 2006

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close