Processes and specifications are ubiquitous, but largely unseen because they are done informally in virtually every organization. Knowledge management research refers to explicit and tacit knowledge, where explicit knowledge is something that's written down and well-defined, while tacit knowledge is something that people just know how to do. Loosely interpreted, explicit knowledge often takes the form of a specification and tacit knowledge often takes the form of a process.
In a previous posting I discussed the specifications and processes used in construction project management. Yesterday, I was discussing the use of processes and specifications with my brother-in-law, who happens to work at a high-end framing shop for those really expensive paintings people buy from galleries. It turns out they have processes and specifications as well, he just didn't realize it because they didn't use any of the terms familiar to engineering, project management, or knowledge management.
This particular framing shop does everything off of a single sheet of paper, and they call it an invoice. At the beginning, the clerk works with the customer to select the framing material, the number, styles, and colors of mats to be applied, what kind of protective layer is involved, and the exact measurements of the work of art. All of this information goes on the invoice, which is an estimate at this point. Each of the craftsmen specializes in one or more of the activities used to construct a frame. Based on the invoice, the mats are selected, cut to size, and trimmed in the pattern described. The framing stock is selected, cut to size, assembled, and any finish work necessary (custom painting, gilding, etc.) is done by the appropriate specialist. A protective layer may be plastic film, acrylic, clear glass or specialty glass and each requires appropriate prep work. Finally, the whole thing is assembled and delivered to the customer. At each stage, the invoice and associated materials are passed from one bench to another and the craftsmen make notes on the invoice about what they did in response to any clarifications solicited and received. Finally, the clerk uses the invoice (which now describes everything that happened) and rings up the final amount at the cash register.
Their invoice is an agile specification. At the beginning, it provides an estimate and a fairly detailed description of what needs to be accomplished. Throughout the process, the invoice is updated to reflect the final design and implementation. At the end, the invoice matches the delivered product and is used to define the final price. Everyone in the shop just "knew" how to use the invoice and what to do at each stage of the process. They just didn't call it a process and a specification. Nor were they familiar with the terms "explicit knowledge" and "tacit knowledge" and any of the other academic jargon used to summarize the real world into abstract concepts. The same is true for just about any industry, from hamburger flipping to convention management. Perhaps this is the reason that Shell Method projects receive such enthusiastic responses from managers and end users; we're following a pattern that people instinctively understand to be successful.
I've come to the conclusion that software engineering needs an agile specification as well. Bits and pieces of agile specifications are not doing the job, and the software engineering profession needs to focus on something workable and appropriate to the small shop and solo developers out there. Heavy, formal processes and specifications are appropriate for large, high-risk projects with deep pockets, but too many projects don't have those deep pockets, and the small/solo developers responsible for those projects don't have the time or funding to put a rigorous process in place, no matter how large a competitive advantage it provides. My feeling is this has to start at the grassroots level, implemented by solo developers and small teams with minimal effort and significant payback. This will not be a "light" version of Shell Method.