I have almost hear you all thinking... What is he talking about? He is crazy!
In order to exaine this premise, we will briefly review each approach from the perspective of OODA loops. For those not familiar with this term, it was coined by Colonel Boyd USAF in the mid 1970's (about the time I started developing software, though it was decades before I learned of it), a good overview can be found on Wikipedia, with links to more authoritive sources. Simply stated, mosthuman activities contain 4 distinct phases:
- Observe: Gather information relevant to the goal.
- Orient: Organize and analyze the observed information in context to determine viable alternatives.
- Decide: Choose a course of action based upon analysis.
- Act: Implement the above decision
True Waterfall has rarely been practiced in many years; in the 30 yearsof Dynamic Concepts existance, we have been involved on only one such project. This is because in the pure form, waterfall prohibits the starting of and phase until the predecessor phase is 100% complete as well as the modification of any previous phase until the entire release cycles hase been performed. For example if the "programming" team discovers an error in the requirements, they will write the code according to the requirement - this code will then go through the QA phase (knowing full well it has an error), and only at the end of the release cycle will there be an opportunity to create new requirements for "Version 2" and the entire cycle repeated.
Even back in the 1960's (the time when many of my early mentors started their own careers), this was rarely done. There would be modifications to the previous step rather than wasting large amounts of time (and time is money) in something that was known to be critically flawed. Since there were no established practices for handling these modifications, and communication between the various parties was often extremely limited this was an "immature" approach, and was most often frought with problems.
From an OODA perspective, waterfall is a series of loops (one per phase) where each loop goes through a single cycle, and the loops are sequentially processed to completion.
CMMI [Capability Maturity Model Integration] was developed to formalize these early attempts at a more iterative approach. By formalizing both the artifact produced and the mechanism for making changes during the process, the huge wastes of a pure waterfall approach going down a known bad path could be reduced or eliminated without introducing the risks of the "ad-hoc" in-flight changes that were happening in the real world.
From an OODA perspective, CMMI maintains the series of loops, but adds a feedback mechanism so that each loop can make additional cycles during the release, rather than requring completion of the entire release before an additional cycle could be performed.
For the purposes of this process topic, we will consider Agile to be any which is based on the Agile Manifesto. In many ways, this was a radical departure from previous approaches; yet it was also born out of the way that software in any small (especially informal) environments was actually being delivered. With the focus returned to the software itself, the formal effort on producing "supporting artifacts" is reduced greatly (but not completely eliminated).
From an OODA perspecitive, Agile eliminates the series of loops in favor of a single loop. It also dramatically reduces the cycle time, since the goal is no longer to "complete" a step in the cycle before proceeding to the next, having been replaced by an approach where "just enough" is done in order to effectively execute meaningful work on the next step. This cycle repeats many times during a single release.
In spite of these significant changes, the actual observations, orientations, decisions and actions (at least as they pertain to the code itself) still need to be done. It is the timing of the elements which has changed. Instead of attempting to complete all observations before starting orientation, a small subset of the total observations occur which allow for the formation of initial orientations.
Since the cycle time is short (remember Col. Boyd's work was focused on reducing the cycle time of OODA loops), the impact of a single cycle is relatively small. This isone of the key benefits, even if a cycle "goes off track" significantly, the overall effect on the project is still managable.
Scrum is properly a simple framework for effective team collaboration on complex projects. It can also be viewed as a specific implementation of the 12 principles which originated with the Agile Manifesto. As a result, the differentiation is the specific set of rules in Scrum, compared to the general philosophical guidelines common to all Agile approaches.
From an OODA perspecitive, there ae only few unique elements to Scrum. Instead of the structural differences that were covered for other approaches, it is the details of HOW to observe, orient, decide and act that are prescribed by Scrum.
As shown above, each approach can be represented as a series of OODA loops. The number of loops, the duration of each loop, and the weight of the artifacts created - all vary significantly. However, if one was to organizethe "leaf elements" for a project done under each of these approaches, the lists would be largely identical. In fact, if one was to repeat this process with multiple independent projects, the differences between projects using the same approach would be significantly larger thant the differences between the lists comparing various approaches on any single project.
It is indeed the timing (and therefore available information) of each element that is the identifying characteristic of each of these approaches. Thus, if one is a Gallifreyan, the various approaches are indeed fundamentally identical.