Disciplined Agile

Choice is Good: A Goal-Driven Approach

DAD’s goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD then indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.

In the first DAD book we described goals in a non-visual manner using tables which explored the advantages and disadvantages of the techniques associated with an issue. In the second half of 2012 we began expanding on this approach and developed a way to represent goals in a visual manner using what we call a goals diagram (see Disciplined Agilists Take a Goal-Driven Approach for a detailed discussion of the notation).

Let’s work through some examples. Figure 1 depicts the goal diagram for Explore Scope, a goal that you should address at the beginning of a project during the Inception phase (remember, DAD promotes a full delivery life cycle, not just a construction life cycle). Where some agile methods will simply advise you to populate your product backlog with some initial user stories the goal diagram 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)? Default techniques, or perhaps more accurately suggested starting points, are shown in bold italics. 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 DAD we make it clear that agile teams do more than just implement new requirements, hence our recommendation to default to a work item stack over Scrum’s simplistic Product Backlog strategy. Finally the goal diagram 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.

2021 Project Management Institute Explore Scope v5.3 Explore Purpose Ideathon Ideation board Impact map Mind map Modified impact map Outcome Really round robin Value proposition canvas Explore Usage Design sprint (User experience (UX)) Epic Persona Unified Modeling Language (UML) use case diagram Usage scenario Use case User story User story map Explore the Domain Domain/conceptual model Event storming Glossary Logical data model (LDM) UML class diagram Explore the Process Business process diagram Data flow diagram (DFD) Flowchart UML activity diagram UML state chart Value stream map Explore User Experience (UX) Design sprint (user experience (UX)) User interface (UI) flow diagram UI prototype (high fidelity) UI prototype (low fidelity) UI specification Explore General Requirements Business rule Context diagram Feature statements Impact map Mind map Modified impact map Shall statement Value proposition canvas Explore Quality Requirements Acceptance criteria Explicit list Technical stories Apply Modeling Strategy(ies) Agile Modeling (informal) sessions Open space Joint application requirement (JAR) sessions Interviews Choose a Backlog Management Strategy Lean backlog Agile backlog Requirements (product) backlog Unsequenced backlog None Level of Detail of the Scope Document Outcome driven Requirements envisioning (light specification) Detailed specification No document

Figure 1. The goal diagram for the Explore Scope process goal.

Clicking the diagram opens the interactive DA Browser where you can learn more about all goals, decision points and options of DA.

There are several fundamental advantages to taking a goal driven approach to agile solution delivery, in that it:

  • Supports process tailoring by making process decisions explicit.
  • Enables effective scaling by guiding you through tailoring your strategy to reflect the realities of the scaling factors which you face.
  • Makes your process options very clear and thereby makes it easier to identify the appropriate strategy for the situation you find yourself in.
  • Takes the guesswork out of extending agile methods and thereby enables you to focus on your actual job which is to provide value to your stakeholders.
  • Makes it clear what risks you’re taking on and thus enables you to increase the likelihood of success.
  • Hints at an agile maturity model (this may not be a benefit).