Pick a road,
before you start driving.
Every project needs a "how are we actually going to build this" answer before anyone writes a line of code. This chapter is the map of every major answer that's ever worked: the rigid, plan-everything-first waterfall, the build-a-bit-learn-a-bit iterative model, the customer-obsessed agile mindset (Scrum, XP, and friends), and DevOps — which stops treating "build it" and "run it" as two different jobs. Same destination, wildly different roads — and the exam wants you to know which road fits which trip.
Process, process model, methodology — three words, three altitudes
Before comparing waterfall to agile, lock in the vocabulary the exam uses to talk about "how a team works."
A collection of work activities, actions, and tasks
Performed whenever some work product is to be created. The raw, ground-level "doing."
An abstract description of a software process
Presents one view of that process — Waterfall, Iterative, Spiral, Evolutionary, etc.
An instantiation of a process model — tends to be prescriptive
The conventions a group agrees to. Literally: "how we work around here."
- Introducing new people to the process
- Substituting people
- Delineating responsibilities
- Demonstrating visible progress — McConnell's definition: "The ease & accuracy with which it is possible to assess the status of a project's cost, schedule, functionality, or other characteristic."
- How rapidly can you substitute or train people?
- How great an effect does it have on the sales process?
- How much freedom (or constraint) does it give the team?
- How fast does it let people respond to changing situations?
- How well does it "protect" the organization legally / from other damages?
PLC vs. SDLC — two concurrent life cycles
IT projects run both, alwaysEvery IT project actually runs two life cycles at once, and the exam loves asking which one covers what.
Encompasses all activities of the project, including the SDLC. Directed toward achieving project requirements (budget, schedule, stakeholders, procurement…).
Directed toward achieving product requirements — the technical build itself.
Three families every process falls into
Before you get to "waterfall vs. agile," the slides sort every process into three top-level buckets.
Ad hoc
No formal process. Includes Code and Fix and Rapid Prototyping.
Prescriptive
Linear/sequential (Classic & Waterfall) · Evolutionary (Iterative/incremental or spiral) · Unified Process.
Adaptive
Lean and Agile methods.
The "traditional" way — and the paper that got misread for 50 years
- Focus on repeatability and predictability
- Defined, standardized, and incrementally improving processes
- Thorough documentation
- A software system architecture defined up-front
- Detailed plans, workflow, roles, responsibilities, and work product descriptions
- A process group containing resources for specialists: monitoring, controlling, educating
- On-going risk management
- Focus on verification and validation
The Royce paper — the origin story students get backwards
1970 · IEEE WESCONThe term waterfall was coined by Winston Royce in a 1970 paper, "Managing the Development of Large Software Systems."
Each phase is marked by completion of deliverables. The expanded lifecycle version labels these: Software Concept → Requirements (Requirements Analysis) → Analysis (Architectural Design) → Design (Detailed Design) → Coding & Debugging (Implementation/Development) → Systems Testing (QA) → Deployment & Maintenance (Production/Operations).
Failure symptoms of a highly-sequential process
- Protracted integration and late design breakage
- Late risk resolution
- Requirements-driven functional decomposition
- Adversarial stakeholder relationships
- Focus on documents and review meetings
Still followed (in name or practice) by many organizations, usually a modified version.
Building with incomplete knowledge, on purpose
An evolutionary methodology follows an iterative and incremental approach that allows the start of development with incomplete, imperfect knowledge.
Advantages of iterative + incremental- Logical progress toward evolving a robust architecture
- Effective management of changing requirements
- Effective means to address changes in planning
- Ability to perform continuous integration
- Early understanding of the system (the "Hello world!" effect)
- Ongoing risk assessment
Evolutionary methodologies are incremental at both the macro (project-scale) and micro (working team) process levels.
Top 5 principles of modern iterative development
non-linear approach- Architecture first — provides the central design element
- Iterative life-cycle process — provides the essential risk management element
- Component-based development — provides the technology element
- Change management environment — provides the control element
- Round-trip engineering — provides the automation element
Get the project off the ground
Formulate product scope (capture requirements and operational concept) · Perform feasibility analysis (resources and technical capability to meet customer needs) · Synthesize the system architecture (evaluate constraints, trade-offs, solutions) · Plan and prepare business case (risk, staffing, iteration plans, cost, infrastructure).
Nail down the architecture
Elaborate the vision (details that drive architectural/planning decisions) · Elaborate the process and infrastructure (construction process/environment established here) · Elaborate the architecture and select reusable (internal or COTS) components — baseline the architecture as quickly as possible and demonstrate it will support the vision at reasonable cost/time.
Build and prove it out
Achieve useful versions (intermediate, alpha, beta, and other test releases) · Perform resource management, control, and process optimization · Complete component development and test · Assess product releases against acceptance criteria.
Get it into customers' hands
Perform deployment-specific engineering tasks (commercial packaging, production, sales kit development, field personnel training) · Assess deployment baselines against complete vision and acceptance criteria (compare what's delivered to what was envisioned) · Plan for the next iteration.
| Waterfall Activity | Waterfall % | Iterative % | Iterative Activity |
|---|---|---|---|
| Management | 5% | 10% | Management |
| Requirements | 5% | 10% | Requirements |
| Design | 10% | 15% | Design |
| Code & Unit Testing | 30% | 25% | Implementation |
| Integration & Test | 40% | 25% | Assessment |
| Deployment | 5% | 5% | Deployment |
| Environment | 5% | 10% | Environment |
| Total | 100% | 100% | Total |
Waterfall dumps 70% of effort into the back half (Code/Unit Test + Integration/Test) — because problems surface late. Iterative spreads risk earlier: more spent on management, requirements, design, and environment up front.
- Clear, stable requirements
- Familiar, proven technology
- Low complexity
- Adequate time, stable schedule
- Reasonably-but-not-perfectly clear requirements
- Unfamiliar or unproven technology
- High complexity
- Short or variable schedule
A mindset first, a method list second
Agile software engineering focuses on delivering functionality quickly, responding to changing product specifications, and minimizing development overheads.
Agile is a blanket term for many approaches
nested, not equalLean is the outermost umbrella. Agile sits inside Lean. And a whole family of named methods sits inside Agile: Scrum, XP, Crystal, FDD, DSDM, AUP, ScrumBan — and Kanban sits under Lean but partly outside strict "Agile."
The exact wording that gets misquoted
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value [the left items]… That is, while there is value in the items on the right, we value the items on the left more." — the Manifesto never says the right-hand items are worthless. See Common Mistakes.
| # | Principle |
|---|---|
| 1 | Highest priority: satisfy the customer through early and continuous delivery of valuable software. |
| 2 | Welcome changing requirements, even late in development. |
| 3 | Deliver working software frequently (weeks, not months — shorter is better). |
| 4 | Business people and developers must work together daily throughout the project. |
| 5 | Build projects around motivated individuals; give them environment/support and trust them. |
| 6 | Face-to-face conversation is the most efficient way to convey information. |
| 7 | Working software is the primary measure of progress. |
| 8 | Agile processes promote sustainable development — a constant pace, indefinitely. |
| 9 | Continuous attention to technical excellence and good design enhances agility. |
| 10 | Simplicity — the art of maximizing the amount of work not done — is essential. |
| 11 | The best architectures, requirements, and designs emerge from self-organizing teams. |
| 12 | At regular intervals, the team reflects on how to become more effective, then tunes and adjusts. |
Involve the customer
Their role: provide & prioritize requirements, evaluate every increment.
Embrace change
Expect features/details to change as the team learns more; adapt the software.
Deliver incrementally
Test & evaluate each increment, feed back required changes.
Maintain simplicity
In the software and the process — eliminate complexity wherever possible.
Focus on people, not things
Trust the team; don't force one uniform process on everyone.
Incremental development — the shared engine under all agile methods
All agile methods are based around incremental development and delivery. You prioritize features so the most important ones are implemented first; only the feature being implemented in an increment gets fully detailed.
- 1. Choose features to be included in an increment
- 2. Refine feature descriptions
- 3. Implement and test
- 4. Integrate feature and test
- 5. Deliver system increment (release if all features complete)
Users or surrogate users try out each increment and feed back to the development team, who then define and implement the next feature. A feature "does something for the software user."
Good practice, pushed to 'extreme' levels
The most influential work that changed software development culture was Extreme Programming (XP). The name was coined by Kent Beck in 1998 because the approach was developed by pushing recognized good practice — like iterative development — to "extreme" levels. XP focused on 12 new development techniques geared to rapid, incremental development, change, and delivery. Some of these are now widely used; others have been less popular.
The XP practice constellationHighlighted chips = the widely adopted practices detailed below.
Incremental planning / user stories
No "grand plan" for the system. What needs to be implemented in each increment is established in discussions with a customer representative, written as user stories. Which stories go into a release is determined by time available and relative priority.
Small releases
The minimal useful set of functionality that provides business value is developed first. Releases are frequent and incrementally add functionality to the previous release.
Test-driven development (TDD)
Developers write the tests before the code — clarifying what the code should actually do and guaranteeing a "tested" version always exists. An automated unit test framework re-runs tests after every change; new code should never break code already implemented.
Continuous integration
As soon as work on a task is complete, it's integrated into the whole system and a new version is created. All unit tests from all developers run automatically and must succeed before the new version is accepted.
Refactoring
Improving the structure, readability, efficiency, and security of a program. All developers refactor as soon as potential code improvements are found — keeping the code simple and maintainable.
A framework for agile organization and planning — no engineering practices included
Software company managers need to know how much a product costs, how long it takes, and when it can reach market. Plan-driven development answers this with long-term deliverable plans — but plans always change, so anything beyond short-term plans is unreliable. Scrum is an agile method that provides a framework for agile project organization and planning. It does not mandate any specific technical practices.
| Term | Definition |
|---|---|
| Scrum | A daily team meeting where progress is reviewed and the day's work is discussed and agreed. |
| Sprint | A short period, typically 2–4 weeks, when a product increment is developed. |
| ScrumMaster | A team coach who guides the team in effective use of Scrum. |
| Product | The software product being developed by the Scrum team. |
| Product owner | Identifies product features/attributes, reviews work done, helps test the product. |
| Product backlog | A to-do list of items (bugs, features, improvements) not yet completed. |
| Development team | A small, self-organizing team of 5–8 people responsible for developing the product. |
| Potentially shippable product increment | The output of a sprint — high enough quality to deploy for customer use. |
| Velocity | An estimate of how much work a team can do in a single sprint. |
Product Owner
Responsible for ensuring the development team stays focused on the product they're building, rather than diverted into technically interesting but less relevant work. In product development, the product manager normally takes on this role.
ScrumMaster
A Scrum expert who guides the team in effective use of Scrum. Not a conventional project manager — a coach, with authority within the team on how Scrum is used. In many companies, the ScrumMaster also holds some project management responsibilities.
Ready for consideration
High-level ideas/feature descriptions. Tentative — may radically change or never make the final product.
Ready for refinement
The team agreed it's important for the current development. Reasonably clear, but still needs work to refine.
Ready for implementation
Enough detail to estimate effort and implement. Dependencies on other items are identified.
The product backlog is continuously reworked through four activities: Refinement (PBI splits into sub-items) · Estimation (sizing effort) · Prioritization (ordering by importance) · Creation (brand new PBIs added).
Key Scrum practices
- Product backlog — reviewed and updated before each sprint.
- Timeboxed sprints — fixed 2–4 week periods implementing backlog items.
- Self-organizing teams — make their own decisions, discuss issues, decide by consensus.
Review product backlog → select items to implement → plan sprint → (Scrum daily meetings +) develop software → test software → review sprint → shippable product increment → back to reviewing the backlog.
Project Management Responsibilities orbit three areas — Reporting (budget, schedule, risks, problems, progress), Administration (finance, compliance, procurement, liaison), and People (vacations, absence, work quality, reviewing, hiring).
| Waterfall | Agile | |
|---|---|---|
| Fixed vs. variable (triple constraint) | Fixed: Scope · Variable: Time, Cost | Fixed: Time, Cost · Variable: Scope |
| Focus | On processes | On people |
| Management | By plans | By changes |
| Development style | Waterfall / long iterations | Incremental, iterative, short iterations |
| Requirements | Planned at the beginning | Updated before every iteration |
| Customer involved | At the beginning and the end | All the time |
| Feedback | Minimal | Frequent |
| Social aspects | Plan and control | Trust, responsibility, motivation |
| Team organization | Hierarchical | Self-organized |
| Leadership | Directing | Coaching |
| Change management | Minimization of changes | Accept and adapt to changes |
| Documentation | Exhaustive | Just enough |
| Communication | Mainly written | Mainly personal |
| Product delivery | As a whole at the end | Frequent, but partial |
Where "building it" and "running it" become one job
The challenge DevOps solves
Agile ↔ IT Operations gapAgile teams push for iterative, incremental progress (fast releases and patches); IT Operations is responsible for infrastructure, deployment, and system reliability (and sends back change requests). When organizations remove the barriers that inhibit collaboration between these two sides, they close the "DevOps gap" — by adopting a collaborative, learning-centric mindset supported by agile practices, and investing heavily in automation. On the dev side, this usually means adopting Continuous Delivery (CD); on the ops side, streamlined and automated operations.
DevOps vs. traditional Project Management
DevOps' fluid, continuous integration/continuous deployment (CI/CD) nature can seem at odds with project management strategies built around fixed timelines, Gantt charts, milestones, and deadlines — that toolkit is more closely aligned with waterfall-style delivery. However, project management styles can adapt to the DevOps pipeline: break work into sprints, focus on iterative progress, embrace change. The key shift is moving focus away from one final product and toward refactoring the timeline to follow incremental deliveries at the end of each sprint.
Collaborative culture
Get leadership on board, align the right people, empower autonomy, share goals & vision.
Embrace the MVP mindset
The simplest version that still meets central requirements — always a deliverable at the end of each sprint.
On-time and quality
Set realistic timelines, monitor defect/rollback rates, embed testing in the pipeline.
Emphasize dependencies
Map them out early, track continuously — beyond just configuration management.
Use tools for heavy lifting
Dashboards, issue trackers, CI/CD platforms as a single source of truth (e.g. Jira ↔ Jenkins).
The role of a DevOps Project Manager
Project managers' roles evolved because of Scrum and other agile approaches. A DevOps PM acts as a bridge between contributors and a tracker of timelines and dependencies — but unlike a traditional PM, they're also technical orchestrators: they need a strong awareness of the development process and the skills required to produce the end product, and they manage the integration, flow, testing, coordination, and deployment of the project.
Traditional setup: developers write code, then hand off to operations to deploy/maintain — that separation breeds miscommunication, delays, finger-pointing. DevOps mindset: dev and ops share goals, tools, and responsibilities from the start. A natural extension of Gantt-chart planning skills: value stream maps, which visualize the whole flow of work from idea to deployment and highlight where value is added or waste/delays occur.
Change isn't just inevitable — it's a catalyst for growth: start with small projects to reduce risk, use the MVP approach, use the right agile planning tools, eliminate silos, reduce project handoffs, create real-time project visibility (shared dashboards), reduce project overhead, and manage change collaboratively with the team.
Where exam answers go wrong
Eight traps this chapter is specifically designed to catch you on.
1. Process vs. Process Model vs. Methodology
2. "Iterative" automatically means "Agile"
3. What Royce's 1970 paper actually argued
4. The Agile Manifesto's "over" statements
5. Scrum vs. Extreme Programming (XP)
6. ScrumMaster = Project Manager
7. "Scrum" the meeting vs. "Sprint" the work period
8. MVP = "cheap, incomplete version"
Click a question to reveal the answer
Quick self-check — separate from the full Practice Lab below.
The whole chapter, one table
| Approach | Category | Best suited for | Key artifact / unit of work |
|---|---|---|---|
| Ad hoc (Code & Fix, Rapid Prototyping) | Ad hoc | Throwaway / exploratory work | — |
| Waterfall / Sequential | Prescriptive | Clear stable requirements, proven tech, low complexity, adequate time | Phase deliverables (Requirements→Design→Construction→QA→Deployment) |
| Evolutionary / Iterative (incl. Unified Process) | Prescriptive | Reasonably clear reqs, unproven tech, high complexity, short/variable schedule | 4-phase cycle: Inception, Elaboration, Construction, Transition |
| XP (Extreme Programming) | Adaptive / Agile | Teams wanting concrete engineering discipline | User story · small release · TDD test |
| Scrum | Adaptive / Agile | Teams wanting planning/organization structure, tech-practice agnostic | Sprint · Product Backlog Item |
| DevOps | Extends Agile | Continuous delivery, frequent production releases | CI/CD pipeline increment |
Scenario → approach, with reasoning
Realistic exam-style scenarios grounded directly in this chapter's decision criteria.