Flavors of Agile - Disciplined Agile

 

I was going to review AUP - the Agile Unified Process (having read about it, once, several years ago, when part of the company I was working for used RUP), but, in 2006, Scott Ambler abandoned it in favor of Disciplined Agile Delivery (DAD), which has since evolved into the Disciplined Agile Framework.  The reason for this shift was to address how to be effective at IT, not just at delivering IT solutions.

Disciplined Agile has its own manifesto and principles.  It is intended to be an extension of the Agile Manifesto, so it will seem very familiar when reading it.

Scott provides several reasons why you should choose Disciplined Agile.

1. Disciplined Agile picks up with Scrum leaves off, dealing with architecture, design, testing, programming, documentation, etc…
2. It is pragmatic, allowing you to choose how to execute it in response to your situation
3. It supports both lean and agile lifecycles
4. It is based on proven strategies used across multiple industries
5. It provides a foundation for scalability
6. It enables and goes beyond SAFe (Scaled Agile Framework; watch for it next week)
7. It is constantly evolving as new agile and lean strategies emerge

Roles are split into primary and secondary roles.  Primary roles exist regardless of the scale of the project.  They are:

• Stakeholder
• Product Owner
• Architecture Owner
• Team Lead (analogous to a Scrum Manager and Agile Coach)
• Team Member

As a project grows in scale, the following roles may be added:

• Specialist
• Independent Tester
• Domain Expert
• Technical Expert
• Integrator

As you learn more about Disciplined Agile, you'll begin to recognize flavors of other project management approaches.  It is intentionally a hybrid approach, with the intent of borrowing the best from other approaches and combining them in attempt to leverage their strengths and overcome their weaknesses.

In keeping with its emphasis on the agile organization, not just agile delivery, Disciplined Agile provides guidance on establishing and running agile Communities of Practice and Centers of Excellence, governing agile teams, and maintaining awareness of agile at five different levels within an organization.  This, combined with other practices, is referred to as Strategic Agility at Scale.  Organizational processes are broken down into lifecycles and blades.  These are:

Disciplined Agile Delivery

• Continuous Delivery
• Exploratory/Lean Startup
• Lean/Advanced
• Agile/Basic
• Program Management

Disciplined DevOps

• Non-Agile/Lean Lifecycles
• Release Management
• Operations
• Support
• Data Management

Disciplined Agile IT

• People Management
• Product Management
• Portfolio Management
• Enterprise Architecture
• Reuse Engineering
• IT Governance
• Continuous Improvement

While this is not the same process as ASAP, it's starting to feel the same - highly structured, which almost feels contrary to Agile - but that is not a bad thing when dealing with Agile at the enterprise level.

While I can't say whether or not Disciplined Agile is the best approach, I completely agree with the mindset that transitioning to Agile cannot be just an IT change.  Not only does Agile change how products are delivered, it changes how progress is reported, how requirements are prepared, how projects are planned, and more.  If your leadership is still expecting things to run the way they used to, you may struggle to get support because leadership expectations are not aligned with Agile practices - this is a concern with all Agile flavors, not just with Disciplined Agile.