@Joshua - Good catches! Thanks.
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…
We'll be posting an update to chapter 3 very soon.
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"
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.
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?
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.
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
#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…
#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, ….
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…
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
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…)
© 2013-2019 Disciplined Agile Consortium
600 Crowfoot Crescent NW, Suite 340
Calgary, Alberta, CANADA T3A 5A2