This is the governing body for certification in Disciplined Agile.

Address Changing Stakeholder Needs

  • 05 Oct 2018 7:55 AM
    Reply # 6708543 on 6281366
    Scott Ambler (Administrator)

    Aldo, very good points.  We've unfortunately seen this sort of thing too in practice.

    We've added these options to the updated version.

    Last modified: 05 Oct 2018 7:55 AM | Scott Ambler (Administrator)
  • 04 Jul 2018 6:51 PM
    Reply # 6360761 on 6281366

    Hi everyone

    My current assignment is with a government department with very rigid lines of reporting. We have Product owners that decides the detailed prioritisation for individual stories and features, but also someone that wears a "Product Manager" hat that determines the larger roadmap for the programme. So my question is this: Should we not mention "Product Manager" as part of the "Prioritise Work: Who" and "Stakeholder Interaction with team" options?

    Aldo

  • 16 Jun 2018 11:17 AM
    Reply # 6316152 on 6281366

    Extra for <There are several reasons why this goal is important>:

    Suggestions:
    • Change management does not start in construction but is rather ongoing. Of course, we need to focus to keep the construction on track
    • Changes management for the current release will interfere with fixes for previous releases and with looking ahead on future ones. So, the strategy and option selections shall also consider the overall concerns. An example that could be met very often:  work in the same time for bugs from previous releases, development for the current release, looking ahead (or even spikes) for a future release. What is optimum for one of the problems could not be the optimum for the whole.  
    • Changes requests during Transions could bring us back in Construction and we can compromise some milestones, so it is preffered to be avoided by looking ahead and getting enough feedback during Construction. 

     

    Address Changing Stakeholder Needs --> Accept Changes – easier with Shorter Releases

    That aspect was also described in XP by Kent Beck.  An increased Agility and shorter releases will make to accept changes easier:

    • It is much easier to manage the changes, because in fact, in a shorter release we will receive less request of changes (will be received for the next releases). In a long release, it is an “avalanche effect”: it is more likely to receive changes requests, the release becomes longer, the probability will increase again, etc.
    • It is more likely to get more accurate requirements

     NOTE – This aspect is very important because it is a fundamental competitive advantage of an Agile approach in software development.

     

    Address Changing Stakeholder Needs --> Accept Changes – optimizing the whole inter-goals

    Options and practices are interrelated, and the optimum is at an upper level:  if we prioritize well the work by business and risks, we can accept changes easier: new work it is accepted, and less important work is deferred (scope negotiation). In this case, by managing well the priorities, we do not have invested in low priority work.     

    In this case <Accept changes> it is relater with <Prioritize the work> ~ goals are inter-related.

     

    Address Changing Stakeholder Needs --> Priorities the work: what induce who, optimizing the whole

    We should be careful not to offer less then Scrum: work prioritization must be a negotiation between what is needed and what is possible, between business and development. We also should not confuse ordering with priorities. We have “competing” stakeholders priorities and one resulted order. If the first ordering comes from the business priorities, then this order must be adjusted with technical ordering dependencies.  So, imo, one of team / the architect must always be part of the default options in WHO part, because they know the technical dependencies.

    I just read in the memories of Richard Feynman about investigation related to Challenger Shuttle how various “business”/” management” representatives override what should be only a technical decision.

    Suggestions:

    • To mention that we finally need to get ordering from “competing” priorities
    • To mention that one of AO / the team must negotiate the ordering considering technical dependencies aspects.

      

  • 01 Jun 2018 8:00 PM
    Message # 6281366
    Scott Ambler (Administrator)

    We just posted the excerpt for this process goal.

    Please add your feedback here.

    Thank you very much!

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software