A couple of things came together into a blogpost. Consider is a bricolage that points toward some deep points that I’ll come back to again.

I came across this link on Twitter today : A Simple Cycle

It moves the idea of Demming’s Plan Do Check Act to  the idea of Align-Act in Development

What we do in agile development really comes down to two things. Here’s the pseudocode:

  1. Requesters engage in dialog with responders.
  2. Responders go off and do stuff.
  3. Goto 1.

This sparked against another Tweet

Brooks said further,

“the single hardest part of building a software system is deciding precisely what to build” Brooks

As did Parnas and Clements in the aptly named “A Rational Design Process: How and Why to Fake It

“Determining the detailed requirements may well be the most difficult part of the software design process”

There is no magic bullet to fixing the problem. There are ways to adapt to, and to respond to the problem by learning faster. Fail fast is a nice idea. Learn fast and succeed is better.

Where Software has gone wrong in the past and where we are hopefully learning better e.g. ‘Minimal Viable Product’ is in faster feedback. It’s Align-Act idea again. It’s not that we don’t get the requirements right or we don’t communicate them, it’s that frequently we don’t have the requirements until we have the software.

Alistair Cockburn encapsulates a lot of this in two images I found when looking an old presentation 

 

 

 

The only problem is that if you go back to Royce’s original 1970 paper. The paper that essentially defined the Waterfall development model you’ll see a lot about feedback loops and learning, and no mention of the word Waterfall. Sometimes we don’t really learn very fast at all.