As Agile methods become more mainstream and accepted, it is often surprising to new (converts/adherents) that the ideas embodied in Agile techniques are not new, nor are they restricted to the software engineering domain. Software engineers frequently take issue with the sequential development processes that are believed to be at the core of civil engineering - in response to the "why can’t you build software like they build bridges" criticism sometimes levered at software development. The reality is that civil engineering projects frequently apply approaches that Agilists will recognise.
Some examples of this crossover can be found in recent articles:
Howard Podeswa discusses a construction project in the Modern Analyst blog:
I was having dinner with a friend of mine - who also happens to be a gifted architect and designer. We were talking about a project he is working on where he is responsible for handling design aspects of a large commercial property development. One of the things that struck him as particularly challenging on this project was the fact that the buildings were literally going up as the design was being worked on. This meant that many different activities were going on at the same time. Instead of going through a single pass of upfront design followed by construction, they were developing this project in a set of short cycles; each time through they pinned down the requirements for an aspect or area of the complex, did just enough design to get it built and then constructed it on the ground
He goes on to discuss ways in which architects are tackling the challenges of building in short timeframes and having to design buildings while some of the requirements are still unknown:
Don’t commit to something today that you can put off till tomorrow. In other words, if you can delay a decision without delaying the project, put the decision off. But if you have to make a decision, thenChoose the option that least constrains the future. That way you minimize the impact of making a wrong decision.
He provides a practical example of what this means to the building designer:
Here’s an example of how the second principle works in his industry: The designers were required to put in a staircase before they even knew how the rooms on that floor were going to be used and what their individual sizes and layout would need to be. So the designers chose a staircase position that left them with the most flexibility for laying out the rooms later. In this case it meant rejecting a central staircase, because it would rule out options for room layouts more than a staircase off to one side.
Adaptive Reuse is a civil engineering principle that has echoes in the software world. Adaptive reuse is the process of adapting old structures for purposes other than those initially intended. In the Agile software world the use of design patterns and refactoring are examples of adaptive reuse applied.
Rich Maltzman author of the Scope crêpe blog discusses how adapting to changing needs and project dynamics was necessary even in the building of the pyramids, and how Agile techniques have been applied to the problem.
He discusses how the project manager adapted and showed his or her agility with the change in slope midway through the project.
A comment on the blog links to a Slideshare presentation by Damian O’Malley and Steven Stark on the Brief for the Sistine Chapel which explains how a clearly articulated vision can result in a product that meets and exceeds the customers’ needs.
Michelangelo's brief for the chapel was:
Please paint our ceiling for the greater glory of God and as an inspiration for his people
Michelangelo took this brief and painted frescoes which depicted the creation of the world, the fall, mankind’s degradation by sin, the divine wrath of the deluge and the preservation of Noah and his family. He knew what to do - and was inspired by the importance of the project. With direction like this he was free to devote his attention to executing the details of the brief in the best way he knew how.
What other lessons are there that the software industry can learn from other professions?
Community comments
Pricing of design-on-the-fly projects
by Bruce Robertson,
Re: Pricing of design-on-the-fly projects
by Petr Sobotka,
Analysis and design of the structure
by irsal imran,
Whole Picture
by Sundarraj Kaushik,
Michelangelo's proactive approach
by Bartosz Klimek,
Pricing of design-on-the-fly projects
by Bruce Robertson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I am curious about project pricing when you don't know what your design will be.
Analysis and design of the structure
by irsal imran,
Your message is awaiting moderation. Thank you for participating in the discussion.
You can't analyze the structure of the bridges, like how big and how many the beams needed, what material being used, etc, if you do not know the whole picture of the final design. Off course you can change the color of the paint or other non-structure part, but you can not change the structure parts of the bridge when construction already started, or the bridge will fail.
Whole Picture
by Sundarraj Kaushik,
Your message is awaiting moderation. Thank you for participating in the discussion.
What can be changed potentially is the internal layout of the building or the paint as mentioned earlier and that too within limits. One cannot suddenly decide to put something really heavy without having planned for the beams to bear such a heavy weight.
Similarly if one has laid a foundation for a certain number stories then one cannot increase the number of stories after that without great difficulty.
Certain fundamentals cannot be changed without much difficulty. This hold good for both Civil Engineering and for Software too.
A Michelangelo could show his creativity because there was know nit-picking on part of the his client with respect to requirements. If somebody asks one to create an HR solution it is difficult to build one unless one knows exactly what to build.
Some of the comparison is OK, but not convinced that the comparison as trivial as it seems to have been made.
Michelangelo's proactive approach
by Bartosz Klimek,
Your message is awaiting moderation. Thank you for participating in the discussion.
What struck me about Michelangelo's example is the trust of his clients in his skills - not only technical painting skills, but also the general feel of what should be painted.
The team of software engineers I'm a proud member of ;) evolved from being sheer implementors of business specifications to proactive participants of business development. At the early stage I believed in a clear separation of business specialists and software engineers. It's not that I rejected to get to know the business, but I simply considered the business people as the most appropriate ones to make business-logic decisions.
Thus I used to force them to go through detailed complex scenarios to gather the knowledge needed later in the implementation. That was a pain since they seemed to loose focus and interest at some point, which astonished me.
But then I realized that they did not want to tell me what the software was going to do, nor did they want to describe detailed requirements. What they expected was: "Guys, just look at this business case and do your best to solve it and make our customers happy". And so we did.
Re: Pricing of design-on-the-fly projects
by Petr Sobotka,
Your message is awaiting moderation. Thank you for participating in the discussion.
You are a lucky man if you always make your pricing after finishing your design. From my experience (in software development) in the majority of cases we must tell the price with only knowing the basic ideas of the customer. Of course you need experienced people who can make such estimations without big mistakes.
Petr