That’s right any approach to software development can and under various circumstances will fail; there are no silver bullets. As discussed in the previous installment, ensuring that goals align and that elements are being executed as intended is key.
But before we can look at specific reasons for each approach, it is critical to ensure that we are all using terms in the same way. The purpose of this installment is to review each of the approaches and establish definitions that will be used for the remainder of the series.
“Waterfall” can be traced back to the 1950’s with a formal definition occurring in 1970. Even in Rice’s 1970 paper, it was identified as a flawed, non-working model. The term is a shortening of “going over a waterfall in a barrel” where there is ZERO opportunity for change once the process has completed until it is entirely complete.
As soon as there is the concept of a Change Order that allows for corrections to decisions or actions taken at a previous point in time, the process is no longer truly Waterfall. Yet people tend to still use the term, despite the fact they are referring to a Heavy Weight Sequential Process [HWSP] that does have some ability to incorporate change over the long term.
“Agile” originated as a Manifesto with 4 value comparisons and 12 principles. The use of the term principle is key since it is defined as “a fundamental truth or proposition”. Thus, if one is not willing to accept even a single principle they are at odds with the manifesto. This is not to pass judgement, but simply the semantics of using the term “Agile” as shorthand for an approach that is in accordance with the manifesto.
The term Agile has been adopted to mean any type of Light Weight Iterative Incremental Process [LWIIP]. Because of the variety of scenarios where the term is applied, it is impossible to give a detailed definition, but there are common traits, such as: A fixed timebox [typically 2-4 weeks] where work is planned, executed and completed. An ordered List of Items of Value that is maintained to provide both timebox and longer term goals. An ability to rapidly respond to change. And, hopefully, at least some consideration of the items from the Manifesto.
At the root, Agile is not something you do, it’s a state of being, mindset, goal; the things mentioned, iterative, timebox, etc. are practices to be agile. One cannot “Do Agile”, despite there being common usage of such phrasing.
“Scrum” is a bit different from the above. The official statement is “Scrum is a framework for developing and sustaining complex products. This definition [of Scrum] consists of Scrum’s roles, events, artifacts, and the rules that bind them together.”. Looking at the definition contained within the Scrum Guide, it is revealed that “Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.”
The distinction between “framework” and “process” is key. While this is discussed explicitly only within the context of Scrum, it is important to realize that neither Agile (either meaning) nor so-called Waterfall are actually processes either. For something to obtain that status of being a process, it must become “a series of actions or steps taken in order to achieve a particular end”. In some cases, these actions and steps are rigorously defined and largely immutable; in other cases, they are more fluid [or even ad-hoc]. Yet, in all cases, to answer the question “what process did you use?” one must be able to identify the specific actions and steps.
We are all Human, and humans will make mistakes. Failure is inevitable, but is also the primary means of learning and progressing. In most cases, failures will come from problems in the tangible processes that are built. But there are also use-cases where the underlying precepts of the approach are not a great match for the desired goals as mentioned in the previous installment.
Next up, a deeper look at Heavy Weight Sequential Processes, and why there are cases where such effort provides value.