Disciplined Agile

How to Read Process Goal Diagrams

The Disciplined Agile (DA) tool kit 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, given the context of the situation that they face, to achieve the outcomes that they desire. Let’s work through four topics:

  1. Goal diagram notation
  2. Examples of goal diagrams
  3. Important concepts regarding goal diagrams
  4. The benefits of a goal-driven approach

Goal Diagram Notation

The goal-diagram notation is summarized in Figure 1.

Process Goal Notification

Figure 1. Goal diagram notation overview (click to enlarge)

Let’s explore the notation of goal diagrams:

  1. Process goal. A process goal is indicated using a rounded rectangle on the left side of the diagram.
  2. Decision point. A decision point is represented as a squared rectangle, and each process goal has two or more decision points.  A decision point is an intent that you need to consider addressing. You may choose not to address some decision points, but you should at least consider them. Decision points were formerly called process factors or process issues.
  3. Option. An option is a technique such as a practice or strategy.  Each decision point is potentially addressed several options, which are shown to the right of the decision point.
  4. Default option. A “default option” is depicted in bolded italics. These are suggested starting points for a team that is tasked with a relatively straightforward domain problem to address. If that is not your situation then the default options may not be appropriate for you.
  5. Ordered option list. These option lists are indicated by an upwards pointing arrow to the left of the list. This is an indication that the options appearing at the top of the list are more desirable from the point of view of agile and lean thinking and the less desirable options 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. Typically, when the options are ordered you will only choose one of them. Ordered option lists provide you with clear improvement options for a given decision point.
  6. Unordered option lists.  A list of options that does not have an arrow to the left of it. While each option has its advantages and disadvantages, we can’t say that some options are generally more effective than others. It is common to choose several options from unordered lists.

Examples of Goal Diagrams

Figure 2 depicts the goal diagram for Explore Scope, a goal that you should address at the beginning of an endeavor (remember, DA supports both project and product life cycles). Where some agile methods will simply advise you to populate your product backlog with some initial user stories, the goal diagram of Figure 2 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 to 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 2 makes it clear that when you’re exploring the initial scope of your effort that you should identify quality requirements — such as reliability, availability, and security requirements (among many) — in some manner.

Explore Scope

Figure 2. The Explore Initial Scope Process Goal (click to enlarge) 

Figure 3 depicts the goal diagram for the Asset Management process blade. The DA tool kit takes a goal-driven approach to all process blades, not just team-level process goals.

Asset Management- Goal Diagram

Figure 3. The Process Goal Diagram for Asset Management (click to enlarge) 

Important Concepts Regarding Goal Diagrams

A few important points about goal diagrams:

  1. 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. The DA tool kit evolves over time, exactly as you would expect.
  2. Each option has tradeoffs. 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 Disciplined Agile Browser provides detailed advice about the strategies and practices identified in the goal diagrams.
  3. 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 tool kit 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.
  4. 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.

The Benefits of a Goal-Driven Approach

Our experience is that there are several fundamental advantages to taking a goal-driven approach to describing the Disciplined Agile (DA) tool kit. A goal-driven approach:

  1. Provides straightforward process improvement guidance. Process goal diagrams make it very clear how to make intelligent process decisions. Process goal diagrams do this by making the process factors that you need to consider explicit, and they indicate potential strategies/practices to consider addressing for each factor. In some cases, these strategies are ordered, this is indicated by the arrow, providing you with a clear improvement options for that factor.
  2. Improves the efficiency of retrospectives. During a retrospective your team may identify that it needs to improve its approach to exploring requirements, or to coordinating with other teams, or to improving the quality of their work. The goal diagrams can provide quick references to help the team identify potential improvements that they might not have been aware of otherwise.
  3. 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.
  4. Makes your process options very clear. Process goal diagrams make it very clear what you need to consider when tailoring your way of working (WoW) to meet the unique needs of the situation faced by your team.
  5. 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 Disciplined Agile Browser provides the context-sensitive advice which supports the diagrams. Other aspects of DA, such as promoting a full delivery life cycle, enterprise awareness, and adopting a hybrid tool kit also support the extensions you require to truly support agile at an enterprise level.
  6. 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. 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 stakeholder value and here’s why” will be listened to.
  7. Enables process assessment. Many teams are interested in answering the question “how are we doing?” The process goal diagrams provide easy and comprehensive “look up charts” against which a team may assess how well it works. 

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 value for their stakeholders. Isn’t that what it’s really all about?