This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
We just released an update to this goal chapter.
The big change is the addition of the Capture Plan decision point, something that was sorely missing. Thanks Glen Little for pointing that out!
@Aldo - Agreed. That's a great option that is clearly missing. Update coming soon!
Just a question on "Scheduling Strategy". There are three options; Date, Scope or Cost.
I was wondering about a situation where work is just continuously delivered, for instance in a team that just focuses on production bug fixes. It will be driven by the "as soon as possible" motive.
It could be time, but would it make sense to have a fourth option called "Continuous delivery" based on cycle time(s)?
@Edson - Thanks for the feedback. We've also seen something similar to what you call PATS. I'm thinking something along the lines of "Team Leadership" may be more recognizable as a term.
Keep your eye out for an update soon.
Develop Initial Release Plan->Scope
Option: Product Solution
Trade-off: In this option, there is a better alignment with the organizational portfolio. Sometimes it's difficult to develop a plan without considering the portfolio since there are dependencies and prioritization conflicts among teams. The prioritization of the portfolio is important by keeping the organization and its teams working on the right products.
Hi, I suggest another option and approach to the "source", that I have been using to achieve the Initial Release Plan goal in the organization I work for and it's been well succeded. Sometimes, it's very difficult to give this mission to a self-management team because either it is not formed yet or their members are still working on another project/product release. Given this context, the Product Owner, Architecture Owner, Team Lead and some key stakeholders could be the source to achieve this goal. I suggest naming it "PATS" option :)
The key advantages:
.There is no need to have the whole team formed or attending the sessions to achieve this goal
.The business, scope, solution and planning views are preserved since the key stakeholders, PO, Architecture Owner, and Team Lead are concerned about that
.This partial and initial team are going to deliver the solution minimizing the risk of "just selling and not doing it / delivering it"
@Valentin, good point about the reasons. Doing an update now. Also updating the Choose Cadences decision point about small releases.
@Maciej, also good points. Updated the Source==>Self-Organizing Team discussion. A regulatory project was the best example I could come up with for something with true fixed scope. Only other category would be when something was sold to an external customer, but that would also likely have a fixed date (and likely cost) too.
I will soon post an updated version of the excerpt.
couple of thoughts
Develop Initial Release Plan -> Source
Self organizing team - prefereably facilitator should be from outside of a team - from one side whole team takes part in discussion and we avoid risk of facilitator from inside the team to put pace or ideas, from the other outside facilitator (from outside company or at least other time) will not have any goal in directing team in any direction
Develop Initial Release Plan -> Scheduling Strategy
Scope driven - not sure if regulatory projects are best example as they have two constraints - scope and time. Here we consider scope driven approach
Develop Initial Release Plan -> Reasons: life-cycle and orchestration
The release plan should reflect our decision/option about the lifecycle, having as inputs information about risks, incertitude, and specifics related to requirements solution and other aspects. The selected life-cycle should make possible the orchestration of all these aspects.
Develop Initial Release Plan -> Schedule: releases, small releases
The first cadence to be considered it is related to the length of the releases, where the suggestion of Agile Manifesto is to have weeks and months, with the preference for the shorter time periods. It is the same idea as the one behind shorter iterations. The complexity and problems of long releases will not be completely solved by iteration. That is one of the biggest weakness of Scrum, where release planning is mostly out of scope. XP and Disciplined Agile have already addressed this aspect. XP and Kent Beck use the “small release” concept. DA use a more explicit guideline of having an improvement roadmap, evolving from Agile Basic life-cycle to Continuous Delivery by reducing inception and transition phases, but also the overall release length until Continuous Delivery. Summarizing, the DA guidance recommends an improvement roadmap with evolution to smaller releases.
Here, in the Initial Release Plan, we just need to align this section with overall DA guidance.
Example (proposal): “Smaller release are better because they provide more frequent opportunities for feedback and to adapt to business needs and changes and reduce the overall complexity of the development.”
Please respond to this topic with any feedback you may have regarding the Develop Initial Release Plan excerpt.
Thanks in advance!
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA