24.3 WAgile hybrid approach¶

Why it matters¶

WAgile methodology combines the structured governance of waterfall with the adaptive flexibility of agile development. This hybrid approach addresses real-world project constraints where organisations need both predictable milestones and the ability to respond to changing requirements. Understanding WAgile helps software engineers work effectively in environments that require formal approvals while maintaining development agility.

Concepts¶

Understanding the WAgile hybrid model¶

WAgile (Waterfall + Agile) is a hybrid methodology that structures projects using traditional waterfall stage gates while conducting development work using agile iterations within each stage.

Key characteristics of WAgile:

Stage gates provide governance: Major decision points with formal approval processes
Agile iterations within stages: Short development cycles that allow adaptation
Hybrid documentation: Mix of upfront planning and just-in-time documentation
Flexible scope within constraints: Can adapt features while meeting stage objectives

prototypingand design validationAgile developmentsprints with regulardeliverablesRequirementsApprovedDesignApproved

Stage gates and governance¶

Stage gates are formal checkpoints where project progress is reviewed and approval is given to proceed to the next phase. They provide organisational oversight and risk management.

Typical stage gate components:

Deliverable review: Assessment of completed work against criteria
Quality gates: Technical and business quality standards verification
Resource approval: Budget and personnel allocation for next stage
Risk assessment: Evaluation of project risks and mitigation strategies

Gate Criteria ExamplesPython Gate Tracker

Gate 1: Requirements Approval

✓ Stakeholder needs documented and validated
✓ Functional and non-functional requirements defined
✓ Success criteria and acceptance tests specified
✓ Project scope and boundaries agreed
✓ Initial architecture and technology approach approved

Gate 2: Design Approval

✓ System architecture documented and reviewed
✓ User interface designs validated with stakeholders
✓ Data model and integration points defined
✓ Development approach and tooling selected
✓ Testing strategy and environment plan approved

Gate 3: Implementation Approval

✓ Core functionality demonstrated and tested
✓ Performance requirements validated
✓ Security review completed
✓ Deployment plan documented and approved
✓ User training materials prepared

from datetime import date
from enum import Enum

class GateStatus(Enum):
    PENDING = "pending"
    IN_REVIEW = "in_review"
    APPROVED = "approved"
    REJECTED = "rejected"

class GateCriteria:
    def __init__(self, description, weight=1):
        self.description = description
        self.weight = weight
        self.status = "not_started"
        self.evidence = None
        self.reviewer_notes = ""

    def mark_complete(self, evidence, notes=""):
        self.status = "complete"
        self.evidence = evidence
        self.reviewer_notes = notes

class StageGate:
    def __init__(self, name, gate_number):
        self.name = name
        self.gate_number = gate_number
        self.criteria = []
        self.status = GateStatus.PENDING
        self.review_date = None
        self.approval_date = None
        self.reviewer_feedback = []

    def add_criteria(self, criteria):
        self.criteria.append(criteria)

    def get_completion_percentage(self):
        if not self.criteria:
            return 0
        completed = sum(1 for c in self.criteria if c.status == "complete")
        return (completed / len(self.criteria)) * 100

    def is_ready_for_review(self):
        return self.get_completion_percentage() == 100

    def submit_for_review(self):
        if self.is_ready_for_review():
            self.status = GateStatus.IN_REVIEW
            self.review_date = date.today()
            return True
        return False

    def approve_gate(self, feedback=""):
        self.status = GateStatus.APPROVED
        self.approval_date = date.today()
        if feedback:
            self.reviewer_feedback.append(feedback)

    def gate_summary(self):
        completion = self.get_completion_percentage()
        return f"Gate {self.gate_number} ({self.name}): {completion:.1f}% complete, Status: {self.status.value}"

## Example: Requirements Gate

