This is the governing body for certification in Disciplined Agile.

Chapter 3 Disciplined Agile Delivery in a Nutshell

  • 18 Nov 2018 8:23 PM
    Reply # 6913284 on 6875905
    Scott Ambler (Administrator)

    @Joshua - Good catches!  Thanks.

  • 16 Nov 2018 2:29 PM
    Reply # 6910936 on 6875905

    Version #3

    Page 4, Specialist: “User experience (UX) and security experts are specialists who may be on a team with there is significant user interface (UI) development or security concerns respectively.” … with to when

    Page 7, Table 1.1, Scrum Column: Scrum meeting to Daily Scrum (per the Scrum guide…) and there is no mention in the guide of Customer, closest to a domain expert may be the Product Owner??  Or maybe leave blank with a dash since not explicitly noted?

    Also, could consider adding in a column for SAFe since it is so prevalent… 

    • Solution Architect
    • Daily Standup
    • Product Owner
    • Iteration
    • Product Owner
    • Customer
    • Team (or agile team)
    • Scrum Master 
  • 29 Oct 2018 9:44 AM
    Reply # 6877866 on 6875905
    Scott Ambler (Administrator)

    Great feedback.


    • It's 6 lifecycles.  We've had some inconsistencies but I think they're fixed now.
    • Good catch on SDCF.  It was in fact in chapter 2 but not called out specifically.


    • Good stuff.
    • I really like the shift left suggestions.  I'd argue it's really stakeholder feedback shifting left and stakeholder involvement shifting right.  This is something we'll discuss in Chapter 7 in the Shift Left/Right section.


    • Lots of good ideas that we've acted on.
    • We've updated the hybrid brick diagram.
    • The idea to update the goal diagram notation is very interesting, but we need to try it out in practice first.  Could end up being a 2019 update to the diagrams but it's too late in the game for this book.  
    • Didn't update Figure 3.4, although we've received feedback on that elsewhere so maybe it will evolve when we act on that.

    We'll be posting an update to chapter 3 very soon.

  • 28 Oct 2018 4:24 PM
    Reply # 6876994 on 6875905

    On page 8 you refer "Software Development Context Framework (SDCF)" to chapter 2. But I could not find that reference in chapter 2. 

    Were you not possibly wanted to refer to "Figure 2.2. Context factors that affect WoW choices" in chapter 2?

    Else you need to clarify in chapter 2 that "Software Development Context Framework (SDCF)" includes "Context factors"

    Last modified: 28 Oct 2018 4:26 PM | Jaco Viljoen
  • 28 Oct 2018 4:19 PM
    Reply # 6876991 on 6875905

    In "Table 1.1. Mapping some of the varying terminology in the agile community" please consider adding:

    1) Product Owner (PO, PO, PO, Customer Representative, Stakeholder)

    2) Architecture Owner (AO, ?, ?, ?, Senior Developer)

    I am not sure what the exact mapping in terminology would be, but feels that these would be helpful to define as well.

  • 28 Oct 2018 4:13 PM
    Reply # 6876987 on 6875905

    In chapter one (p4 bottom) you state that DAD supports "5" lifecycles (also see figure 1.1). In chapter three (p6 bottom) you state that DAD supports "6" lifecycles (also see figure 3.5). Was this inconsistency intentional?

  • 28 Oct 2018 7:04 AM
    Reply # 6876555 on 6875905

    Intro – DAD resulted process: leaner and more effective in the context

    Somewhere in the sections Complete and Context-sensitive could be a good idea to mention that by having guidance for selecting choices considering tradeoffs in context, the resulted process approach will be streamlined: more effective and leaner.

    Or better, could be a conclusion of the introductory section.

    Team Lead vs Scrum Master

    “This is similar to the Scrum Master role in Scrum.” with the differences that will have a better understanding, experience and could lead by example. TL is solidary responsible with the other team members, where the SM responsibility is fuzzy.

    Consumable Solutions Over Working Software– usable suppose two parts

    It’s usable. The users are iteratively involved in knowing and using the system. They could give an informed and valuable feedback and will be prepared at release.   ~ Shift left user/customer involvement.


    It’s Easy to Get Started with DAD – collaboration guidance help

    Having more choices in collaboration techniques, the improvement of this part can be a great start for overall WoW improvement. Effective collaboration is the base for WoW improvement.


    It’s Easy to Get Started with DAD – understand the current process

    With DAD guidance a team could easily and better understand their current WoW approach as a base for future improvements.  

    Summary – using other methods

    ~ above sentence. “If you are using Scrum, XP, or Kanban”, with DA guidance you can understand better how you are using in context, if something is missing or if can be improved.  

  • 27 Oct 2018 10:04 AM
    Message # 6875905

    I saw you posted Chapter 3 Disciplined Agile Delivery in a Nutshell.. another really good chapter.  A few thoughts:

    Chapter 3 Disciplined Agile Delivery in a Nutshell

    Page 2

    #2. Very small change but may consider putting SAFe right after Scrum since there is so much awareness of it now and having it up front in the list would make it prevalent.  I think unfortunately in lists like these many people see them like ingredients lists on a food product, the ones early in the list have a higher concentration, or cover more of it, etc….


    #4.Support for multiple lifecycles. DAD supports agile, lean, continuous delivery, exploratory, and large-team versions of the lifecycle (some context may be missing ... large-team versions of these lifecycles, or all lifecycles, or specific one). DAD doesn’t prescribe a single lifecycle because it recognizes that one process approach does not fit all. Chapter XX explores lifecycles in greater detail.  Could consider adding a tiny bit more “and strategies for evolving from one to another…)

    #5.Could consider adding to the list requirementsor user outcomes… this could be something that could be quickly spotted by someone with a traditional background as not included…

    Page 3

    #1. Could add in a few words on why things have been renamed such as “from literally 10s of thousands of projects around the globe we have validated learnings that guided the evolution…”


    Last paragraph, 2ndsentence: We put these techniques into context, exploring fundamental issues(I know I mentioned this in other comments, but I want to be consistent J… maybe have this as “tradeoffs” and not refer to it as an issue?) such as what are the advantages and disadvantages of the technique, ….

    Page 5

    Figure 3.2, just like comment above, could consider putting the frameworks/approaches that have a lot of awareness right now up top, Scrum, SAFe, DevOps…   In training/coaching I usually find it helps to set context, oh you know Scrum or have heard a lot about SAFe, great - DA leverages the best parts of them and points out some of the disadvantages….

    Figure 3.3, I know I mentioned this on slack, but just a revisit to possible sequencing of the goals by when a Team would likely start work on them (not finish).  I have found that to be quite helpful when coaching new teams and how the outcomes from goals have reciprocal relationships, as work is done on one, it provides information needed for others, which then may evolve the work on the other, etc.  I know page count is a big consideration and more content may not be right for this point in the writing… but the attached slide is just some thoughts I have been working on.  The thought here was to try to lay out a relative starting point for a team using the agile lifecycle, are new to agile, need training, coaching, etc…. Sequencing on this still needs another pass (or 2) but as a concept it is a visual that provides some example timing.  I have white boarded this many times with teams to provide context on what we need to plan for and think through…. What is not easily done on a graphic but is on a board is the then draw some lines showing the time span we maysee in practice, arrows for once we learn X in this goals outcome we then understand more of Y, etc…

    Page 6

    Figure 3.4 Reuse Enterprise Assets Decision, could consider an add in “Share assets” as a way to have teams contribute to the enterprise assets and constantly improve their quality… grow and evolve enterprise asset quality? Tying into enterprise awareness and support …But coverage is already in Evolve WoW Goal -> Share Improvement with Others as well as Leverage and Enhance Existing Infra -> Work with Process Assets-> Share process learnings

    Page 9

    Summary, could consider an add into the bullet section that DAD can support your evolution from Scrum, XP, … as well as strategies for evolution from one of the DA lifecycles to the next (agile -> continuous delivery…)

    1 file

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software