David Anderson has suggested through Jim Shore that software development is not like construction. Once again David may be confusing "project management" with "product development."
Certainly the development of a building, highway, and sewage system is not done in the same way the development of a software system - at least at the detail level. But David and Jim seem to be missing the field observation of the massively parallel activities, customer interaction, continuously changing plans and deliverables focus that takes place in construction projects. Yes the framers can't start their work until the foundation is poured sounds like a nice description of a residential house. Actually in residential construction they do start their work while the foundation is being poured. They build up wall sections (roof sections as well), lay them in the yard ready for setting once the subfloor has been completed. This is the case in a petrochemical plant constuction as well - the "bone yard" its called.
Having worked in petrochemical, pulp and paper, pharma plant, and nuclear site remediation, the massively parallel "development" with "full contact" customer engagment is the norm. Any prime contractor performing the work in a serial manner in the absence of the customer while focusing on documents would be late and over budget. From David's post
From the agile manifesto, the only value that immediately jumps to mind as appropriate for home construction might be customer collaboration over following a plan. I fail to see what individuals and interactions over processes and tools, or working software over comprehensive documentation, have to do with construction. I think a vague case can be made for responding to change over following a plan but who would seriously contract with a construction company without an agreed plan. A garden shed, maybe, but a full house? C'mon, let's get real!
Let me explain a bit how large construction jobs (from my limited experience in those industrial sites where we I developing and installing either the control system or provided engineering services to the contractor - piping design systems for example).
- Customer collaboration - change orders occur nearly daily, sometimes after the concrete has dried. These change orders come from customer needs that are discovered after the design is committed. This is not desirable of course but it is normal.
- At the construction site of a major pharmaceutical plant here in Longmont I worked on the document management system. This system controlled the continuous changing drawing set between the architects of the plant, the project managers and the prime contractors, who's offices are in South Carolina. In a manner similar to a software project where the customer comes to the iteration meetings with a new requirement, the plant construction manager would come to the weekly review with changes in the physical aspects of the plant. Why? Because the underlying biochemical process was being built along with the plant. They could not wait until the biochemistry was complete before starting construction. It would put them behind the competition.
- Yes the foundation for the plant was designed and built long before the 3 stories of 10 acre floors were build. But this was a standard floor loading (industrial standard loading) so the structural engineers could design and build this independent of the actual equipment going in the building - in most instances.
- The plans were "guidance," the customer changes were the reality. This is why in the EDM system there are "as designed," "as built," and "as operated" (21CFR) drawing and document coding in the database. This is the case in all major construction projects where health and safety are involved.
- Individual and interactions over processes and tools - it may be that David and Jim have never been on a large construction site, I don't know. But on those sites the customer and her staff are face-to-face with the contractor 24/7 for the duration of the job. This is probably conjecture on David and Jim's part and is not true in practice in many domains.
- We built a custom home in Niwot (it's a good way to get a divorce BTW). I visited the site nearly everyday and when I was unable to my wife or her girl friends who had built custom homes did. We knew more about our general contractor's life, children, phobias etc. then we ever wanted to.
- The conjecture that processes and tools override interpersonal interaction is simply not the case in reality.
- Working software over comprehensive documentation - getting to the Certificate of Occupancy or Operating Permit is the goal of any building construction. The CO is not the same as the "as built" drawings. The "as builts" are useful, just as the "Design To" drawings are, but they are not the building, paper mill, interstate, or nuclear remediation site completion.
- Documents play a different role in construction than they do in software. Documents are "material take off" sources. MTO is where the bill of materials comes from, long lead order planning, weight and balance for elevated structures etc. There is no similar paradigm in software unless it is around the performance estimates, security audits, operators manuals, test requirements, build instructions, etc. etc.
- Gee, seems like documents on both domains are done for their value. Which BTW is one of the biggest red herrings of agile. No viable construction firm be it paper mills or manned space flight does documents just for the sake of documents. This is a margin eroding activity and in the modern world is simply not done. Agilest use this as a stalking horse for non-agile processes.
- Responding to change over following a plan - I currently work on a $3.3B spacecraft construction project. We have plans, we change those plans almost every month in some way to deal with the reality of the phsyical progress of the program. There is a "master schedule" that shows on one page, in nice color symbology, the flow of the program. When systems and subsystems come together, when risk reduction flights take place, when our machine will be mated with the launch vehicle, when we'll be docking with the ISS.
- But this master schedule is not an executable plan, it is a "picture" of the program that can be used in conversations about out work. The intermediate and detailed schedules show more detail, dependencies, sequences of deliverables, risk mitigation's, etc.
- But the "real" schedule, the week to week shop floor schedule the subcontractor execution schedules change all the time. They have to change - this is a discovery design project. The last manned spaceflight design was the Shuttle - 25 years ago - so there is no such thing as "following the plan" when you have to invent new physics to solve the problem. Having the plan "guide" you in the discovery of new physics is a better description.
My sense here (and this may sound rude but it is not meant to be) is that David and Jim are missing some understanding of how large construction projects work in the field. Unless you've been on such a project it may be hard to derive the process details from reading about them and replace this knowledge with a conjecture about how they "might" work. This is actually irrelevant though, since their experiences are their own and I'm in no position to challenge their personal opinions. But for the sake of understanding - agile software has many things in common construction.
Looking for this commonality adds important understanding to the construction of software. Ignoring these differences simply narrows one's vision.
