This is the governing body for certification in Disciplined Agile.

Chapter 7: Choosing the Right Lifecycle

<< First  < Prev   1   2   Next >  Last >> 
  • 05 Nov 2018 8:55 AM
    Reply # 6889407 on 6826124
    Scott Ambler (Administrator)

    @Jaco:

    • We'll update the "Each team can choose their WoW" point to indicate that this includes choosing their own lifecycle.
    • There is more about lifecycles in the Evolve WoW process goal.
    @Valentin:
    • We'll flesh out the description of Exploratory, I like the point of exploring options for software acquisition.  Similar to running several PoCs in parallel as was pointed out before.


  • 31 Oct 2018 3:53 AM
    Reply # 6882116 on 6826124

    @Scott - "For Exploratory, it is typically used for high incertitude requirements." - one example is a F-35 kind of project. If solution approach has a very high incertitude, you are even not sure about requirements, because maybe you cannot keep the initial ones. 

    An simpler example that is more software specific. I was involved in a exploratory phase for DoD software acquisition. That could be useful for any significant software acquisition done by the state, or by a private company. They are using this kind of approach:

    - "phase" 1 : they select some possible contractors based on their previous experience and based on "paper" offers

    - "phase" 2 : 2-3 or more selected contractors will build some prototypes and makes demonstrations based on requirements

    - "phase" 3 : the final contract is awarded to one of the competitors

    That it inspired by Spiral life-cycle, but could be useful to find an equivalent in Agile, because could be a very common approach in big software acquisitions.

    In the above model we have in fact two "projects":

    - "phase" 2 with high incertitude even about term and costs, but should be anyway much lower that putting them in Phase 3. Sometime the development side should "invent" some part of the solutions. The result is a kind of MVP, but in prototype form. Inside this phase should be many demonstrations of working software.

    - "phase" 3 - productization - is more close to a "standard" project (but could have also an Exploratory part)

    It is variant of the more common situation where:

    - Exploratory will produce the MVP

    - Next releases with a more common life-cycles will enhance the project

    In described case we have two MVPs and two exploratory phases: one for prototyping and one for production MVP.

    In many cases, they need this "phase 2" because high incertitude related to the solution side and the associated risks and costs.

  • 31 Oct 2018 3:12 AM
    Reply # 6882076 on 6826124

    Something that is not answered in this chapter for me is what would the Subteam's lifecycles look like in context of the DAD Program lifecycle.

    For example, could we have some lean subteams working together with some agile subteams (SAFe has some guidance on this), or could the subteams have transition phases even though the program lifecycle do not have a transition phase, etc.?

    Do you plan to have more on the lifecyles later in chapters, or is this chapter it? :-)

  • 30 Oct 2018 5:51 AM
    Reply # 6879176 on 6826124
    Scott Ambler (Administrator)

    Thanks for the feedback!

    @Valentin:

    • For the Lean lifecycle we've added discussion of kanban boards and will likely add a picture of one too.
    • Good catch on Figure 7.17.  We've had other feedback indicating that diagram is problematic, so we're replacing it for now with a new version that doesn't try to explore so many factors at once.
    • Figure 7.15 perhaps implies a more advanced form of lean as you say.
    • Good point about the program lifecycle, need to think a bit about this.
    • For Exploratory, it is typically used for high incertitude requirements.  For high incertitude technology I would apply spikes, PoCs, or walking skeletons.

    @Joshua:

    • Figure 7.2 - I've updated.  Not sure that was an issue, but doesn't hurt to tighten up the figure.
    • Figure 7.4 - Not much can be done about alignment.  We've added text earlier
    • Figure 7.6 - Need to think about your suggestion a bit.  Potential future change.
    • For lifecycles, we want to focus adoption advice into the When to Adopt section
    • Exploratory - What you're describing is parallel PoCs, something we describe elsewhere
    • I like the idea of MVOs.  They would motivate the creation of MVPs, MMFs, and MMRs I presume?
    • Good catch on Figure 7.12
    • Good point about sufficient functionality, wording updated.
    Jaco:
    • Not sure we want to bring the DAIT lifecycle into Fig 7.3.  Need to think about that a bit.
    • Figure 7.12 - Good point about the funnel.  The funnel ties into other figures that don't appear in this book though, which is why it appears out of context here.
    • On skills, the two CD lifecycles require more in the way of tech skills that exploratory.  Exploratory is pretty close to CD on the diagram though.
    • Figure 7.14 now includes a decision around team size.
    An update to the excerpt has been posted.



  • 28 Oct 2018 6:56 PM
    Reply # 6877160 on 6826124

    On page 16 you have selection factors for choosing a lifecycle, but these only refer to five lifecycles - Program lifecycle is not included. Now it is logical that program lifecycle comes from the scaling factors, e.g. technical and domain complexity. Should there not be a paragraph or something on this somewhere in there?

  • 28 Oct 2018 6:42 PM
    Reply # 6877141 on 6826124

    When discussing the "Team Skills" selection factors, you stated that the CD Lifecycles need the most skill. I would argue that the exploratory lifecycle needs the same if not more team skills than the CD lifecycles.

  • 28 Oct 2018 6:38 PM
    Reply # 6877125 on 6826124

    In "Figure 7.14. A flow chart for choosing an initial lifecycle" it is not clear that if you select the program lifecycle that you would have to select a lifecyle for each one of the DAD subteams.

  • 28 Oct 2018 6:22 PM
    Reply # 6877117 on 6826124

    I love the addition of "Figure 7.12. The DAD Program lifecycle." 

    A remark: In the other lifecycles you depicted a backlog or work-item list. In the program lifecyle you used a funnel. I would have used a backlog or work-item list for consistency with other lifecycle diagrams.

  • 28 Oct 2018 6:12 PM
    Reply # 6877103 on 6826124

    On page 9 under the title "DAD’s Continuous Delivery: Lean Lifecycle", you wrote: 

    "Inception and Transition have disappeared. This occurred for the same reasons they disappeared for Continuous Delivery: Agile."

    In the referred to section you said that the phase became an activity, not that it disappeared. Should it not maybe read: 

    "Inception and Transition became activities. This occurred for the same reasons they became activities for Continuous Delivery: Agile."


  • 28 Oct 2018 5:56 PM
    Reply # 6877054 on 6826124

    In figure "Figure 7.3. The system lifecycle (high-level)." you depict two lifecyles namely "Delivery" and "DevOps". It would be great if you could depict the "DA IT" lifecycle as well as a third line below. I suppose that it would include or stretch from concept to retire. 

<< First  < Prev   1   2   Next >  Last >> 

© 2013-2019 Project Management Institute, Inc.

600 Crowfoot Crescent NW, Suite 340

Calgary, Alberta, CANADA  T3A 5A2

Powered by Wild Apricot Membership Software