In Scrum Training, I started touching on the difference between the “Waterfall” method of project tracking (Defined Process Control) vs. Empirical Process Control. At the root of the Waterfall system is the idea that for the same inputs into a system, I can expect the same outputs and that the work ahead of us is well defined and known. In software, that usually is not the case, as we really don’t know that what we have built is what the customer wants until they can “experience” it in the way of working software. The other idea with Scrum is that we focus on getting the teams so disciplined in the logistics of shipping software, that is no longer the pain point or hold up in the process, we can ship software when we want (which to me is the definition of “Agile”).
It is easy to get caught up in the “logistics” of a process and just focus on the mechanics, I think this article by Barry Hawkins does a great job conveying more of the “why” behind Scrum. If we can focus on the ideas and principles of the process, we can use that as leverage to get better instead of saying “these are the ceremonies in Scrum, go do them”.
There is another article that brings good insight into how people have turned waterfall into something it wasn’t originally intended. I bring this up as I regularly speak to University students regarding Software Development approaches (typically traditional SDLC is the first process they learn). They were in awe of the article I show on Dr. Royce’s “Managing the Devleopment of Large Systems“. Fig 3 of the Waterfall process shows iterations are recommended. He describes the traditional SDLC model in Fig 2 inviting risk and failure. Dr. Royce’s paper is great and offers a great perspective on a big problem we were trying to solve in the 70’s. We also seem to always be in a rush and sometimes miss what an article was trying to convey. Thus began a formal process that the government originally initiated to help “control” projects.
To sum this up, I love the diagram below (provided by Ralph Stacey). When people ask “when should we use Scrum”?, I display this diagram and say, “anything past Simple are best suited for Scrum” (although I would still use Scrum on the simple ones as well). If any process involves humans and creativity, it is automatically a “complex” project in my humble opinion.