When we describe DAD we remind people that it is not another agile method as we clearly have enough of those already. Rather, DAD is a process decision framework that enables better decision making when customizing approaches for adopting agile within the context of your organization and projects. Popular agile methods can be quite prescriptive. Sometimes their agile rules – work collocated in one room, use teams less than nine people, or don’t do fixed price projects – are not practical. Rather than discounting such projects as not agile, why not take a pragmatic approach to dealing with these realities while striving to still be as agile as possible? DAD provides the guidance that enables you to easily tailor, and later evolve, your agile approach to effectively address the context of the situation that you find yourself in. Hence the term process decision framework.
Another way to look at DAD is that is “pragmatic agile”. In their book The Pragmatic Programmer, Andrew Hunt and David Thomas describe the need for programmers to be inquisitive, critical thinkers who are realistic and jack-of-all-trades (what we call generalizing specialists). These qualities are consistent with those we describe for all team members on DAD projects. This pragmatism reflects the need for agilists to abandon dogmatic, purist approaches to implementing agile and recognize the need to adapt for the complexities of most enterprise projects. We often encounter management that is frustrated with agile teams that ignore organizational standards and resist compliance with any sort of governance that seeks measure things such as the health, risks, and return on investment for these agile projects. In return, agile teams often say that management just doesn’t get it. Surely there is a compromise here. Management needs to understand that they need to adapt their approach to governing agile projects and agile teams need to be flexible in dealing with the realities of building software solutions for the enterprise.
Why is DAD pragmatic agile? We feel that it is pragmatic to:
- Take a goal-driven approach which describes the agile strategies available to you, the advantages of disadvantages of each, and when to consider using each one.
- Invest a small amount of time prior to beginning construction to get going in the right direction. We frame this endeavour in terms of the goals described below in the Inception phase section of Figure 1.
- Plan to spend some time after completing the construction of the solution to properly deploy it to your stakeholders. This is described via a goal-driven strategie as shown in the Transition phase section of Figure 1
- Do some lookahead planning and modeling, often referred to as backlog grooming, on a just-in-time basis to be more effective when implementing work items during each iteration
- Leverage the existing organizational ecosystem to reuse existing services, patterns, templates, code, guidelines and other assets
- Govern the project teams in an agile manner
- Encourage project specific process improvement through self-organization within the constraints that make sense for the organization
- Adapt the types and formality of work products produced for the context of the projects
We have seen that DAD is certainly resonating with companies that have been struggling to create their own flavour of agile with Scrum, Extreme Programming (XP), and other approaches. This roll-your-own approach can be difficult and expensive for companies to develop and then maintain. DAD provides a complete and flexible framework that enterprises have been looking for, enabling them to get on with the actual job of delivering business value to their stakeholders.
How do we apply the framework to make better decisions and be pragmatic? DAD is goal-driven. Figure 1 shows the goals that are consistent with any type of software development effort regardless of type, whether it be custom development or implementing a package for instance.
Figure 1. The Process Goals of Disciplined Agile Delivery.
Figure 2 shows an example of a process goal diagram to show how to fulfill a particular goal. To address the Explore The Initial Scope process goal we need to consider various issues or factors in order to be most effective for the context that we find ourselves in. This goal is an important part of the Inception phase so that we can move towards obtaining stakeholder consensus that it makes sense to move into the Construction phase and begin building the solution. For each issue there are a number of choices. Some choices, such as work item stack, are bolded and italicized indicate good choices as a place to start for a typical DAD project. Some issues show an arrow beside the options which is an indication that the choices at the top are typically the most effective and the better alternatives to strive for. A typical project will make hundreds of process decisions and these diagrams can be used to ensure that the various options are considered. An example of a decision might be what view type might I use to depict my scope? DAD recommends starting with a combination of usage modeling, domain modeling, and non-functional requirements. For usage modeling, user stories is the most popular agile approach, but you could also create use case diagrams or personas as needed. The DAD book describes each of the alternatives, as well as their advantages and disadvantages of each. In this way, DAD helps us make better decisions.
Figure 2. Process Goal Diagram: Explore the Initial Scope.
Is pragmatic agile an excuse for taking shortcuts? Although the DAD philosophy seeks to be as agile as possible, it is not an excuse for being lazy. We use the term disciplined for a reason. We often see organizations that are struggling with Scrum, and the root cause turns out to be that the teams are skipping some of the core Scrum practices. For instance they may have decided that they have a good process and no longer need to do retrospectives. In situations like these, the teams have abandoned one or more of the goals of a DAD project. Referring back to Table 1, we can see that an ongoing goal is to Improve team process and environment. Another example might be that the team does not do regular, end-of-iteration demonstrations. Here they are not fulling the goal of Produce a potentially consumable solution. Perhaps the teams says that they always have working software, but how do we know it is consumable? Who as seen it? Have the operations and support staff seen it? Are end users actually eager to work with it?
As you can see, we can refer to the goals table and ask ourselves, “how are we fulfilling each of these goals?”. Using this goals driven approach can help to ensure that you do not have gaps in your approach to implementing pragmatic agile.