In this posting we explore the goal-driven aspect of the Disciplined Agile (DA) toolkit. This 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 also indicates that there are several process factors/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.
We start by describing how to visualize goals. We then summarize the goals called out by DAD, a topic we’ve written about in the past so we only cover this topic briefly here. We end with a summary of the advantages and disadvantages of a goal-driven approach over the more prescriptive approaches of older agile methods.
Visualizing Goals
In the original DAD book we described process goals in a non-visual manner using tables which explored the advantages and disadvantages of the techniques associated with a process factor. Since we wrote that book both Mark and I have spent a lot of time helping people to understand what a goals-driven approach entails and we’ve found that many people respond well to visual representations of a process goal. Yes, the process decision tables are very important but a visual overview helps to provide context for the detailed information.
In the second half of 2012 we began developing a way to represent goals in a visual manner using what we call a goals diagram. A goals diagram, the notation for which is summarized in Figure 1, is in effect a form of decision tree. In Figure 1 you see that a process goal is indicated using a rounded rectangle and the decision points pertaining to a goal with normal rectangles. Process goals will have one or more decision points 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 1 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 1. The notation of goal diagrams.
Let’s work through some examples. Figure 2 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, DAD 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 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 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 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 Figure 2 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 2. Exploring the initial scope.
Figure 3 depicts one of the goals that you should address during the construction phase, in this case Address Changing Stakeholder Needs. This is an iteresting example for two reasons. First, it captures the key decisions surrounding the second of the 15 principles of the Disciplined Agile Manifesto, that of welcoming changing requirements. Second, it has a decision point that overlaps with that of another goal, in this case we indicate that your Work Item Management Strategy is important to consider for both this goal and Explore Initial Scope (see Figure 2).
Figure 3 makes the process factors surrounding how to address changing stakeholder needs very explicit. How are you going to prioritize changes? A business value approach is one option, the approach popularized by Scrum, but we’ve found that the risk-value approach promoted by Unified Process (UP) to be a more robust strategy that leads to greater chance of agile project success. There’s advantages and disadvantages to each technique so you’ll want to choose the one best for you. When are you going to accept the change? During the current iteration as Extreme Programming (XP) suggests or a future iteration as Scrum suggests? Do changes come directly from stakeholders or via a proxy such as a product owner or business analyst? How will your team elicit changes (via modeling, demos, …)?
Figure 3. Addressing changing stakeholder needs.
.jpg)
The advantage of visualizing goals as we’ve shown in Figures 2 and 3 is that it makes it very clear what process-related decisions you need to make and what options you have available to you. The disadvantage of this sort of diagram is that they get fairly big at times, as you can see. This effectively prevents us from taking the diagrams one step further to indicate the trade-offs associated with each technique and as a result you’ll still need the text tables we included in the DAD book for that.
The Goals of DAD
In the previous section we indicated that there are many goals called out by DAD, Figure 4 summarizes these goals, which have evolved slightly from what we published in the book (we refactored a few to make them more consumable). Notice how each of the three phases (Inception, Construction, and Transition) are described by specific goals. Also notice how some goals, such as Grow Team Members and Address Risk, are applicable throughout the entire lifecycle.
Figure 4. Goals throughout the lifecycle.
Mark Lines’ post Being Goal-Driven Requires Discipline explores the history of the figure above if you’re interested in how the goals have evolved since the DAD book was published.
The Advantage of Goals Over Prescription
First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that 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. Our experience is that there are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:
- Supports process tailoring. I think that Figures 2 and 3 make it very clear how DAD enables people to make intelligent process decisions. I think that this is a huge improvement over previous process frameworks, particularly Rational Unified Process (RUP) that provided a lot of great process advice (regardless of what some agilists may claim) but struggled to provide consumable process tailoring advice.
- Enables effective scaling. DAD provides a foundation from which to 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 (the goal captured in Figure 2). A large agile 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. These are just three of several scaling factors (more on this in a future blog posting, although you may postings in my agility at scale blog to be of interest).
- Makes your process options very clear. Figure 4, in combination with the more detailed goals diagrams (such as in Figures 2 and 3) 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. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the toolkit cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?
- 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, DAD 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 DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD 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 first 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.
- It hints at an agile maturity model. We have written about how DAD and CMMI potentially fit together. In that article I suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that I have no desire to wade into the agile maturity model morass, but I think it’s an important observation nonetheless.
So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
We hope that this blog posting has given you some food for thought that you can leverage on your next agile project. Got Discipline?
