Earlier this summer, I had the opportunity to speak to a group of lawyers regarding Agile Software Development. This was a joint panel discussion with a couple of subject matter experts who were there to discuss the pros of Open Source software. While my performance left much to be desired, the open source subject matter experts were phenomenal in their explanation and use of metaphors. Some of the metaphors used were:
- The German Enigma machine when discussing the concept of concealing the “how” versus concealing the “what”
- A door lock when discussing the availability of how a lock works versus the concealment of the “key” which unlocks the lock
- The comparison of a car with the hood sealed shut when discussing closed software versus a car with the hood that opens when discussing open software
While the subject matters experts used several other metaphors, one that resonate with me from an Agile perspective was the metaphor of a house.
The Open Source SMEs used the metaphor in terms of the public nature of the architectural plans of a house. It is as follows, when building a house on spec, the plans for that house are filed with the County where the house will be built. While the plans are owned by the homeowner, they are available and most times publicly. The public nature of the plans do not prevent the homeowner from building the home. Further, while the plans are public they do not limit the ability of the homeowner to secure and insure the belongs in the house.
So what does this have to do with Agile Program Management?
I regret not leveraging this metaphor further for Agile software development. Using Agile software development is similar to being able to live and test each room of a house as it is being built. It also allows the homeowner to prioritize the building of the rooms of a house based on the homeowner’s priority but respective of the infrastructure necessary to support the rooms. For example, if the homeowner prioritizes the master bedroom as the most important room, the builder will build the infrastructure necessary to support that room first. This may include installing the plumbing for the en suite and installing the HVAC for the heating and cooling. It may also include the installation of steps and the minimal framing of lower levels to support the master bedroom, if it were on the second floor.
The house metaphor was also appropriate as it similarly fixes cost and time as an agile software development project does. In most cases when building a house, the homeowner is bound by time for delivery and a budget. The fixtures and elements (e.g. the scope) of the house are changeable based upon the homeowner’s value selection. If a homeowner does not have the budget for that third bathroom, it will not be delivered in the scheduled timeline but a later rehab may take place. Again, this is based upon the homeowners relative value of maybe adding a walk-in closet.
The house metaphor was a great metaphor to explain the iterative and value based nature of agile software development while considering the architectural components required to deliver each room of the house. I regret not taking the opportunity to use it when it was presented.
