UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 3.2 Free with a free account
Blending Agile with the Systems Development Life Cycle
System Analysis and Design · Chapter 3: Agile Methods and Rapid DevelopmentSection 3.2 · lesson 16 of 698 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of System Analysis and Design.
Lesson complete
Earn the 3 college credits for System Analysis and Design
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Agile vs. Traditional SDLC: A Side-by-Side Comparison →← Agile Thinking: Core Definitions, Concepts, and StepsNext lesson: Agile vs. Traditional SDLC: A Side-by-Side Comparison →
In this lesson
Water-Scrum-Fall, sprint-shaped phases, relocated gates, and scaled agile.
- Explain the Water-Scrum-Fall hybrid, and why organizations adopt it
- Map the 5 life-cycle phases onto sprint-based delivery
- Identify where documentation and phase gates still fit
- Describe how SAFe coordinates many agile teams on one system
Transcript
Everything said in the video, section by section (1,200 words). Read along, or search it.
Agile Methods and Rapid Development
Blending Agile with the Life Cycle
The last section introduced agile methods on their own terms. But very few organizations run a purely agile process, from end to end. And very few run a purely linear one either. This section is about what most organizations actually do. They blend the two. We will look at the most common hybrid, how the life-cycle phases change shape inside it, where the gates and documents go, and how agile scales to many teams.
The Hybrid Reality
Few Organizations Are Purely Linear or Purely Agile
Most organizations settle into a hybrid approach. It blends structured, up-front planning, iterative delivery in the middle, and a more formal release process at the back end. The most widely used name for this pattern is Water-Scrum-Fall. Water stands for the linear, document-driven front end. Scrum stands for the iterative, sprint-based middle. And Fall stands for the linear, gate-driven back end, where the system is integrated, formally tested, and released. Picture a straight line going in, a loop of sprints in the middle, and a straight line coming out. The loop in the middle can repeat as many times as the work needs. The straight segments on either side happen once.
Why Hybrids Exist
2 Fixed Points, Flexibility Between
Why do organizations end up here? For practical reasons, rather than out of a preference for one model over another. At the front end, contracts and budgets often need to be approved before any work starts. That favors an up-front planning stage. At the back end, regulated industries and enterprise release processes often require formal test evidence and sign-off before anything reaches production. That favors a structured back end. Between those two fixed points, though, building the system benefits from the fast feedback and course-correction that sprints provide. So the hybrid is not a compromise born of confusion. Each segment answers a real constraint.
The 3 Segments
What Happens in Each
Let's look at what happens in each segment. The water segment, at the front end, is linear. It covers high-level requirements, budgeting and contracting, and initial architecture decisions. The scrum segment, in the middle, is iterative. It runs sprints that each produce a working, tested increment, with ongoing backlog refinement. The fall segment, at the back end, is linear again. It covers formal system and regression testing, compliance sign-off, and staged deployment. Notice that the middle is the only segment built to absorb change quickly. The two ends are built for approval and evidence instead.
Phases, Reshaped
Mapping the 5 Phases onto Sprints
Blending an iterative middle into the life cycle does not remove any of the five phases. It changes how each one is shaped. Planning is still largely completed up front. The project charter, feasibility, and an initial budget are typically approved before the first sprint begins. Analysis becomes distributed across sprints. Each sprint begins by refining and analyzing the slice of the backlog it will build, rather than the whole system at once. Design is also distributed. Each sprint does just enough design for the stories being built that sprint. This is sometimes called just-in-time design. Implementation is spread across every sprint. Each sprint is expected to produce a tested, potentially shippable increment, rather than one long build at the end. And maintenance begins as soon as an increment is released, often running in parallel with sprints still building new features. So every phase from chapter one is still here. What changed is its rhythm, not its existence.
Gates, Relocated
Phase Gates Resized, Not Removed
What happens to the phase gates covered earlier in the course? A hybrid approach does not eliminate them. It relocates them, and resizes them. A lightweight gate happens at the end of every sprint. It usually takes the form of a sprint review. Stakeholders see the working increment, and either accept it, or send specific items back for rework. The larger, more formal gates still exist too. These are the ones that require a signed requirements document, or a complete test report. But they cluster at the boundaries. Once before the first sprint, and again before the system moves from the scrum segment into the fall segment. In effect, a hybrid trades a few very large gates for many small ones, plus a couple of large ones at the edges. The small gates catch problems while they are cheap, one sprint at a time.
Documentation, Relocated
Living Documents, Finalized Late
Documentation follows the same pattern. A single, exhaustive requirements document, produced before any development starts, is rare in a hybrid approach. Instead, a living backlog and lightweight design notes are updated continuously, as sprints proceed. Formal documentation required for compliance or audit is still produced. But it is usually assembled and finalized at the back end, once the increments it describes have been built and tested. So the timeline looks like this. The project charter and feasibility sign-off happen at the front end, before sprint one. Sprint review and demo approval happen at the end of every sprint. Release readiness and formal test sign-off happen at the back end, before a major release. And the compliance or audit package is updated continuously, but formally finalized at the back end.
Scaling Up
When One Team Is Not Enough
So far, we have pictured a single team. A single team's sprints work well when one team can build the whole system. On a large system, several teams typically build interdependent parts at the same time. Their sprints need to stay synchronized with each other, and with the organization's broader priorities. Scaled frameworks exist to coordinate that larger picture. The best known is the Scaled Agile Framework, or SAFe. And crucially, it does this without asking each team to give up its own sprint cadence. Without that coordination, each team could succeed on its own, while the parts still failed to fit together.
SAFe
3 Layers of Coordination
SAFe organizes work into layers above the individual team. At the team layer, one agile team runs its own sprints and backlog. At the program layer, multiple teams building toward a shared release are grouped into an Agile Release Train. The release train plans and releases on a common cadence, known as a Program Increment. At the portfolio layer, the organization sets overall investment priorities and strategic themes, across multiple release trains. And each layer keeps a form of the gate structure we discussed. A release train still has its own planning and review checkpoints, just at a larger scale than a single team's sprint.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. Water-Scrum-Fall is a hybrid, with a linear front end, iterative sprints in the middle, and a linear back end. Just-in-time design means doing just enough design for the stories being built in the current sprint. A sprint review is the lightweight end-of-sprint gate, where stakeholders accept work or send items back. SAFe, the Scaled Agile Framework, coordinates many agile teams working on one system. And an Agile Release Train groups teams building toward a shared release, on a common Program Increment cadence.
Key Takeaways
What to Carry Forward
To pull this together. Water-Scrum-Fall blends a linear front end and back end around an iterative, sprint-based middle. Analysis, design, and implementation still happen in a hybrid model. But they happen in small slices, repeated every sprint, rather than as one long phase each. Phase gates and formal documentation are not removed. Lightweight gates run every sprint, and the larger formal gates cluster at the front and back boundaries. And scaled frameworks such as SAFe coordinate multiple agile teams and their release cadence, without removing each team's own sprints.
About System Analysis and Design at UPI Study
System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take System Analysis and Design with UPI Study
Where the credit goes
Universities that work with NCCRS
System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Blending Agile with the Systems Development Life Cycle
What is Water-Scrum-Fall?
How do the SDLC phases change when agile sprints are used?
Do phase gates and documentation still exist in a hybrid agile project?
What is SAFe, and how does it coordinate multiple agile teams?
About the System Analysis and Design course
How many college credits is System Analysis and Design?
How much does System Analysis and Design cost and what is included?
Which universities accept UPI Study credits?
How long does System Analysis and Design take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in System Analysis and Design.
69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →