Process Goals

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 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.  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:

  1. The process goals
  2. Process goal diagrams
  3. The benefits of a goal-driven approach

 

The Process Goals

Figure 1 summarizes the delivery-oriented process goals of the DA process decision framework via a mind map.  There are twenty-two goals in total, each of which is described by a Process Goal Diagram (see Figure 2 below for an example).  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).

Lifecycle Goals

 

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). 

Timing Goals
Inception
Construction
Transition
Ongoing

 

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 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 2. Goal diagram notation overview.

Goal diagram notation

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 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 DA 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 3. The Explore Initial Scope Process Goal.

Explore Initial Scope
A few important points about these 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.
  2. 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.
  3. 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 by the goal diagrams (which is the primary reason that the printed version of the book is a bit over 500 pages).
  4. 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.
  5. Defaults are shown in bold.  We recognize that the goal diagrams can be a bit overwhelming at first.  To help address that we’ve indicated default 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 agile solution delivery.  A goal-driven approach:

  1. Provides straightforward process tailoring guidance. Figure 2 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).
  2. 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.
  3. Enables effective scaling.  DA 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.  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.
  4. 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.
  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 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.
  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.  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.
  7. 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?

11 thoughts on “Process Goals

  1. Joanna

    I find the explanation and organization of the process goals well done here, easy to follow (and a great reference!). I was wondering if you were planning to add something similar for the milestones, in future? And perhaps show how they complement the goals?

    Reply
  2. Pingback: What Makes a Good Disciplined Agile Delivery Coach? | Disciplined Agile Delivery

  3. Pingback: What Makes a Good Disciplined Agile Delivery Coach? | Toocan

  4. Pingback: Large Agile Teams | Project Management Buzz

  5. Pingback: Does your team own its process or merely rent it? | Disciplined Agile Delivery

  6. Pingback: Put Practices in Context: #NoBestPractices | Disciplined Agile Delivery

  7. Alistair Thomas

    I have been interested in DAD for a few years and normally follow the lifecycle which I used to do from my days following http://www.ambysoft.com/unifiedprocess/agileUP.html, but I don’t always check I’m meeting all the goals, although I do find myself naturally doing the majority of the recommend approaches where possible (I’m from an XP background so that helps). I like the structure of the website now – much easier to navigate around so I’m sure I’ll find it easier to review the goals, so good work on that!

    I have often wandered if you recommend teams that follow DAD keep a track of how they have decided to approach each goal and if so if there is a format (Excel file or somewhere online for example) that people have used to track this? I’d imagine it would be a good thing to keep update so you keep thinking about how you are approaching you project and could be used to good effect if reviewed from time to time at retrospectives .

    Reply
    1. Scott Ambler Post author

      Alistair, thanks for the feedback. To answer your question, it depends. 😉 We’ve seen a few teams record their decisions, often as a Wiki page, but the vast majority don’t seem to track this. It’s more common in regulatory situations as many regulations push you to have a documented process and evidence that you followed the process. Of course you want to keep this as light as possible.

      A far more common strategy, as you allude to, is to keep track of how (if at all) you adopt the potential improvements that you identify during retrospectives. This is a strategy that we captured in the framework called “measured improvement” and it tends to lead to better improvement than retrospectives alone.

      Reply
  8. Gopinath

    Goals seem to be the only prescriptive component in this framework. Can we have some guidance on how to choose goals depending on the project context. A table (similar to that of practice options) listing the pros and cons and impact of each goal will be helpful.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *