This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
Thanks for all the feedback, here are some thoughts:
Should you not also define "Process Blade" somewhere in this chapter? It is used in subsequent chapters...
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.
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...
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.
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.
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:
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:
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.
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.
We just published the chapter overviewing process goals. It's a short one.
Looking forward to your feedback.
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA