Strategies for Successful Development

Process and technology for small teams building real software

The No-Spec Spec

Posted by S4SD (Seth Morris) on 2008/09/18

Articles in this series:
     The No-Spec Spec: Overview
     The No-Spec Spec: Fit
     The No-Spec Spec: Identity
     The No-Spec Spec: Purpose
     The No-Spec Spec: Assumptions
     The No-Spec Spec: Environment
     The No-Spec Spec: Capability
     The No-Spec Spec: Behavior


Specifying without a spec

There are a lot of reasons why teams don’t get—or write—good specs: fast-changing product definitions, overloaded product managers, no time in the schedule for technical specifications, lack of training on specifying, communication barriers preventing getting information from other departments, etc. Some groups even eschew specs as inappropriate to agile development (although that actually means they have a too-narrow definition of both "agile" and "specification").

Over the course of training teams to create specifications, I’ve come to a humbling realization: some teams/companies just shouldn’t be writing specs yet. In the CMM parlance, they’re maturity level 0 teams/companies and don’t have the ability to produce an artifact as formal as a spec.

Other teams could, but a senior manager or respected developer whose identity is bound up in being "seat of the pants" or in "cowboy development" keeps the culture from supporting the people trying to implement some minimal process. This is often the case in companies very tied to the "cult of the programmer."

So here’s an alternate approach, based on multiple small artifacts. The main goals are:

  • Severable: The process can be implemented piecemeal, although some pieces are better with others finished as a prerequisite
  • Practicable: Each piece is useful on its own
  • Low-cost: No piece requires extensive time to produce
  • Pervasive: Every discipline, from executive sponsorship down, can be involved under their own initiative
  • Guerrilla-ready: No piece requires significant input from multiple disciplines
  • Produces living documents: Each stage artifact is open to revision and the consequences of that revision are clearly and immediately visible
  • Recursive: the process can be applied to whole projects and recursively re-applied to pieces of the project down to code-level design.
  • Supports a sliding-window:  You only have to specify the pieces you are working on next and can increase the level of detail as information becomes available

The No-Spec Spec is designed around Robert Diltz adaptation of Gregory Bateson’s notion of logical levels. Project artifacts are sorted into logical levels with an eye towards what sets the environment for what. If something fundamental changes, every artifact and decision below it needs to be re-evaluated. Changes don’t often propagate the other way, though, unless the change is due to some out-of-band change that should affect a higher level.

Here are the parts of the No-Spec Spec:

Level Describes…
Fit How the product/project fits with the company’s business

This is not usually included in specs. Making this explicit solves many problems that arise over trade-offs, the importance of functionality, the flexibility of schedules, etc.
 

Identity What the product is in simple language. This forms the core mission of  the project.

This may be included in an MRD, but companies that have trouble producing specs rarely produce MRDs. Those that do produce good MRDs rarely carry their value all the way down to implementation.
 

Purpose The business need/problem the product/project addresses. The value proposition for the project.

This is the user-centered version of Identity (and, to a lesser extent, Fit). This is the place to start talking about use cases and other customer-centric design methodologies that have become standard.
 

Assumptions Assumptions that underlie the project. If any assumptions are invalidated, everything in the project needs to be reexamined.

These should include assumptions about the business environment, competitors, technology, regulatory environment, team and company composition, other projects in the company, and anything else that would require re-examining the project from top to bottom.

There is a close relationship between assumptions and risks, but risks are those things you prepare for and monitor for change. Assumptions are generally completely out of your control and are black or white: they don’t have a risk level, although you may be able to estimate a current risk level that an assumption will be invalidated.
 

Environment What is the environment for the product? Is this for an office? For home? A kiosk in a bar? A PDA? A server product in a Fortune 100 IT room?

What is the hardware and software it is expected to run on (note that this is not the same as hardware requirements, but expected environment)?

What is the user’s experience before using the software? What are they going to do after?
 

Capability The breadth of the project. This includes elements of the product roadmap, the range of applicability (versions, add-ons, integration, etc.)

This is where canceled featured go to resurrect them in a subsequent version. For those of you using SCRUM1, this is not the same as a product backlog. This is for product planning outside the SCRUM process.

1 The project religion of the month when this was written
 

Behavior The main areas of functionality and what they do. This is the place to go into user stories/use cases.

Keep this to a level of detail appropriate to the rest of the artifacts. An Identity document describing a 20-developer, 6-month project as a whole should not be coupled with a Behavior document listing every error screen and log file format. Save that for another set of documents; otherwise, the Behavior artifacts are likely to hold up the rest of the work.
 

In general, change flows downhill and the rate of change increases at each lower level. A change in Fit means the entire project needs to be reexamined. A change in Environment means the capability is likely to change, which will in turn affect Behavior, but an environmental change is unlikely to affect Purpose. If it does, then the project Identity most likely changed without anyone noticing.

If any level is changing faster than the level above it, the project has a serious problem and is likely to fail. If the Assumptions don’t stabilize, you won’t ever get clear Behavior; if the Purpose keeps changing, then the bulk of the project is premature. Track how often these docs rev and note whether they are making major revisions and whether they are making changes in response to another change or if they are spinning their wheels.

Despite the fact that change flows (and grows) downhill, you don’t need—or want—to prepare these in order. Most of these documents capture and explicate existing information. If the executive sponsor doesn’t have time to write a Fit statement, you can and should still go ahead and define your Assumptions, Purpose, Behavior, etc. You will only need to change the other documents if the Fit surprises you—and you should reexamine what you’ve prepared anytime you are surprised by something more fundamental.

I’ll go into each of these levels and give examples in later postings. Let me know what you think.


Listening to: Blood, Sweat & Tears – Greatest Hits – You’ve Made Me So Very Happy

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: