Looking to other domains

Over the years we have seen many software design and development models evolve, each using a set or subset of formal processes; requirements analysis, design, implementation, testing, maintenance etc. From the waterfall model, bottom up, top down, evolutionary variants, to those with a prototypcial focus, test driven design/development (intentional programming) to the newer iterative models; iterative development, agile and extreme programming. Each of which has spawned meta process models along the way like agile, SCRUM. One interesting quote that made me think twice was posted by Robin on our agile boards.

"You cannot solve a problem with the mind that created
 it."

This reminds me of the notion that the person proofing ones work should not be the author of that work. But the context it was placed in was with respect to classifying problems and solutions with the intent of replicating it.

"We have seen a solution to a problem,
recognize what went well and what did not. It does not
 necessarily translate to a recipe for success in
 another project, in another time, with other resources
 in another domain."

Whilst this is a pertinent point I think we still have plenty to learn in the software world. Just look at how many problems the industry is still plagued by:

• Huge costs - Usually higher then projected
• Overall project failure
• Longevity - aging systems and maintenance hell
• Often not delivered on time
• Poor quality
• Falling short of addressing the intended problem
• Software developed with no intended purpose

So why can't we look towards other domains that have been successful in developing and applying models? I think there are still many things we can look at in other domains like construction and else where that have been quite successful in developing, applying and replicating process models. Software models have evolved over time but this doesn't necessarily mean they are getting any better though (I'm not saying they are not). When it comes to less documentation, more focus on the output that the customer wants (business value) and overall quality I am increasingly seeing the value in agile methodologies. Take for example SCRUM, a meta-process model for agile development. Drawn from the game of Rugby it defines an abstract model for development. The model can be thought of as abstract or a meta-process as it only defines the steps involved and their appropriate transitions. It does not specify how each step is carried out or what is involved in each step. This allows the model to be easily moved and applied to projects in different domains. The SCRUM model is just one model taken from another domain (Rugby). I suggest until we successfully address many of the problems above we continue to look towards other domains, capturing what does and does not work. They may not have gotten it completely right. But neither have we.