Editor’s note: This is a guest post on Lean Software Development by Corey Ladas. If you don’t know Corey, he’s a product development methodologist. He brings more to the table than most on engineering process because of his background working on integrated mechanical / electrical / software products.  What I like about Corey is his ability to take start of the art and bridge the gap with state of the practice. He has an uncanny ability to boil complex things down into their essence. without further ado, here’s Corey with …

The following is a short list of some of the project practices that have helped me maximize impact, while shipping on time and on budget.

Verification

Dog fooding. Throughout the project, I have the team dog food what we build. See Dog fooding (WIkipedia.)
5 customers. This is an critical check throughout the project that 5 customers stand behind the project. They key is these are 5 customers that actually use the deliverable.

One of the best ways I’ve found to map out a problem space is to create what I call, “Scenario Frames.” I call them scenario frames because they are an organizing frame of scenarios. Simply put, they’re a set of one-liner stories or scenarios organized by categories. The beauty of a scenario frame is that it can contain macro-level or micro-level scenarios and, because it’s a tickler list, it’s easy to traverse.

One of the most effective approaches I’ve found for chunking up a project for incremental value is using a Scenario and Feature Matrix.

Scenarios are Your Rows, Features are Your Columns
A Scenario and Feature Matrix organizes scenarios and features into a simple view. The scenarios are your rows. The features are your columns. You list your scenarios in order of “MUST”, “SHOULD”, and “COULD” (or Pri 1, 2, and 3) .. through vNext. You list your features by cross-cutting and vertical. By cross-cutting, I mean that feature applies to multiple scenarios. By vertical, I mean that feature applies to just one scenario. It helps to think of scenarios in this case as goals customers achieve.

A few folks have asked me about Axiomatic design. I figure an example is a good entry point.

An associate first walked me through axiomatic design like this. You’re designing a faucet where you have one knob for hot and one knob for cold. Why’s it a bad design? He said because each knob controls both temperature and flow. He said a better design is one knob for temperature and one knob for flow. This allows for incremental changes in design because the two requirements (temperature and flow) have their independence. He then showed me a nifty matrix on the board that mathematically *proved* good design.