What is an Agile Specification?


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 recent blog posting I discussed the specifications and processes used in construction project management. The other day, 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 elicited 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. "Design, then build" is a pattern that people instinctively understand to be successful.


I came 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 analysts 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 analysts 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. Instead, a simple specification that fits with a basic SDLC will give the small/solo analyst the tools needed to succeed with the majority of projects they might encounter. My feeling was this had to start at the grassroots level, implemented by solo developers and small teams with minimal effort and significant payback. And thus was born this Web site.



Instead of generating piles of written documentation, Agile Specifications use pictures and other multimedia elements to convey a software design. Imagine how much text you would have had to grind through to get the same information that the following movie gives you in a few minutes.