Disciplined Agile Delivery: Agile Project Management in the Post-Scrum World
If you’ve been using Scrum long enough, you’ve probably faced some of these issues:
- insufficient or missing big-picture planning,
- weak or missing architecture focus, no architecture role,
- lack of early risk mitigation,
- lack of upfront requirements,
- lack of acceptance criteria,
- lack of budget approvals,
- lack of dates.
Do these look familiar? If yes, your Agile project management puzzle is missing pieces, and Scrum doesn’t have a standard solution for them.
Don’t get me wrong, Scrum does an awesome job at helping you manage the work of development teams. The problem is it doesn’t go outside of this narrow scope. As a consequence, adopting Scrum without having a good plan for requirements, stakeholder expectation management, design, and architecture is a recipe for failure.
In the worst-case scenario, this results in a broken project management that fails to secure the delivery of a high-quality product. In the best-case scenario, this leads to a “somewhat agile” project management which doesn’t scale beyond small teams and doesn’t produce predictable outcomes for the business.
So how do you fix these issues?
The good news is you don’t have to reinvent the wheel to fill in the missing parts of Agile project management. If you’re looking for less ideology and more actionable stuff, there are several frameworks that offer practical, down-to-earth solutions.
Two notable examples are the Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). In fact, it’s the latter that proved to work for a wide range of companies, from large enterprises to lean startups. And it’s the Disciplined Agile Delivery that the AgileEngine team uses internally as its core project management methodology.
Why we’ve chosen Disciplined Agile Delivery
DAD does a far better job at covering the complete software delivery lifecycle than any other framework used in Agile project management.
Disciplined Agile Delivery offers a readymade process-decision framework that combines the elements of major Agile methodologies. The latter include Scrum, Kanban, Extreme Programming, Agile Modeling, Agile Data, Unified Process, and the Outside-in Software Development. And the best part is DAD demonstrates how these Agile techniques can fit together in a well-structured, flexible, and scalable system.
In a nutshell, the Disciplined Agile Delivery takes what works in Scrum (or other Agile software development methodologies), and it adds everything that’s missing. For instance, it divides the Agile lifecycle into phases, adding the much-needed time frame for envisioning and initial planning:
By doing this, it helps you avoid the pitfalls associated with the lack of long-term planning in the “classic” Agile. Naturally, there are other practical benefits that production teams get from adopting DAD. In fact, let’s return to the issues we’ve began with and see how the Disciplined Agile Delivery deals with them.
Seeing the bigger picture
In contrast to the narrow focus of Scrum, DAD addresses a wide spectrum of Agile project management processes and collaboration patterns.
The scope Dedicated Agile Delivery doesn’t stop at the team management level. Instead, the framework provides you with a detailed enterprise-level Agile methodology that leaves no big questions unanswered. In addition to development, DAD addresses architecture, governance, design, DevOps, testing, even technical writing — and it ties all of these processes together.
Thanks to the support of four lifecycles (Agile, Lean, Continuous Delivery and Lean Startup), DAD also encourages you to choose how you’re going to build your product. The wide range of supported lifecycles makes DAD way less restrictive than SAFe.
Agile project management with an strong architecture focus
Disciplined Agile Delivery incorporates agile architecture strategies starting from the project inception phase. Upfront architecture envisioning is integral to every DAD-based project, and the architecture evolves incrementally and iteratively during the development phase. The iterations during the development phase also require proving architecture with code.
The existence of a clear-cut role of an architecture owner is another distinguishing feature of DAD. Like in other Agile project management models, this role requires a specialist with advanced experience with the product’s tech domain.
An architecture owner drives the collective effort of planning out the iterative evolution of project architecture. In this respect, the role of an architecture owner is different from that of an architect who has a semi-ultimate control over the product architecture.
Early risk mitigation
The risk/value-driven lifecycle used in the Disciplined Agile Delivery builds on early mitigation of risks. Identification of risks is a process goal included into the project inception phase of Disciplined Agile Delivery.
Furthermore, DAD specifies the procedures for identification, classification, exploration, documentation, capturing, and monitoring of risks. The risks that the framework explicitly addresses are those of architectural, security, quality, financial, organizational, and schedule-related nature.
Project management in the Disciplined Agile Delivery aims to mitigate risks via a set of milestones. Getting feedback from stakeholders and proving architecture via code in the early stages are examples of such milestones. The same goes for functionality checks before the transition and production readiness checks before the release.
The exploration of up-front requirements is another process goal that belongs in the project inception phase in DAD. Much in the spirit of Agile project management, a team aims to collect just enough information to form a clear vision of the problems that the future product will solve. In case with larger projects, the collection of initial requirements may involve more work and go into greater detail.
DAD includes best practices for capturing and the implementation of acceptance criteria from a wide range of stakeholders. Working with acceptance criteria is carried out via Acceptance test driven development (ATDD) and Behavior Driven Development (BDD). The initial collection of acceptance criteria, along with other non-functional requirements, occurs during the inception phase.
Budgeting and scheduling
The proponents of the Disciplined Agile Delivery favor the rolling wave approach to planning. This paradigm combines high-level planning on project level with detailed scheduling for those events that will occur in the near future.
This approach benefits development teams by providing them with a more realistic schedule that reflects the actual state of affairs at any given moment. In addition, this scheduling model offers a larger amount of performance data for the management.
Part of the rolling wave planning is the rolling wave budgeting model that is opposed to annual budgeting strategies.
Bottom line: want to know more?
If the Disciplined Agile Delivery sounds like something you’d want to know more about, here’s a presentation that covers the key components of the framework. In case you’re looking for something more in-depth, check out the Disciplined Agile 2.X website.
Finally, if a team of software developers with expertise in DAD projects is what you’re looking for, you’re at the right place. The software engineers at AgileEngine have over 15 years of collective experience, and we were among the early adopters of DAD when it emerged in 2012. Our guys worked in DAD projects, and they’ve presented their thoughts on the framework during a number of tech talks.
Care to know more? Fill in the contact form and tell us about your project and the tech stack you’re planning to use.