Unravelling Disciplined Agile (DA): A Guide to a Hybrid Agile Framework

Unravelling Disciplined Agile (DA): A Guide to a Hybrid Agile Framework

Disciplined Agile: The Framework That Refuses to Be a Framework

Disciplined Agile (DA) was created by Scott Ambler and Mark Lines in 2012, and its central premise is almost paradoxical: we’re giving you a toolkit, not a process. You decide how to use it.

This is both its greatest strength and its most significant adoption challenge. DA contains more options than any other Agile framework. Scrum tells you what meetings to have and roughly how they should work. DA tells you there are nine different ways to approach sprint/iteration planning and here’s when each is appropriate.

For organizations that genuinely need flexibility because their teams operate in diverse contexts, DA is powerful. For organizations that want someone to tell them exactly what to do, DA is maddening.

What DA Actually Is

DA is a decision-making framework — specifically, a toolkit of process goals and the techniques that can achieve them. It was acquired by PMI (Project Management Institute) in 2019 and is now a central part of their methodology portfolio.

The core of DA is organized around process goals — outcomes like “form initial team,” “produce potentially consumable solution,” “govern delivery team.” For each process goal, DA offers multiple approaches (tactics) that teams can choose from based on their context. The choice of tactics is guided by context factors: team size, organizational culture, technical constraints, regulatory environment.

This is genuinely different from other Agile frameworks. Scrum says “do a retrospective every sprint.” DA says “here are eight practices for continuous improvement, including but not limited to retrospectives — choose based on your team’s situation.”

The Seven Principles: The Honest Assessment

DA’s seven principles are reasonable and in some cases sharper than most Agile frameworks manage:

Delight customers — not just satisfy them, not just deliver what they asked for. This is a high bar that most organizations aspire to and rarely measure.

Be awesome — every team member is encouraged to pursue personal excellence. This sounds motivational-poster vague but it has a practical implication: DA expects team members to invest in their own skills, not just execute their role.

Context counts — perhaps DA’s most important principle. The right solution depends on your specific situation. A government regulatory project looks different from a startup’s consumer product. DA is designed to accommodate both.

Pragmatism — focus on what works in practice, not what sounds good in theory. This is a direct critique of frameworks that prescribe practices without regard for whether they’ll work in a given context.

Choice is good — the plurality of options is a feature. Teams that have experience with multiple approaches can select the most appropriate one.

Optimize flow — similar to Lean’s flow concept. Reduce delays, minimize handoffs, maximize throughput.

Enterprise awareness — team decisions should consider organizational impact, not just local team optimization.

Where DA Excels: The Genuine Strengths

Handling organizational diversity — many large organizations have teams in genuinely different situations. A team maintaining a legacy COBOL system has different needs than a team building a new mobile app, which is different from a data science team. Scrum’s uniform prescriptions often create problems when applied to all three. DA’s context-sensitivity handles this better.

Integration with project management — because PMI now owns DA, it integrates naturally with traditional project management practices, risk management, governance, and reporting. This makes it easier to adopt in organizations with existing PMI or PMBOK practices.

Honest about phases — unlike purely iterative frameworks that sometimes deny the existence of project phases, DA acknowledges that projects have inception, construction, transition, and production phases with different needs. This makes DA more honest about how projects actually work.

Hybrid approach — DA doesn’t require you to abandon Scrum or Kanban. It can be used as a wrapper that helps teams choose and adapt existing practices rather than as a replacement for everything they know.

Where DA Struggles: The Genuine Weaknesses

Decision paralysis — Ambler and Lines themselves acknowledge this risk. When you give teams nine options for how to plan a sprint, teams without experienced guidance often struggle to choose. Decision paralysis is real, and it tends to affect teams early in their Agile journey most severely — exactly the teams that might be reaching for a toolkit because they’re not sure what to do.

My observation: DA works best as a framework for experienced Agile practitioners who have internalized enough experience to make informed choices. Less experienced teams often benefit from the prescriptiveness of Scrum first, then graduating to DA’s context-sensitivity once they understand why Scrum’s prescriptions exist.

Certification proliferation — PMI’s acquisition brought the framework’s certification apparatus. DA now has multiple certification levels with associated training costs. Whether the certifications signal genuine competence is debatable.

Less community — Scrum has an enormous community, countless retrospective formats on the internet, and decades of accumulated practitioner knowledge. DA has a smaller community and less freely available practical guidance. Practitioners who need peer support or external resources will find less to draw on.

The toolkit can become the destination — teams sometimes become absorbed in DA’s framework selection and documentation rather than actually delivering software. Meta-process discussion is a form of waste.

How to Actually Implement DA

Don’t start by learning all of DA. Start by identifying your actual problems.

If your team is working well with Scrum and struggling with context-specific situations that Scrum doesn’t address — unusual governance requirements, hybrid teams, integration with traditional project management — use DA’s toolkit to supplement what you’re already doing.

If you’re choosing between DA and another framework for a new team: start with Scrum or Kanban for the first 3-6 months to build basic Agile discipline. Then use DA’s context tools to evaluate whether your current practices are the right fit for your specific situation.

The DA lifecycle gives you a helpful structure: Inception (initial team formation, vision, feasibility) → Construction (iterative delivery) → Transition (release preparation) → Production (ongoing operations). Using this lifecycle framing even while practicing Scrum helps teams think about the whole product lifecycle rather than just the current sprint.

The Honest Bottom Line

DA is the right framework if: you have experienced Agile practitioners who understand why practices exist and can make informed contextual choices, you operate in a genuinely diverse organizational environment, and you need a framework that integrates with traditional project management.

DA is the wrong framework if: your team is new to Agile and needs clear prescriptions to learn from, you have limited experienced Agile guidance available, or you’re looking for something with a large active community for ongoing learning.

The most honest description of DA: it’s the framework for people who’ve outgrown single-framework prescriptions and need structured flexibility. It’s powerful in those hands and overwhelming in others.