Chapter 13: Case Study: The SDLC in a Large Enterprise Team

Why this matters

This chapter mirrors Chapter 12's structure exactly, applied to the opposite end of the spectrum — a large enterprise context — to make the contrast, and the underlying reasoning framework that produces genuinely different (but equally deliberate) choices, as clear as possible.

The context

A 40-person engineering organization (multiple teams) at an established company, building software for a regulated financial services product — real customers, real money, and real regulatory/audit requirements, with the primary business risk being a costly, reputation-damaging, or compliance-violating failure, not "building the wrong feature."

Process model (Chapter 2-3)

Choice: Scrum within each team (two-week sprints, standard ceremonies), with an additional cross-team coordination layer — a scaled-Agile-style planning cadence where teams' sprint plans are reviewed together periodically to surface cross-team dependencies before they become blocking surprises.

Reasoning: at 40 engineers across multiple teams, the coordination problem is real and severe (Chapter 3) — without a structured cadence, cross-team dependencies become invisible until they cause late, expensive integration surprises. Scrum's predictable sprint rhythm also fits well with the organization's need to report progress to non-engineering stakeholders (compliance, executive leadership) on a predictable cycle.

Requirements (Chapter 4)

Choice: formal user stories with detailed acceptance criteria in Jira, reviewed by a dedicated product manager, with explicit sign-off required for anything touching regulated functionality.

Reasoning: with many engineers who don't have constant, informal access to the people who understand the regulatory requirements, ambiguity resolved via a two-minute hallway conversation (as in the startup case study) isn't available — requirements need to be explicit and complete enough to be understood correctly by someone without that immediate, shared context, and the regulatory stakes justify formal sign-off as a real safeguard, not just process ceremony.

Design (Chapter 5)

Choice: formal, written design documents for any change touching a shared/core system, reviewed by a cross-team architecture review group before implementation begins; lighter-weight design notes for changes fully contained within one team's own service.

Reasoning: a design flaw in a shared, widely-depended-upon system affects many teams simultaneously and is expensive to correct after multiple teams have built on top of it — the architecture review's fresh, cross-team perspective (Chapter 5) is specifically valuable here because no single team has full visibility into every other team's dependencies and constraints.

Testing (Chapter 7)

Choice: a full testing pyramid with mandatory coverage thresholds enforced in CI, a dedicated QA team performing structured UAT for regulated functionality, and mandatory security review for anything touching customer financial data.

Reasoning: the cost of a production defect in this domain (financial harm, regulatory penalty, reputational damage) is high enough to justify comprehensive, multi-layered verification — the informal, engineer-self-verification approach reasonable at the startup's scale and risk profile would be genuinely inadequate here, not just "more thorough than necessary."

Deployment (Chapter 9)

Choice: canary deployments with automated rollback triggers for all production changes, mandatory change review/approval for anything touching regulated systems, and a formal change freeze during specific high-risk periods (e.g., end-of-quarter financial reporting).

Reasoning: the blast radius of a bad deployment in this domain is large and expensive — canary's gradual, monitored rollout directly limits that blast radius, and the formal approval/freeze processes reflect genuine, externally-imposed regulatory and business constraints the startup case study simply doesn't face.

Operations (Chapter 10)

Choice: formal, tooled on-call rotation (PagerDuty) with defined severity levels and escalation paths, mandatory blameless postmortems for any customer-impacting incident, and a dedicated incident commander role staffed from a trained pool.

Reasoning: at this scale and risk profile, an ad hoc "whoever's around" response (reasonable for the five-person startup) would be genuinely inadequate — the cost of a slow, poorly-coordinated incident response in a regulated financial system is high enough to justify real, ongoing investment in structured incident response capability.

Common mistakes

1. Assuming a large enterprise team's heavier process is simply bureaucratic overhead, rather than recognizing it's calibrated to genuinely higher stakes (regulatory risk, coordination complexity, cost of failure) that the startup case study doesn't face at all.
2. Applying uniform heavy process to every change regardless of actual scope (formal architecture review for a change fully contained within one team's own service) — this enterprise case study still calibrates rigor to actual risk, just at a generally higher baseline than the startup case.
3. Not recognizing that regulatory/compliance requirements are often genuinely externally imposed, not a team's own process preference — some of this rigor isn't a judgment call the team gets to make lightly, unlike most of the startup case study's choices.
4. Assuming this heavier process would also be appropriate for the startup's context, missing that the entire point of Chapter 3's framework is that the same process can be right in one context and wrong in another.

Discussion / interview questions

1. "How would you structure the SDLC for a 40-person engineering organization building regulated financial software, and how would this differ from a small startup's approach?" Strong answer: Heavier process throughout (Scrum with cross-team coordination, formal requirements sign-off, mandatory architecture review for shared systems, full testing pyramid with dedicated QA, canary deployments with formal approval, tooled on-call with blameless postmortems) — calibrated to genuinely higher stakes (regulatory risk, coordination complexity, cost of failure) than a small startup faces, contrasted explicitly against the Chapter 12 case study.

2. "Why does requirements documentation need to be more formal in a large organization than in a small startup?" Strong answer: In a small startup, ambiguity resolves via immediate, informal conversation with people who have full context; in a large organization, many engineers lack that immediate access to domain experts, so requirements need to be explicit and complete enough to be understood correctly without that informal channel — and regulatory stakes further justify formal sign-off as a genuine safeguard.

3. "Why would a large enterprise team use canary deployments with formal approval, rather than the startup's continuous-deployment-to-everyone approach?" Strong answer: The blast radius and cost of a bad deployment in a regulated financial system is much higher, justifying canary's gradual, monitored rollout to limit exposure, plus formal approval reflecting genuine regulatory/business constraints — the startup's low-stakes, low-traffic context doesn't face these same pressures.

4. "Is all of this enterprise team's process overhead justified, or is some of it just bureaucracy?" Strong answer: A well-reasoned answer distinguishes genuinely justified rigor (calibrated to real regulatory/coordination/cost-of-failure stakes) from process applied uniformly regardless of actual risk (e.g., requiring full architecture review for a trivial, single-team-contained change) — even in a high-stakes context, rigor should still be calibrated to the specific change's actual risk, not applied as a blanket, undifferentiated maximum everywhere.

Chapter summary / cheat sheet

• A 40-person regulated-industry enterprise team reasonably chooses heavier process nearly everywhere: Scrum plus cross-team coordination, formal requirements sign-off, mandatory architecture review for shared systems, comprehensive testing with dedicated QA, canary deployments with formal approval, and tooled, structured incident response.
• The dominant risk (costly, regulatory, or reputation-damaging failure) and coordination complexity (many teams, less shared context) justify this heavier baseline — directly contrasting with the startup case study's dominant risk (building the wrong thing slowly).
• Even at this heavier baseline, rigor should still be calibrated to a specific change's actual risk (lighter design notes for single-team-contained changes) — heavier overall process doesn't mean uniform maximum rigor everywhere.
• Comparing these two case studies directly demonstrates Chapter 3's central lesson: the same underlying decision framework, applied honestly to different contexts, produces genuinely different, equally reasonable answers.

---