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:
- Requesters engage in dialog with responders.
- Responders go off and do stuff.
- Goto 1.
This sparked against another Tweet
‘Much of the essence of building a program is in fact the debugging of the specification.’ — Fred Brooks
— Computer Science(@CompSciFact) January 11, 2013
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.