This is the governing body for certification in Disciplined Agile.

Chapter 5: Process Goals

  • 29 Oct 2018 10:37 AM
    Reply # 6877934 on 6721765
    Scott Ambler (Administrator)

    Thanks for all the feedback, here are some thoughts:

    • This is now Chapter 6 as we've decided to insert a chapter (4) on roles, rights, and responsibilities.  We should get that out later this week.
    • We've added a Tony Robbins quote at the top of the chapter.  What has my life come to?  ;-)
    • @Drennan - Thanks for pointing out the bolding/italics issue.
    • @Joshua - Thanks for the intro rewording.  Good points about needing to mention lightweight tailoring.
    • @Charlie - The idea of updating the diagram notation that way is a good one, it's something we'll need to experiment with and see how well it works in practice before we start to apply it across the board.
    • @Jaco - We used a Construction phase example in Chapter 3 so we wanted to mix it up a bit and use an Inception goal here.
    • @Jaco - Do you think a second version of the example that indicates only the choices that the team has chosen with help with making it clear that you only adopt the ones that make the most sense for your situation?


  • 28 Oct 2018 6:30 PM
    Reply # 6877122 on 6721765

    Should you not also define "Process Blade" somewhere in this chapter? It is used in subsequent chapters...

  • 28 Oct 2018 5:39 PM
    Reply # 6877027 on 6721765

    A point that did not come through clearly for me is that one select from the phases and process goals and do not have to do all of it. I might be wrong but my impression from reading the chapter is that one only select from the strategies in the process goal diagrams.

    PS. Maybe an option table is needed for selecting the phases and goals.

  • 28 Oct 2018 5:35 PM
    Reply # 6877022 on 6721765

    The example you used is from inception phase. I would rather use an example from construction phase (i.e Produce a Potentially Consumable Solution) to illustrate the point. It might be more familiar to the reader...

  • 25 Oct 2018 5:52 AM
    Reply # 6872739 on 6721765

    Process Goal Notation.
    During my recent course we were talking about the “Explore Usage” decision point in the “Explore Initial Scope” goal.  The "Use Cases" option was stated by Mark as a poor choice, but the process goal diagram did not reflect this.

    All non-ordered options are alphabetically sorted.  As such, I assume that some process diagrams show poor options at the top of the list.

    I was thinking that some kind of “Preference Group Separator” between the options might be an solution to this problem.  See attachment.

  • 24 Oct 2018 2:32 PM
    Reply # 6871906 on 6721765

    Page 2: Intro:

    I found the intro was a little hard to read, not sure it would be easy for readers to glean the value of this approach easily.  I swapped a few of the sentences around as an attempt to make it a little easier to:

    Disciplined Agile Delivery (DAD) takes a light-weight approach to support teams in choosing their way of working (WoW).  Process goals guide teams 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.  Some people like to call this a capability-driven approach, a process outcomes-driven approach, or a vector-driven approach.

    The DAD approach starts with process goals which defining high-level process outcome, such as improving quality or exploring the initial scope, without prescribing how to do so. Instead a process goal indicates the issues you need to consider, what we call decision points, and some potential options you may choose to adopt.

    Process goals guides teams 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. Process goals are a light-weight approach to support teams in choosing their way of working (WoW), and are a critical part of Disciplined Agile (DA)’s process scaffolding.

    Page 2

    One thing that I think is important that is not covered in the chapter and may work nice in this first page is some context on going teams thinking and working through this approach should:

    • NOT need to spend days doing this, a few hours for Inception goals first time, etc.
    • Does not need to be perfect, choose and experiment, adapt as necessary based on results
    • A goal(s) can be revisited at any time based on results and choice of option updated, NOT done once and carved in stone…


    Page 3 - 2nd bullet / Page 4 - 2nd bullet

    Using the word issues -  “… of the issues you need to…” makes it seem like there are already issues.  It may read better as something like …of the aspects you need to... or another word that conveys areas of focus that are important to do a bit of critical thinking through.

    Page 8 / Summary

    Could add a sentence or 2 about how teams use this approach in practice and how simple yet powerful it is, such as:

    • Printing out on paper, using a high-lighter to capture decision, hang on team room wall
    • Using a spreadsheet or something like a Quip doc to capture
    • The new DA tool?


  • 20 Oct 2018 8:58 AM
    Reply # 6826103 on 6721765

    But This is so Complex! / How to Apply Process Goals in Practice - notes

    Just a few notes, maybe will help to address this "complexity" issue. 

    The process goals & options & associated guidance are is like a map. You will use the map when you face the unknown or to make improvements. The knowledge, the choices and the WoW itself can and will be reused when the context is stable or known. The effort to build & improve the WoW is “distributed” in time.

    The set of goals, factors that need decisions exist anyway. We will want to be rather aware of our choices and options. We will want to make an improvement in time, to exercise new practices. We will rather want to make informed choices.

    In a specific context, some goals and factors will be more important than others and will need our focus. For example, if the quality is very important in a specific context (product, customer) we can investigate and experiment more on process goals related to this aspect.

    And, last but definitely not least, the resulted process will not be complex, but rather lean. We need to be informed in order to build a lean & effective process.      

  • 15 Oct 2018 2:28 AM
    Reply # 6728387 on 6721765

    Looks great. Formatting of the options table, might want to check out. In some tables the decision points are in bold and italic (which i love) and some are not bold, some bold but not italic, some in italics not bold, etc. In this chapter the decision point description is also in italics and the decision point is not bold. I'm sure these are small things that would have been corrected anyway but just wanted to highlight as they are so critical as you skim through them to weigh your options.

  • 14 Oct 2018 2:08 PM
    Message # 6721765
    Scott Ambler (Administrator)

    We just published the chapter overviewing process goals.  It's a short one.

    Looking forward to your feedback.

© 2013-2019 Project Management Institute, Inc.

600 Crowfoot Crescent NW, Suite 340

Calgary, Alberta, CANADA  T3A 5A2

Powered by Wild Apricot Membership Software