One Method for Two Very Different Product Lines
Statewide Bank's digital lending group, 30 people, runs two product lines under one manager. Line A covers regulatory lending disclosures: 18 months of fixed scope, an annual regulator deadline, requirements that barely change, and integration through nine core systems. Line B runs machine-learning experiments for credit-risk scoring: hypotheses change every two to four weeks, and the team needs to test models against live data. The manager standardizes both lines on two-week Scrum sprints, one product backlog per line, and a quarterly release train. Six weeks in, Line A has missed two integration windows with the payments platform, and Line B needs about six weeks to move a single experiment through the backlog. The manager asks for a single 'DA-compliant' approach that covers both lines because 'the PMO wants consistency.'
1. Recommend a way of working for Line A and Line B. Justify using DA's life-cycle selection logic rather than a single 'DA-compliant' template.
Read the worked answer
DA treats the life cycle as a context-sensitive choice, not a certification badge. Line A has stable requirements, a fixed external deadline, and high integration complexity across nine systems. A flow-oriented, continuous-delivery life cycle fits better than two-week Scrum: make integration a daily activity, use a kanban-style pull system with explicit policies, and plan releases around regulator milestones rather than a quarterly train. Line B has high uncertainty and short hypothesis cycles; an Exploratory life cycle fits, with time-boxed experiments, evidence-based decision points, and a separate backlog.
The PMO can have consistency in governance without uniformity in method: same intake, same outcome metrics, different ways of working. The manager's 'single approach' is the problem - it forces Line A to batch integration and Line B to queue experiments behind feature work. Document the choice and review it at a set date; DA expects the life cycle to evolve.
2. What program-level practices would you add for Line A, and what would you stop?
Read the worked answer
Add a program-level integration cadence: a shared integration environment with a published booking policy and daily automated build-and-test across the nine systems; a dependency board reviewed twice weekly; and a release roadmap tied to regulator checkpoints. Define 'done' at program level to include cross-system integration tests, not just team-level tests. Stop treating the quarterly release train as the only integration event - that batches risk. Also stop the single product backlog if it forces integration work to compete with feature stories; instead reserve explicit integration capacity each iteration.
At the program level, DA's process blade includes coordinating teams, managing dependencies, and aligning architecture. Measure integration-window adherence, defect leakage into system test, and lead time for cross-system changes. Choose the first change with guided continuous improvement: pick the largest pain point - missed integration windows - run a two-iteration experiment on daily integration, and compare leakage before and after.
3. Line B's experiments need live data and six weeks to get through the backlog. What guardrails keep it compliant without turning it into Scrum?
Read the worked answer
Guardrails should constrain outcomes and risk, not the experiment cadence. Require each experiment to state a hypothesis, a success measure, a data-handling approval, and a stop date. Use a lightweight intake that reserves a fixed percentage of capacity for experiments so they are not queued behind feature work. Require a decision record at the end: adopt, iterate, or stop. For compliance, keep the same audit trail and data-access reviews as Line A, but do not require two-week sprint boundaries or a quarterly release train.
This is DA's 'choice is good' applied with explicit boundaries: the team tailors its way of working, and the organization sets the non-negotiables. Measure cycle time from hypothesis to decision, percentage of experiments with a recorded decision, and number of compliance exceptions. If cycle time stays above four weeks after two iterations, change the intake or the capacity reservation.