Abstract.Since the advent of applying Agile  practices on DoD projects, specifically Scrum  practices, the burning question asked by many has been, “How does Agile integrate with Waterfall  milestones?” Agile development is by definition incremental, meaning major functionality is completed and demonstrated to the customer, users, and other stakeholders at specified releases and through a series of short, scheduled iterations (or sprints). Waterfall projects rely on completing all requirements by the Preliminary Design Review (PDR) milestone, completing all design by the Critical Design Review (CDR) milestone, and completing product development by the Test Readiness Review (TRR) milestone. Some success has been made to abate this issue by breaking the typical waterfall-based milestone reviews into multiple interim reviews enabled by the flexibility in the DoD 5000 acquisition regulation requirements. Interim reviews reflect the iterative nature of Agile as they can be held more frequently and with tighter focus than the traditional days-long milestone reviews. This article presents an approach that uses surveillance points throughout the project lifecycle as the basis for technical interchange meetings (TIMS) each of which includes a demonstration and review of completed functionality that can be deployed as an operational component of the final product. When deployed into the targeted domain, users are encouraged to provide reflections of product usage in the form of feedback to the project team in real time.
Agile Software Development is not a fad, methodology, or process. Rather, Agile  is a mind-set that applies values and principles to the practices implemented by motivated and trained practitioners. The origination of Agile dates back to February 2001, when 17 industry software development experts got together in search of a common ground of software development techniques. After three arduous days of talking, skiing, and relaxing, they created the Manifesto for Agile Software Development . The declaration proclaimed by the manifesto was aimed at restoring balance and credibility, to provide hope of success in the new economy, and to move aggressively into the era of e-business, e-commerce, and the web. The manifesto represented a beacon of light for companies who were burdened with their Dilbert manifestations of make-work and hidden policies that could change their antiquated and wasteful ways.
NOTE: This paper is based on a presentation given by Dick Carlson at the 2012 Software Technology Conference in Salt Lake City, UT.
Domination of the Waterfall Model
The Waterfall Model has been a well-known approach to software development projects for nearly 60 years. In short, the Waterfall Model is a sequential design process where progress flows steadily downwards (as in a waterfall) through Analysis, Design, Construction, Test, and Production phases of a project. The Waterfall Model is attractive to project management because of its distinct and sequential phases, has an appealing air of simplicity, and the use of easily tracked milestones. The Waterfall Model may have been used to build the pyramids, and it continues to work very well when the problem space is very well defined and few or no changes are anticipated. Ambiguity and changes cause turmoil to Waterfall management.
However, the model has some significant drawbacks. For example, development is done in isolation from other important groups; overhead for technical reviews is costly; it aggravates complexity overload and “analysis paralysis”; it pushes many high-risk and difficult elements toward the end of a project; it does not accommodate uncertainty or changing requirements well; it does not yield a working version of the product until late in the process; and it does not contain intrinsic feedback loops. Waterfall milestones assume stable requirements and design early and focus heavily on documentation and formal reviews. Changes in scope typically result in significant impacts to design and construction.
Milestone Reviews and Surveillance Points
To understand why surveillance points are used, a few words need to be said about milestones. Milestones in projects that use the Waterfall Model establish baselines after the approval of a milestone review (see Figure 1).
Baselines typically consist of the customer’s approval of requirements adequacy, design stability, implementation completeness, and test readiness. Approval signifies an endorsement of work completed to that point. Such interchanges are infrequent and costly to both the customer and the contractor. Tremendous effort is expended on preparation of material that involves a significant number of people who are charged with gathering data, and then preparing presentations and other work products that will be reviewed, presented, and discussed during the review. This activity takes time away from doing the work contracted. Milestone reviews can last one day to all week, depending on the importance, complexity, or size of the program.
As a feasible alternative to Waterfall milestones, consider Agile Surveillance Points, which are intervals of the lifecycle where customers, users, and other key stakeholders have opportunities to observe product development progress. On Agile projects, these junctures are the last day of every sprint (a.k.a. iteration) and at the closure of every release, both of which occur frequently throughout a project’s lifecycle.
At the end of each sprint, at Sprint Review is conducted where all stakeholders have an opportunity to observe work that the project team has completed. Completed functionality is demonstrated and other completed work products and how they related to the product capability or performance is mentioned.
The end of each sprint series is followed by a release where the completed functionality of the product being developed, including other relevant work products such as test cases and documentation, are demonstrated within a controlled or simulated environment.
“Wait, There’s More!”
For projects that are required to use the Waterfall model, a project can implement the Agile project management approach, Scrum, to work within the more traditional method. When this approach is used, commonly referred to as a “hybrid” Agile approach, certain release demonstrations and reviews may be planned in advance as formalized releases.
The formal release demonstration/review can be accommodated quite easily through the conduct of technical interchange meetings (TIMs) and used as customer “acceptance points.” where the customer evaluates whether the product is meeting their requirements and is being developed according to their expectations. The customer may also evaluate whether the project team is making sufficient progress to the schedule and ultimately determine if the project team should continue working according to plan, or make adjustments or corrections prior to proceeding any further. (See Figure 2.)
The number of formal demonstrations/reviews must be agreed upon by the customer and the project team. Formal demonstrations or reviews targeted to be formal in nature must be documented and scheduled with customer approval. During the project planning phase (otherwise known as Sprint 0, entry criteria for every planned formal demonstration or review must be established and well-understood by all.
Light at the End of the Tunnel
To put things into perspective, at the start of every release cycle or after approval of the project or next stage of the project, the Product Owner (the project visionary) and others discuss and plan a solid release strategy. From the project’s Product Roadmap, features and functionality that address the customer’s real needs and value are decomposed into smaller chunks to enable the team to more accurately plan the most important work first. Such items are listed in prioritized order in the Product Backlog. Priority of items must be customer-driven to maximize business value. At this point, the team provides gross or high-level estimates to determine scope and project duration.
From this point onward and upon the start of the project, the stakeholder’s surveillance of the product’s development and progress is highly encouraged. In a technical paper published by the Software Engineering Institute , it was suggested that surveillance in the form of formal reviews such as preliminary and critical design reviews (e.g. PDR and CDR) be reformatted into interim design reviews.
Interim design reviews provide opportunities for key project stakeholders to observe product development progress through more frequent and active participation than that of the traditional PDRs and CDRs that is costly in preparation and travel and involves more people than necessary.
The use of surveillance points on Agile projects enables project stakeholders to observe product development from sprint to sprint and release to release. Milestones in projects that use the Waterfall Model establish baselines after the approval of a milestone review. The Waterfall Model is attractive to project management because of its distinct and sequential phases, has an appealing air of simplicity, and the use of easily tracked milestones. Agile Surveillance Points are intervals of the lifecycle where customers, users, and other key stakeholders have opportunities to observe product development progress.
For projects that are required to use the Waterfall model, a project can implement the Agile project management approach, Scrum, to work within the more traditional method. When this approach, commonly referred to as a “hybrid” Agile approach is used, certain release demonstrations and reviews may be planned in advance as formalized releases. Interim design reviews provide opportunities for key project stakeholders to observe product development progress through more frequent and active participation than that of the traditional PDRs and CDRs that is costly in preparation and can involve more people than necessary.
References and Notes
5. Software Engineering Institute Technical Note, CMU/SEI-2010-TN-002
Dick Carlson has an extensive engineering background that includes many years of practical knowledge and hands-on experience in the implementation and deployment of Agile, Lean, and Scrum values and principles in communications-electronics, and software and systems engineering within the aerospace, DoD, IT, and industry domains. He has developed and actively conducted comprehensive training courses for Scrum Teams, Scrum Masters, Product Owners, project/program managers, customers, executives, organizational leaders, and others interested in learning how to implement and deploy Agile, Lean, and Scrum. Mr. Carlson has a Bachelor of Science degree in Business and Management from the University of Maryland, and is a Certified Scrum Professional, Certified Scrum Master, and Certified Scrum Product Owner.
Agile & Lean Education Associates (ALEA)
« Previous Next »