This is the governing body for certification in Disciplined Agile.

Chapter 7: Choosing the Right Lifecycle

<< First  < Prev   1   2   Next >  Last >> 
  • 28 Oct 2018 5:52 PM
    Reply # 6877049 on 6826124
    On page 4 you describe the broader system/product lifecycle. However, figure 7.3 only refers to system lifecycle and not "product". SHould it not maybe read "Figure 7.3. The system/product lifecycle (high-level)."
  • 22 Oct 2018 2:36 PM
    Reply # 6857563 on 6826124

    Chapter content reads great, a few thoughts…

    Page 4

    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…

    Page 5

    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?

    Page 6

    • 1.     The Inception Phase – up to this point in the chapter, the graphic like 7.2 shows 1 (or more) iterations to get going in the right direction but iterations are introduced in the next numbered section for Construction.  May not cause confusion but it appears that iterations start in Construction…

    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?

    Page 7

    <<see attached file for graphic>>

    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.

    Page 8

    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?

    Page 10

    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…

    Page 11

    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”.

    Page 13

    Figure 7.12 – is the 3rd Subteam #3?  Subteam 1 is in their twice…

    Page 17

    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.

    1 file
    Last modified: 22 Oct 2018 2:43 PM | Joshua Barnes
  • 20 Oct 2018 11:43 AM
    Reply # 6826419 on 6826124

    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

    • Introduce a work pool & Kanban flow visualize inside the iteration
    • Focus on opportunistic look ahead to make the work Ready over the Iterations starts

    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

    • In picture 7.17 seems to be referred Advanced Lean
    • n picture 7.15 for Culture related axes, seems to be referred the not-advanced Lean case. 

    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.  

  • 20 Oct 2018 9:15 AM
    Message # 6826124
    Scott Ambler (Administrator)

    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:

    1. We've updated the lifecycles
    2. We've added a Program lifecycle
    3. We provide advice around how to select the right lifecycle for your situation.
<< First  < Prev   1   2   Next >  Last >> 

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software