This is the governing body for certification in Disciplined Agile.
@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.
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? :-)
Thanks for the feedback!
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?
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.
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.
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.
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."
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.
© 2013-2019 Project Management Institute, Inc.
600 Crowfoot Crescent NW, Suite 340
Calgary, Alberta, CANADA T3A 5A2