Every agile method comes with opinions, and every enterprise comes with exceptions. A team that builds a mobile app, a team that integrates an enterprise resource planning (ERP) package, and a team that maintains a 20-year-old billing system don’t share the same constraints. Disciplined Agile Delivery (DAD) starts from that observation.

Scott Ambler and Mark Lines described DAD in their 2012 book. It isn’t a single method with a fixed set of ceremonies. It’s a toolkit that borrows from Scrum, Kanban, Lean, Extreme Programming, and other sources, and it organizes them around goals instead of prescriptions. For each goal, such as “explore the initial scope” or “improve quality,” DAD lists options, trade-offs, and when each one fits.

A full lifecycle, not just construction

DAD also covers more of the delivery story than many agile approaches do. It describes three phases: inception, where the team forms a shared vision and enough of a plan to get funded; construction, where it builds the solution in increments; and transition, where it prepares for release into production. Anyone who has watched a Scrum team “finish” a sprint only to wait six weeks for a release window will see why that matters.

For a large organization, this is useful. Consider a manufacturer whose teams must satisfy audit, security, and operations groups before anything ships. A method that ignores those groups leaves the team to improvise. A method that names them as part of the lifecycle gives everyone something to plan around.

The case for choosing by context

We think the underlying argument is sound. Practices work in context. Daily stand-ups help a co-located team and may be a burden to a distributed one. Estimating in story points helps some teams forecast and gives others a number to argue about. Letting teams choose practices that fit their situation, and explain why, is more honest than handing out one playbook and calling any deviation a failure.

It also fits how large clients buy. Few enterprises want to rip out everything they have. A hybrid approach lets them keep a stage-gate review where regulation requires it while teams work iteratively between gates.

The risk: choice as an excuse

Here’s the catch. “We chose what works for us” is easy to say and easy to abuse. Teams can drop the uncomfortable practices, such as retrospectives, working software every iteration, and honest measurement, and keep the comfortable ones. The result is a customized process that is mostly missing.

The word “disciplined” matters here. Choice only works with guardrails. Before a team drops or changes a practice, ask three things:

• Which goal does this practice serve?
• What will we do instead to reach that goal?
• How will we know in a month whether it worked?

If a team can’t answer, it hasn’t chosen anything. It has skipped something.

For your next engagement, treat flexibility as something teams earn by showing results. Start every team with a small, agreed baseline, let them adapt with reasons written down, and review those reasons regularly. If you want a second opinion on where your teams sit between rigid and loose, talk to us.