req_gate = StageGate("Requirements Approval", 1)
req_gate.add_criteria(GateCriteria("Stakeholder needs documented"))
req_gate.add_criteria(GateCriteria("Functional requirements defined"))
req_gate.add_criteria(GateCriteria("Non-functional requirements specified"))
req_gate.add_criteria(GateCriteria("Acceptance criteria documented"))

## Mark some criteria as complete

req_gate.criteria[0].mark_complete("Stakeholder interview notes and user personas", "Well documented")
req_gate.criteria[1].mark_complete("Functional requirements document v1.2", "Comprehensive coverage")

print(req_gate.gate_summary())
print(f"Ready for review: {req_gate.is_ready_for_review()}")

Iterative delivery within stages¶

Within each waterfall stage, agile iterations allow teams to refine work progressively and respond to feedback without compromising the overall project structure.

Benefits of iterative delivery in WAgile:

Progressive refinement: Each iteration improves on previous work
Early feedback: Stakeholders can see progress and provide input
Risk reduction: Problems are identified and addressed quickly
Quality improvement: Multiple review cycles enhance deliverable quality

Requirements Stage IterationsPython Iteration Tracker

Sprint 1: Initial Requirements Gathering

Stakeholder interviews and workshops
High-level user stories and epic creation
Initial scope definition and boundaries

Sprint 2: Requirements Refinement

Detailed user story breakdown
Acceptance criteria definition
Non-functional requirements specification

Sprint 3: Requirements Validation

Stakeholder review and feedback incorporation
Requirements traceability matrix creation
Final requirements document preparation

from datetime import date, timedelta

class Iteration:
    def __init__(self, number, stage_name, duration_weeks=2):
        self.number = number
        self.stage_name = stage_name
        self.duration_weeks = duration_weeks
        self.start_date = None
        self.end_date = None
        self.objectives = []
        self.deliverables = []
        self.feedback_items = []
        self.completed = False

    def start_iteration(self, start_date, objectives):
        self.start_date = start_date
        self.end_date = start_date + timedelta(weeks=self.duration_weeks)
        self.objectives = objectives
        print(f"Started {self.stage_name} Iteration {self.number}: {start_date} to {self.end_date}")

    def add_deliverable(self, deliverable, completion_date=None):
        item = {
            "name": deliverable,
            "completion_date": completion_date or date.today(),
            "status": "complete" if completion_date else "in_progress"
        }
        self.deliverables.append(item)

    def collect_feedback(self, feedback, source, priority="medium"):
        feedback_item = {
            "feedback": feedback,
            "source": source,
            "priority": priority,
            "date": date.today(),
            "addressed": False
        }
        self.feedback_items.append(feedback_item)

    def complete_iteration(self):
        self.completed = True
        print(f"Completed {self.stage_name} Iteration {self.number}")

    def iteration_summary(self):
        deliverable_count = len([d for d in self.deliverables if d["status"] == "complete"])
        feedback_count = len(self.feedback_items)
        unaddressed_feedback = len([f for f in self.feedback_items if not f["addressed"]])

        summary = f"{self.stage_name} Iteration {self.number}:\\n"
        summary += f"  Deliverables completed: {deliverable_count}\\n"
        summary += f"  Feedback items: {feedback_count} (unaddressed: {unaddressed_feedback})\\n"
        summary += f"  Status: {'Complete' if self.completed else 'In Progress'}"
        return summary

## Example: Requirements stage iterations

req_iteration_1 = Iteration(1, "Requirements")
req_iteration_1.start_iteration(
    date(2025, 10, 1), 
    ["Stakeholder interviews", "Initial user stories", "Scope definition"]
)
req_iteration_1.add_deliverable("Stakeholder interview notes")
req_iteration_1.add_deliverable("High-level user story list")
req_iteration_1.collect_feedback("Need more detail on user roles", "Product Owner", "high")
req_iteration_1.complete_iteration()

print(req_iteration_1.iteration_summary())

When and how to apply WAgile interventions¶

WAgile interventions involve deciding when to apply waterfall structure versus agile flexibility based on project context and organisational needs.

Decision factors for WAgile interventions:

Regulatory requirements: Compliance needs may require formal documentation
Stakeholder expectations: Some organisations expect traditional project milestones
Risk tolerance: High-risk projects may need more governance checkpoints
Team experience: Less experienced teams may benefit from structured phases

Intervention GuidelinesPython Decision Framework

Apply Waterfall Elements When:

Regulatory compliance requires formal documentation
Budget approval processes need predictable milestones
Integration with legacy systems requires detailed planning
Stakeholders need formal progress reporting
Risk of scope creep is high

Apply Agile Elements When:

Requirements are likely to change during development
User feedback is essential for success
Technology choices may evolve during project
Team needs flexibility to respond to blockers
Innovation and experimentation are valued

Hybrid Approaches Work Best When:

Organisation values both governance and agility
Projects have mixed requirements (some stable, some evolving)
Multiple stakeholder groups with different expectations
Need to balance innovation with risk management

class ProjectCharacteristics:
    def __init__(self):
        self.regulatory_requirements = False
        self.budget_constraints = False
        self.changing_requirements = False
        self.stakeholder_diversity = False
        self.technical_uncertainty = False
        self.team_experience_level = "medium"  # low, medium, high
        self.risk_tolerance = "medium"  # low, medium, high

    def recommend_approach(self):
        waterfall_score = 0
        agile_score = 0

        ## Score waterfall factors

        if self.regulatory_requirements:
            waterfall_score += 3
        if self.budget_constraints:
            waterfall_score += 2
        if self.team_experience_level == "low":
            waterfall_score += 2
        if self.risk_tolerance == "low":
            waterfall_score += 2

        ## Score agile factors

        if self.changing_requirements:
            agile_score += 3
        if self.technical_uncertainty:
            agile_score += 2
        if self.stakeholder_diversity:
            agile_score += 1
        if self.team_experience_level == "high":
            agile_score += 1

        ## Determine recommendation

        if abs(waterfall_score - agile_score) <= 1:
            return "WAgile hybrid approach recommended"
        elif waterfall_score > agile_score:
            return "Waterfall-heavy WAgile (more stage gates, longer iterations)"
        else:
            return "Agile-heavy WAgile (fewer gates, shorter iterations)"

## Example project assessment

project = ProjectCharacteristics()
project.regulatory_requirements = True
project.changing_requirements = True
project.stakeholder_diversity = True
project.technical_uncertainty = False
project.team_experience_level = "medium"
project.risk_tolerance = "low"

recommendation = project.recommend_approach()
print(f"Methodology recommendation: {recommendation}")

Scale and development type considerations¶

WAgile methodology must be adapted based on project scale, team size, and the type of software being developed.

Scaling considerations:

Small teams (2-8 people): Lightweight stage gates, informal reviews
Medium teams (9-20 people): Structured gates, regular cross-team coordination
Large teams (20+ people): Formal gates, extensive documentation, program management
Enterprise scale: Multiple projects, portfolio-level governance, standardised processes

Scale AdaptationsPython Scale Calculator

Small Team WAgile:

2-3 stage gates maximum
Sprint reviews serve as mini-gates
Lightweight documentation focused on decisions
Single product owner and scrum master

Enterprise WAgile:

4-6 formal stage gates with executive review
Program-level coordination across multiple teams
Extensive documentation for compliance and handoffs
Multiple product owners with coordination mechanisms

Risk Profile Adaptations:

Low risk: Fewer gates, longer iterations, informal reviews
Medium risk: Standard gates, 2-week iterations, structured reviews
High risk: Additional gates, shorter iterations, extensive validation

class ProjectScale:
    def __init__(self, team_size, duration_months, budget, complexity):
        self.team_size = team_size
        self.duration_months = duration_months
        self.budget = budget
        self.complexity = complexity  # low, medium, high

    def calculate_scale_category(self):
        scale_points = 0

        ## Team size scoring

        if self.team_size <= 8:
            scale_points += 1
        elif self.team_size <= 20:
            scale_points += 2
        else:
            scale_points += 3

        ## Duration scoring

        if self.duration_months <= 6:
            scale_points += 1
        elif self.duration_months <= 12:
            scale_points += 2
        else:
            scale_points += 3

        ## Complexity scoring

        complexity_map = {"low": 1, "medium": 2, "high": 3}
        scale_points += complexity_map.get(self.complexity, 2)

        ## Categorise scale

        if scale_points <= 4:
            return "Small Scale"
        elif scale_points <= 7:
            return "Medium Scale"
        else:
            return "Large Scale"

    def recommend_wagile_structure(self):
        scale = self.calculate_scale_category()

        if scale == "Small Scale":
            return {
                "stage_gates": 2,
                "iteration_length": "2-3 weeks",
                "documentation": "Lightweight",
                "governance": "Team-level decisions"
            }
        elif scale == "Medium Scale":
            return {
                "stage_gates": 3,
                "iteration_length": "2 weeks",
                "documentation": "Structured",
                "governance": "Management review"
            }
        else:
            return {
                "stage_gates": 4,
                "iteration_length": "1-2 weeks",
                "documentation": "Comprehensive",
                "governance": "Executive oversight"
            }

## Example project scaling

project = ProjectScale(
    team_size=12,
    duration_months=8,
    budget=500000,
    complexity="medium"
)

scale = project.calculate_scale_category()
structure = project.recommend_wagile_structure()

print(f"Project scale: {scale}")
print(f"Recommended WAgile structure:")
for key, value in structure.items():
    print(f"  {key}: {value}")

Practice¶

Exercise 1: WAgile project design¶

Exercise 1: Design a Hybrid Approach

Scenario: A government department is developing a new citizen services portal. The project has the following characteristics:

Team size: 15 developers, 3 testers, 2 business analysts
Duration: 18 months
Budget: $2.5 million (fixed)
Compliance: Must meet government accessibility and security standards
Stakeholders: Citizens, department staff, IT security team, executive leadership
Requirements: Some are well-defined (security), others will evolve (user interface)

Tasks:

Design a WAgile approach for this project
Define the stage gates and their criteria
Plan how agile iterations will work within each stage
Identify where waterfall and agile elements are most appropriate

Sample Solution

WAgile Project Design for Citizen Services Portal:

Overall Structure (Large scale project):

4 major stage gates over 18 months
2-week agile iterations within each stage
Formal governance with executive oversight

Stage Gates and Criteria:

Gate 1: Requirements and Compliance Approval (Month 3)

✓ User needs assessment completed
✓ Security requirements defined and approved
✓ Accessibility standards compliance plan
✓ Integration requirements with existing systems
✓ Initial architecture and technology selection

Gate 2: Design and Security Approval (Month 6)

✓ System architecture passed security review
✓ User interface designs validated with citizen focus groups
✓ Data protection impact assessment completed
✓ Development environment and CI/CD pipeline established
✓ Testing strategy approved

Gate 3: Core Implementation Approval (Month 12)

✓ Core functionality developed and tested
✓ Security penetration testing completed
✓ Accessibility testing passed
✓ Performance benchmarks met
✓ User acceptance testing begun

Gate 4: Production Readiness Approval (Month 16)

✓ Full system integration completed
✓ Production deployment procedures tested
✓ Staff training materials completed
✓ Disaster recovery procedures validated
✓ Go-live plan approved

Agile Iterations Within Stages:

Months 1-3 (Requirements Stage):

Sprint 1: Stakeholder interviews and current state analysis
Sprint 2: User journey mapping and requirements gathering
Sprint 3: Compliance requirements research and documentation
Sprint 4: Requirements validation and prioritisation
Sprint 5: Architecture planning and technology evaluation

Months 4-6 (Design Stage):

Sprint 6: High-level system design and security architecture
Sprint 7: User interface wireframes and prototypes
Sprint 8: Data model and API design
Sprint 9: Design validation with focus groups
Sprint 10: Security review and compliance validation

Waterfall Elements Applied:

Security and compliance requirements (heavily regulated)
Budget approval and milestone reporting
Integration with existing government systems
Executive oversight and governance

Agile Elements Applied:

User interface design (needs citizen feedback)
Feature prioritisation based on user testing
Technical implementation and testing
Iterative refinement based on stakeholder feedback

Risk Mitigation:

Early security reviews prevent late-stage rework
Citizen feedback incorporated through agile iterations
Fixed compliance checkpoints ensure regulatory adherence
Regular stakeholder demos maintain engagement

Exercise 2: Intervention decision framework¶

Exercise 2: When to Apply Waterfall vs Agile

Scenario: You’re managing a school management system with the following components:

Student Records Module: Stores grades, attendance, personal information
Timetabling System: Manages class schedules and room bookings
Parent Portal: Allows parents to view student progress
Mobile App: Student access to schedules and notifications
Reporting Dashboard: Administrative reports and analytics

Constraints:

Must integrate with existing government student information system
Privacy legislation requires specific data handling procedures
Parents and students want modern, intuitive interfaces
School administrators have traditional preferences
12-month timeline with fixed budget

Tasks:

For each component, decide whether to use more waterfall or agile approach
Justify your decisions based on risk, compliance, and stakeholder needs
Design the overall project flow showing how components will be developed
Identify integration points where coordination is critical

Sample Solution

Component-by-Component Analysis:

1. Student Records Module → Waterfall-Heavy

Rationale: High compliance requirements, integration with government systems
Approach: Detailed upfront design, formal security review, extensive testing
Documentation: Comprehensive data mapping, security procedures, audit trails

2. Timetabling System → Waterfall-Heavy

Rationale: Complex business rules, integration with multiple systems
Approach: Algorithm design phase, constraint validation, structured testing
Documentation: Business rules specification, integration requirements

3. Parent Portal → Agile-Heavy

Rationale: User experience critical, requirements may evolve with feedback
Approach: Rapid prototyping, user testing iterations, incremental features
Documentation: User stories, design iterations, feedback incorporation

4. Mobile App → Agile-Heavy

Rationale: Student preferences, technology platform changes, usability focus
Approach: MVP development, student feedback cycles, feature iterations
Documentation: User stories, design guidelines, platform-specific requirements

5. Reporting Dashboard → Balanced WAgile

Rationale: Mix of fixed requirements (compliance) and evolving needs (usability)
Approach: Core reporting framework (waterfall) with iterative dashboard design (agile)
Documentation: Report specifications, dashboard wireframes, user feedback

Overall Project Flow (18-month timeline):

Phase 1: Foundation (Months 1-4)

Student Records Module design and core development
Timetabling System architecture and algorithm development
Integration framework establishment

Phase 2: Core Implementation (Months 5-10)

Complete Student Records and Timetabling systems
Begin Parent Portal with user research and prototyping
Start Mobile App MVP development

Phase 3: User-Facing Development (Months 11-16)

Iterative Parent Portal development with parent feedback
Mobile App iterations with student testing
Reporting Dashboard core functionality

Phase 4: Integration and Deployment (Months 17-18)

System integration testing
Security and compliance validation
User training and deployment

Critical Integration Points:

Data API Layer (Month 4): All components depend on this
Authentication System (Month 6): Shared across all user-facing components
Security Review (Month 8): Required before any external access
User Testing Coordination (Month 12): Parent and student feedback sessions

Risk Management:

Early focus on compliance-heavy components reduces late-stage risk
User-facing components get continuous feedback to ensure adoption
Integration points are clearly defined and scheduled
Security and privacy requirements addressed throughout

Exercise 3: Scaling WAgile for different contexts¶

Exercise 3: Adapt WAgile to Project Context

Scenario: You need to recommend WAgile approaches for three different projects:

Project A: Startup Mobile App

Team: 4 developers
Timeline: 6 months
Budget: Flexible (seeking investment)
Market: Rapidly changing user preferences
Technology: Modern mobile frameworks

Project B: Enterprise Data Migration

Team: 25 specialists across multiple locations
Timeline: 24 months
Budget: $5M (fixed, heavily scrutinised)
Compliance: Financial regulations, audit requirements
Technology: Legacy systems integration

Project C: School Website Redesign

Team: 2 developers, 1 designer
Timeline: 4 months
Budget: $50,000 (fixed)
Stakeholders: Teachers, parents, students, administration
Requirements: Mix of fixed (branding) and evolving (features)

Tasks:

For each project, recommend the appropriate WAgile balance
Define the number and type of stage gates
Specify iteration lengths and governance approaches
Justify your recommendations based on project characteristics

Sample Solution

Project A: Startup Mobile App → Agile-Heavy WAgile

Recommended Structure:

Stage Gates: 2 lightweight gates
Iteration Length: 1 week sprints
Governance: Team self-management with weekly stakeholder check-ins

Stage Gates:

MVP Definition Gate (Month 2): Core features defined, technical approach validated
Market Validation Gate (Month 4): User feedback collected, pivot decisions made

Justification: High uncertainty, need for rapid iteration, small team can move quickly, market feedback critical for success.

Project B: Enterprise Data Migration → Waterfall-Heavy WAgile

Recommended Structure:

Stage Gates: 5 formal gates with executive approval
Iteration Length: 3-4 week iterations
Governance: Program management office, formal documentation

Stage Gates:

Data Assessment Gate (Month 4): Current state analysis, migration scope defined
Architecture Approval Gate (Month 8): Technical approach approved, tools selected
Pilot Migration Gate (Month 12): Small-scale migration validated
Production Readiness Gate (Month 20): Full migration approach tested
Deployment Approval Gate (Month 23): Final validation, go-live approval

Justification: High risk, regulatory requirements, large distributed team needs coordination, budget scrutiny requires predictable milestones.

Project C: School Website Redesign → Balanced WAgile

Recommended Structure:

Stage Gates: 2 informal gates with stakeholder review
Iteration Length: 2 week sprints
Governance: Weekly stakeholder demos, end-of-iteration reviews

Stage Gates:

Design Approval Gate (Month 2): Visual design and site structure approved by stakeholders
Content Migration Gate (Month 3): Content strategy validated, technical implementation complete

Justification: Small team, mixed requirements (some fixed branding, some evolving features), diverse stakeholders need regular input, fixed budget requires controlled scope.

Common Success Factors Across All Projects:

Clear gate criteria defined upfront for all stakeholders
Regular iteration reviews to collect feedback and adjust
Stakeholder engagement appropriate to project scale and risk
Documentation level matched to compliance and handoff needs
Risk management proportional to project impact and uncertainty

Recap¶

WAgile methodology provides a practical hybrid approach that combines waterfall stage gates for governance and risk management with agile iterations for flexibility and rapid feedback. The approach works best when organisations need both predictable milestones and adaptive development capability.

Stage gates provide formal checkpoints for approval, quality assurance, and risk assessment, while iterative delivery within stages allows teams to refine work progressively and respond to stakeholder feedback. The balance between waterfall and agile elements should be determined by project scale, regulatory requirements, team experience, and organisational culture.

WAgile interventions are most effective when applied thoughtfully based on specific project characteristics rather than as a one-size-fits-all approach. Success depends on clear gate criteria, appropriate governance levels, and maintaining team agility within the structured framework.