If you’ve been working with 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 software development puzzle is missing pieces, and Scrum doesn’t have a standard solution for this problem.
Don’t get me wrong, Scrum does an awesome job at helping you manage delivery teams. Still, there are issues that Scrum doesn’t address due to its 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?
An obvious solution is to come up with a strategy that extends Scrum, scaling Agile project management to an enterprise-grade level. The good news is you don’t have to reinvent the wheel to do this. If you’re looking for less ideology and more actionable stuff, there are several mainstream agile methods that offer practical, down-to-earth solutions.
Two notable examples are DAD and SAFe — the Disciplined Agile Delivery and the Scaled Agile Framework. In our experience, the former has proved to work for delivery operations in a wide range of companies, from large enterprises to lean startups. In fact, the AgileEngine team uses the Disciplined Agile Delivery internally as its core project management methodology.
WHY WE’VE CHOSEN DISCIPLINED AGILE DELIVERY
DAD excels at covering the full delivery lifecycle. It offers a hybrid Agile approach that moves from abstract principles to a well-structured process decision framework. The latter combines practices from multiple sources including Scrum, Kanban, Unified Process, Extreme Programming, Agile Modeling, Agile Data, and the Outside-in Software Development. And the best part is DAD demonstrates how these Agile strategies and 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 delivery 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.
UP-FRONT REQUIREMENTS
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.
ACCEPTANCE CRITERIA
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.
