This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
Chapter content reads great, a few thoughts…
Figure 7.2, the iteration representations in the graphic appear to have time between each iteration, especially in-between phases. Consider a graphic revision such as:
<<see attached file for graphic>>
1st paragraph, 2nd sentence: “The need to invest some time at the beginning to get going in the right direction (Inception/Sprint 0)…
2nd paragraph, last sentence: Disciplined Agile (DA) has strategies and guidance which encompasses…
Figures 7.4: could consider increasing the size of the Agile/Lean Project Lifecycle, it looks like Inception is lining up with the Architecture phase in the serial lifecycle and Transition ends with the Test phase… or if it is intended to shrink for this and then continuous maybe just add a thin dashed line on each side at an angle to have a visual cue?
Somewhat trivial point, but the numbering to me reads a bit like a sequence 1-8, could consider using bullets since these are just key points of the lifecycle?
Could consider an update to figure7.6, similar to 7.2, I have experienced some confusion that the “scrum” lifecycle at the top spans the entire construction phase vs. it being a representation of what teams do each iteration. I added in the same small iteration elements just above the phases and then a lasso around the first iteration of Construction as a way to illustrate this occurs each iteration… this is how I usually describe it in coaching sessions or training to reinforce that we will do this part of the graphic each iteration in Construction…
DAD’s Lean Lifecycle – could add in to the first paragraph that this can also be a nice step for team’s using the agile lifecycle to move to working on a stream of work as they evolve from small batches for flow but are not ready or possibly for continuous delivery (either lifecycle) and still work in a project pattern.
Continuous Delivery – could consider adding in a sentence or maybe another short paragraph in the list below that conveys a little more context on the evolution of the team – they need to have discipline and experience to do continuous delivery… need to be somewhat high performing at least. Just read page 15, team skills… could add that sentence in here possibly as well?
Could consider also a small bit of context that the exploratory lifecycle is also valuable when organizations have down selected candidate vendors in an RFP process, giving the short list of vendors a problem to solve and prove their approach… running multiple in parallel to get real transparency into the vendors capabilities…
Figure 7.11… I have liked this graphic and have used it frequently. One thing I have been getting some success with is also discussing an “MVO” minimum viable outcomes. This could be an add and tie back to small summary on page 9 “Outcomes Lead to Continuous Exploration”.
Figure 7.12 – is the 3rd Subteam #3? Subteam 1 is in their twice…
Sufficient Functionality: one of ways I often explain the sequencing of the work in the Construction phase based on both business value and risk by the PO and how that plays into sufficient functionality is tying back to a higher-level scope mechanism (feature, outcome, etc.) which can take multiple stories to be implemented to cover the minimum of a business process/function. Teams may implement 1 or more stories in the early construction iterations but to be potentially releasable the outcome requires a minimum of the process to provide value to users. E.g. simplistic example if I can go to a web portal and search and find a product I want to purchase, if I cannot add it into a cart and the pay and ship the “search” story provides no value as a user…. May consider adding in some context to reinforce that for a new feature, it may take multiple stories and therefore multiple iterations before that minimum value is able to be released.
Lean – opportunistic look ahead
In this case, the life-cycle is longer than Continuous Delivery, so beyond JIT, we still need some opportunistic look ahead to keep the work pool prepared and avoid surprises and waiting. We still need coordination with the stakeholders and that could not be done without look ahead.
One of the main seven wastes to avoid (Toyota Production System) is the waste because waiting. That could happen if the work pool is empty, that means that incoming work is not Ready.
Example: when we want to move from Agile to Lean, we can do for starting these two things
This is important for “not advanced” lean teams (see below) that could be really hurt by disregarding this aspect.
Two kind of Lean (!): different positions versus Agile
Not advanced Lean – when the team have an ad-hoc ceremonial but are not so aware of their work results and enough skills to streamline the work. In this case, Agile will be the next step in improvement.
Advanced Lean – when the team uses the ad-hoc ceremonial as a method to streamline the work and their skills support that. The next improvement could be Continuous Delivery
VERY IMPORTANT – content consistency possible problem
Maybe some clarifications are needed. In the workshop, (by its nature) Lean life-cycle is the least intuitive at first encounter.
Program life-cycle – teams WoWs matching
I think could be useful to put some references to DA guidance about how different life-cycles could fit together when the team with different WOWs are collaborating.
Choosing the life-cycle – Exploratory: solution incertitude
There are two main reasons to select this life-cycle: high incertitude about what the customers’ needs and high incertitude about the technical solution. The later is missing from the picture.
We've just posted Chapter 7, Choosing the Right Lifecycle.
We're looking forward to your feedback.
I suspect you'll find this chapter interesting for several reasons:
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA