Agile Architecture
Long ago I studied architecture by designing and constructing buildings for my college. It was a unique program, and, in retrospect, it was an agile development process. Building design is normally a classic waterfall process, so it's interesting to look at what happened...
Each project was run by a professor-architect . We began with a plan that included the building program (requirements) and a basic framework for the design, with few details. Every few weeks we would get together and agree on the next part of the project, craft the details, and begin what we might now call a sprint. Every morning we would meet (our scrum): the crew of students, the faculty architect (analogous to the product owner), and our professional contractor (our scrum master). In the summer, we would meet on the site; in the winter (this was Vermont) we would meet in a small construction shack around a hot woodstove, and draw on the walls (which we would paint over periodically). Our designs were incremental: every morning we would review the previous day's work, and adjust our plans accordingly. Sometimes we decided that work that was underway needed to be changed or even removed - we felt free to improve by tearing things out and starting over if necessary. Our users - school staff - would visit now and then and make suggestions. When the project was done satisfactorily, we moved on to the next one.
I'm not making this up.
If you're an architect, you'll say "building design never happens that way." Well, it did, because we were working for our school, and the school gave us license to experiment. After all, the crew was paying (tuition) for the opportunity to build this way. If you're an agile software developer, you'll say, no way, this sounds too much like the agile process (and this was long before Agile was articulated).
We stumbled on this process for a reason. It wasn't a grand theory - it just made sense given our goals (a desire to build something special while learning new approaches to design) and college's willingness to experiment in exchange for free labor. We were able to design buildings incrementally, evaluating progress and making adjustments based on our observations. The results were pretty good. (Link to photos.)
Traditional architects don't generally work this way because on-site design is too expensive when you have a large crew of expensive builders to keep busy. ("Feed the beast!") Historically, buildings have been designed and specified 100% in advance, and the "product" is built to spec. The downside, as in software development, is that poor design and actual errors are often unnoticed until people move into the building, when it's often prohibitively expensive to make changes. Sound familiar, waterfallers?
Interestingly, modern design tools have provided ways for architects to simulate buildings with extraordinary realism: Building Information Modeling tools like Autodesk's Revit and NavisWorks enable designers to realistically envision the construction process and the final building. Design teams now have the ability to work more incrementally than ever, with meaningful feedback from clients and builders along the way. In effect, tools for rapid prototyping and evaluation have given the architects the same ability to "be agile" that modern development tools have given software teams.
If you think about it, many kinds of artistic and creative endeavors are approached incrementally. Painting, sculpture, writing - they're all done incrementally, with ongoing self-evaluation and revision. There are team-endeavors that work this way too: movie making and music recording, for example.Even pure engineering, in the design phase, tends to be incremental - an airplane is designed iteratively, with many iterations based on internal review, wind tunnel tests, etc. Perhaps a "design everything in advance and then build it as designed" approach is really an aberration, serving primarily to give architects and software designers a sense of control over the outcome that may actually be illusory.
My early experience with "agile building" and the rapid acceptance of agile software development lead me to believe that an incremental development process is a natural way to work when the right conditions are in place. These "conditions" are partly technical - tools for rapid development and evaluation - and partly social - a willingness to be flexible and to iterate until a product is "right." With these in place, why wouldn't you choose to work this way?
Each project was run by a professor-architect . We began with a plan that included the building program (requirements) and a basic framework for the design, with few details. Every few weeks we would get together and agree on the next part of the project, craft the details, and begin what we might now call a sprint. Every morning we would meet (our scrum): the crew of students, the faculty architect (analogous to the product owner), and our professional contractor (our scrum master). In the summer, we would meet on the site; in the winter (this was Vermont) we would meet in a small construction shack around a hot woodstove, and draw on the walls (which we would paint over periodically). Our designs were incremental: every morning we would review the previous day's work, and adjust our plans accordingly. Sometimes we decided that work that was underway needed to be changed or even removed - we felt free to improve by tearing things out and starting over if necessary. Our users - school staff - would visit now and then and make suggestions. When the project was done satisfactorily, we moved on to the next one.
I'm not making this up.
If you're an architect, you'll say "building design never happens that way." Well, it did, because we were working for our school, and the school gave us license to experiment. After all, the crew was paying (tuition) for the opportunity to build this way. If you're an agile software developer, you'll say, no way, this sounds too much like the agile process (and this was long before Agile was articulated).
We stumbled on this process for a reason. It wasn't a grand theory - it just made sense given our goals (a desire to build something special while learning new approaches to design) and college's willingness to experiment in exchange for free labor. We were able to design buildings incrementally, evaluating progress and making adjustments based on our observations. The results were pretty good. (Link to photos.)
Traditional architects don't generally work this way because on-site design is too expensive when you have a large crew of expensive builders to keep busy. ("Feed the beast!") Historically, buildings have been designed and specified 100% in advance, and the "product" is built to spec. The downside, as in software development, is that poor design and actual errors are often unnoticed until people move into the building, when it's often prohibitively expensive to make changes. Sound familiar, waterfallers?
Interestingly, modern design tools have provided ways for architects to simulate buildings with extraordinary realism: Building Information Modeling tools like Autodesk's Revit and NavisWorks enable designers to realistically envision the construction process and the final building. Design teams now have the ability to work more incrementally than ever, with meaningful feedback from clients and builders along the way. In effect, tools for rapid prototyping and evaluation have given the architects the same ability to "be agile" that modern development tools have given software teams.
If you think about it, many kinds of artistic and creative endeavors are approached incrementally. Painting, sculpture, writing - they're all done incrementally, with ongoing self-evaluation and revision. There are team-endeavors that work this way too: movie making and music recording, for example.Even pure engineering, in the design phase, tends to be incremental - an airplane is designed iteratively, with many iterations based on internal review, wind tunnel tests, etc. Perhaps a "design everything in advance and then build it as designed" approach is really an aberration, serving primarily to give architects and software designers a sense of control over the outcome that may actually be illusory.
My early experience with "agile building" and the rapid acceptance of agile software development lead me to believe that an incremental development process is a natural way to work when the right conditions are in place. These "conditions" are partly technical - tools for rapid development and evaluation - and partly social - a willingness to be flexible and to iterate until a product is "right." With these in place, why wouldn't you choose to work this way?