This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
Valentin, that makes a lot of sense. We've added Active Stakeholder Participation, with an appropriate write up, to Validate Release.
Yes, for high risks, high emergencies cases. We need to monitor (if we know in advance), react and collaborate very fast. For such cases, we could anticipate that we could have a series of other small releases to monitor/fix/improve. Everything will be fast and in-time and cannot be done without collaboration availability.
@Valentin - Are you thinking that as an option for Validate Release? To have direct interaction with stakeholders to determine whether it has worked or not? And if not, to potentially work together to resolve?
In cases of high risks, this could be a most critical point of direct collaboration with the stakeholders. No time for lack of availability and lack of inter-teams synchronization. In such cases, in fact, it is more than A.S.P. more than focus groups and discussions.
It is needed an availability for Just-In-Time collaboration with the stakeholders for everything that could be necessary for the short term.
Proposal: Just-in-time stakeholders collaboration.
Validate Release – Active Stakeholder participation
We can have some critical aspects to validate. We can use testing or surveys, but testing could have not enough coverage and surveys can be rather slow. For critical aspects to validate, we can discuss with the customers or other stakeholders (operations, IT, database admins) about what we need to check and what feedback we need. The feedback could be diverse: from end users response about usage, to check logs or other audit artifacts. Also, Active Stakeholders Participation could help to adapt and react just-in-time to various problems.
After deployment time could be critical and a just-in-time response is fundamental. More: it is very likely that this response will involve more stakeholders and JIT collaboration will be needed.
"holder" is repeated:
Enables teams to rapidly address changing stakeholder holder needs
Under Deploy the Solution Release Strategy>Incremental/rolling release>
Perhaps another option to release our solution to a staging server, then to the rest after beta testing. Effectively allowing BAU on the remaining servers while beta testers work off the staging server. Canary+Incremental+others Release benefits. Trade-off is obviously affecting BAU for the beta testing users.
Under Deploy the Solution and Validate Release>Stakeholder satisfaction survey>Trade-Offs:
Potentially send surveys to users based on usage reporting - the users who use the new/old functionality the most, that experience exceptions/performance degradation (also gauged from reports) and actually respond to the surveys (pattern of behavior over time) will give you the best feedback and will not annoy the low usage users. Social media AI can also help to ring-fence the surveys.
I've been looking forward to announcing that we've deployed the excerpt for this process goal. ;-)
As usual, please respond to this topic with any feedback that you have.
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA