Question 5 of 26: Agile Methods — Interest and Dangers

Question 5: Agile Methods — Interest and Dangers (Part I)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Why the Interest

Business environments change requirements faster than they can be fully specified up front, and heavyweight upfront specification (classical Waterfall) commits to a detailed requirements document that is frequently obsolete before the system is delivered. Agile methods respond by embracing change: short iterations (typically 1–4 weeks) deliver working, demonstrable software early and often, so real user feedback corrects course long before the full budget is spent building the wrong thing. This reduces the single biggest risk in software projects — building a functionally correct system nobody actually wants — and shortens time-to-market for the highest-value features by prioritizing the backlog continuously rather than committing to a fixed scope at project start.

Dangers

• Scaling and coordination. Agile's close, continuous customer collaboration and light documentation assume a small, co-located (or tightly synchronized) team; scaling to large, distributed teams, or to systems requiring formal certification traceability (safety-critical, medical, aviation — directly relevant to EGBC-regulated engineering work), is far harder and usually needs additional scaffolding (SAFe, disciplined architecture ownership) not present in the base method.
• Architectural erosion. Without deliberate architectural discipline, rapid feature-by-feature delivery can accumulate technical debt — each sprint optimizes for the current increment, and no phase is explicitly reserved for holistic architecture review, unless the team enforces one itself.
• Customer availability dependency. The method assumes a real, continuously available customer representative to clarify requirements each iteration; in fixed-price/contract development this role is often unrealistic, and its absence degrades agile back toward guesswork.
• Predictability. Fixed-scope, fixed-price contracts sit uneasily with agile's variable-scope philosophy, since neither total cost nor delivery date is committed up front in the same way a Waterfall plan claims to commit them (even though that Waterfall commitment is itself frequently unreliable in practice).