The Disciplined Agile (DA) framework takes a goal-driven approach (some people like to call this a capability-driven approach or even a vector-driven approach). The purpose of DA’s goal-driven approach is that it guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. This supports the DA principle that Choice is Good. This is important because every team faces a unique situation. Teams vary in size, they vary in the way that they are geographically or organizationally distributed, they vary by the domain and technical complexity that they face, and they vary by the compliancy issues that are relevant to them. Furthermore, teams are made up of unique individuals, each of whom has a set of unique skills and experiences. In short, because each agile team finds itself in a unique situation the team must find a way to effectively tailor the way that they work to best face that situation – This reflects the DA principle Context Counts. DA’s goal-driven strategy is a light-weight approach to providing advice for such process tailoring.
This article is organized into the following topics:
The Process Goals of Disciplined Agile Delivery (DAD)
Figure 1 summarizes the delivery-oriented process goals of Disciplined Agile Delivery (DAD) via a mind map. There are twenty-two goals in total, each of which is described by a Process Goal Diagram (see Figures 3 and 4 below for examples). A disciplined agile team will consider how to address each goal in a manner that reflects the situation that they face. Sometimes a goal will be very easy to address, for example an established development team may find that they need to do nothing else to fulfill the Form Initial Team goal. A team that is building a solution via an architecture they are very familiar with will have very little work to do to fulfill the Prove Architecture Early goal whereas a team using technologies that are new to them may have a fair bit of work to do. Different situations require different approaches.
Figure 1. The process goals of Disciplined Agile Delivery (DAD).Each of the three delivery phases (Inception, Construction, and Transition) are described by specific goals. Some goals, such as Grow Team Members and Address Risk, are applicable throughout the entire lifecycle. All twenty-two diagrams are available online via the links provided below in Table 1).
Table 1. The Process Goals of Disciplined Agile Delivery (DAD).
Process Goal Diagrams
The goal-diagram notation is summarized in Figure 2. You see that a process goal is indicated using a rounded rectangle and the process factors pertaining to a goal with normal rectangles. Process goals will have one or more decision points (formerly called process factors or process issues) that you need to consider addressing, with most goals having four or five decision points although some have eight or nine. Each decision point is then addressed by two or more techniques/practices. Because there may be many techniques to choose from, we indicate “default” techniques in bolded italics. These defaults are good starting points for teams new to agile – they are almost always strategies from Scrum, XP, or Agile Modelling with a few Rational Unified Process (RUP) ideas thrown in to round things out. Some decision points you may choose not to address. Sometimes options are “ordered”, which is indicated by a upwards pointing arrow to the left of the list of techniques. What we mean by this is that the techniques appearing at the top of the list are more desirable from the point of view of agile and lean thinking and the less desirable techniques are at the bottom of the stack. Your team of course should strive to adopt the most effective techniques they are capable of performing given the context of the situation that they face. In Figure 2 the first decision point has an ordered set of options whereas the second one does not. Typically when the options are ordered you will only choose one of them whereas you MIGHT choose several options in unordered situations.
Figure 2. Goal diagram notation overview.
Figure 3 depicts the goal diagram for Explore Initial Scope, a goal that you should address at the beginning of a project during the Inception phase (remember, DA promotes a full delivery lifecycle, not just a construction lifecycle). Where some agile methods will simply advise you to populate your product backlog with some initial user stories the goal diagram of Figure 3 makes it clear that you might want to be a bit more sophisticated in your approach. What level of detail should you capture, if any (a light specification approach of writing up some index cards and a few whiteboard sketches is just one option you should consider)? What view types should you consider (user stories are one approach to usage modeling, but shouldn’t you consider other views to explore the data or the UI)? Notice how we suggest that you likely want to default to capturing usage in some way, basic domain concepts (e.g. via a high-level conceptual diagram) in some way, and non-functional requirements in some way. There are different strategies you may want to consider for going about modeling. You should also start thinking about your approach to managing your work. In DA we make it clear that agile teams do more than just implement new requirements, hence our recommendation to default to a work item list over Scrum’s simplistic Product Backlog strategy. Finally Figure 3 makes it clear that when you’re exploring the initial scope of your effort that you should capture non-functional requirements – such as reliability, availability, and security requirements (among many) – in some manner.
Figure 3. The Explore Initial Scope Process Goal.
Figure 4 depicts the goal diagram for the Reuse Engineering process blade. The point is that the DA framework takes a goal-driven approach to all four levels of the framework: Disciplined Agile Delivery (DAD), Disciplined DevOps, Disciplined Agile IT (DAIT) and Disciplined Agile Enterprise (DAE).
Figure 4. The Goal Diagram for Reuse Engineering.
A few important points about these goal diagrams:
- There are still more options. Although the diagrams provide a good representation of the options available to you, there are always more strategies and practices being identified every day.
- Some options are really categories of options. For example, the View Types factor has options such as usage modeling, domain modeling, and so on. There are several approaches to usage modeling, including user stories, use cases, usage scenarios, and more. There are several approaches to domain modeling, including data modeling, conceptual modeling, and UML class diagramming.
- Each option has trade offs. There is no such thing as a best practice. Every practice has advantages and disadvantages. Every practice works well in some situations and very poorly in others. The DAD book provides detailed advice about the strategies and practices identified in the DAD goal diagrams (which is the primary reason that the printed version of the book is a bit over 500 pages).
- Some options are generally better than others. When there is an arrow to the left of the options list it is an indicator that the options towards the top of the list are generally more effective from an agile point of view than the options towards the bottom. An interesting implication is that the goal diagrams will often include strategies, such as taking a Big Requirements Up Front (BRUF) approach, that you would prefer to avoid. By including a range of options the DA framework helps teams to not only understand that they have choices, but that they may also have strategies available to them that are better than the ones they have currently chosen.
- Potential starting points are shown in bold. We recognize that the goal diagrams can be a bit overwhelming at first. To help address that we’ve indicated potential starting points that are geared towards teams that find themselves in fairly straightforward situations – smallish teams that are near located taking on reasonable complexities.
The Benefits of a Goal-Driven Approach
Our experience is that there are several fundamental advantages to taking a goal-driven approach to agile solution delivery. A goal-driven approach:
- Provides straightforward process tailoring guidance. Figures 3 and 4 should make it very clear how DA enables people to make intelligent process decisions. It does this by making the process factors that you need to consider explicit and it indicates potential strategies/practices to consider to address each factor. In some cases these strategies are ordered (this is indicated by the arrow).
- Improves the efficiency of retrospectives. During a retrospective your team may identify that it needs to improve it’s approach to exploring requirements, or to evolving the architecture, or to testing the solution. The goal diagrams can provide quick references to help the team identify potential improvements that they might not have been aware of otherwise.
- Enables effective tactical scaling. DA provides a foundation from which to tactically scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. See the article Exploring Initial Scope on Disciplined Agile Teams for a more detailed discussion about addressing this goal at scale.
- Makes your process options very clear. Figure 1, in combination with the more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.
- Takes the guesswork out of extending agile methods. The goal diagrams make it very clear that you have a range of options available to you, and the DAD book provides the detailed context-sensitive advice which supports the diagrams. Other aspects of DA, such as promoting a full delivery lifecycle, enterprise awareness, and adopting a hybrid framework also support the extensions you require to truly support agile at an enterprise level.
- Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DA makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DA is going to make it very clear what risks you’ve just taken on by doing so. DA also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.
- Enables process assessment. Many teams are interested in answering the question “how are we doing?” The process goal diagrams, at both the delivery team level (e.g. the Address Changing Stakeholder Needs goals) and at the IT level (e.g. The Data Management process blade), provide easy and comprehensive “look up charts” against which a team may be assessed.
This goal-driven approach helps teams to determine what strategy is best for them given the situation that they face. This in turn enables them to reduce the time they would otherwise spend on process-related issues and instead invest that effort into producing consumable solutions for their stakeholders. Isn’t that what it’s really all about?