The Two Rules Of Software Creation From Which Every Problem Derives

Scrum has been having a bad time for the last ten years, and thus so has Agile. My favorite article on this is truly exhaustive about all the problems we have encountered in the last two decades trying to deliver software of any kind using these methodologies. (I know nothing about the writer, this could totally be a Milkshake Duck experience; some algorithm just recommended this insanely long post to me one day and I went “Uh huh. Uh huh. Uh huh. Uncharitable but I can see where they are coming from. Baby and bathwater but yeah. Uh huh.” It’s been on my open tabs for 4 months now waiting for me to write this.)

Thing is, I remember the before times. Waterfall, short or long. I delivered projects in those systems. In fact, the first time I encountered Agile in a company, I was new and young and thus stupid enough to not ask what that was about and thus very confused until I looked up where it came from. I remained very confused how you get from the statements in the Agile manifesto (seriously, check them out again) to the rituals of Scrum like stand-ups, retros, pointing and everything else that makes programmers so angry they only get to program 50% of their day and have to talk to other people otherwise, until I actually did some work in Agile Scrum and understood what it was trying to do.

None of the critics are offering real alternatives, just modifications of Scrum to fit Design or Product management in. I don’t think anyone wants to go back to Waterfall, but they can’t really explain why not.

I can. With two rules (which may become more as we discuss them).

It’s the two rules that actually are behind every statement in the agile manifesto. The manifesto unfortunately doesn’t name them really; the people behind it were so steeped in the problems of software delivery—and what they thought would fix it—that they posited their statements without saying why each of these things are necessary to deliver good software. (Unfortunately, necessary but not enough for success, but that we found out in the next decades.)

They are

1. Humans can not accurately describe what they want out of a software system until it exists.
   
2. Humans can not accurately predict how long any software effort will take beyond four weeks. And after 2 weeks it is already dicey.

That’s it. Every other problem that you have to solve in software delivery rolls out of these two major issues, I think. I may be wrong, you may need a third or fourth.

Am I going to spend time proving these two correct? No. There’s enough literature out there, most of it documenting failed software efforts in Waterfall in the 60s, 70s, 80s, 90s, to support them, and I am not going to go over that. What I will, in the next few days, is go over their implications, how they led to current Agile practices, and how they can not be ignored when you want to make things better.