Schedule is orthogonal to workflow

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

This is the essential principle that allows Lean development to be something more than Agile.

As a consequence of its minimalism, Scrum paves the way for post-Agile methodology. This might not be too surprising, given that Scrum is the closest to Lean thinking in its origin. Scrum differs somewhat from its Agile peers by refraining from specifying a workflow. It has been customary within the Scrum community to suggest that this workflow should be informal and self-organizing in the Agile tradition, but there’s nothing within Scrum proper that mandates this informality. In fact, there’s really nothing to stop you from using Scrum to schedule a more rigorous workflow like the SEI Personal Software Process.

What Scrum does require is that work requests should be small (a few person-days of effort), stated in terms of customer utility, and that once started, they will be completed to integration and acceptance testing. A fancier way of saying this is that Scrum requires orthogonality of requirements. If work requests must be independent of one another, and also independent of workflow, then we may also say that Scrum makes schedule orthogonal to workflow.

Axiomatic Design demonstrates why orthogonality of requirements is a consequence of an ideal design. That is, regardless of what process was used to produce a design, the ideal outcome of a design process is a system with functionally independent requirements. How convenient is it that an ideal design, by definition, already satisfies the essential constraint for the ideal work scheduling algorithm? Surely this cannot be a coincidence. And in other words, a batch-and-queue phased process buys you absolutely nothing with respect to final design quality, but it does impose deep inefficiencies on your business. Sounds like a great deal.

There is nothing intrinsic to the SEI Team Software Process that requires batching and queuing of requirements. Neither does the V Model. Nor is there any intrinsic batching to most of the Design for Six Sigma techniques. The front end of requirements gathering will often deal in larger chunks, but the ideal output of requirements analysis should produce independently schedulable features. If it doesn’t, then Axiomatic Design is already telling you that you’ve done something wrong.

The Agile movement has given us some big advances, and also some big distractions. The good news is that we are perfectly free to toss out the distractions and substitute something better. In this spirit, Lean Software Engineering will:

  • develop a deep characterization of customer needs, based on close customer interaction and sophisticated modeling tools
  • produce finely grained, formally specified requirements that can be independently scheduled for development
  • follow a rigorous and formal engineering workflow with multiple preventive quality control steps, and planned continuous process improvement
  • collect useful statistics about quality and productivity as an integrated part of everyday work activities
  • continuously integrate new features into a working, stable, secure, and reliable system
  • make those new features available to customers at every appropriate opportunity