Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
In the same way you manage change into other type of approaches. Agile has change manegement embeded into it. If you use methods or frameworks you will find that change mantement is included. Unfortunately people do not understand (some people) that "embraced change" is not a synonim of "no change mangement".
which change management are your referring to? Project change management or Organization change management? In the former case, adaptive approaches are more open to change in requirements/scope but even then, if there are major changes affecting funding, committed release timelines or major scope components, a PCR might still be used. If you are referring to the latter, then it is an ongoing activity in projects following an adaptive lifecycle as we introduce change multiple times (early & regularly) and outcomes like a change strategy or plan need to evolve over the life of the project based on changing requirements.
Kiron
...
1 reply by Gaurav Dhooper
May 08, 2019 9:10 PM
Gaurav Dhooper
...
Thanks Kiron for providing your valuable feedback. I am referring to Project Change Management.
You do have to realize that scope change management in an agile project can be tricky. Normally, scope changes should be added to the backlog and prioritized. When you do that, you will be pushing scope further down the backlog.
The question will be: is the project driven by an end date or by the scope? If the former, then you probably won't affect the schedule or the budget. If the latter, then your schedule will be longer and your budget higher. Saving Changes...
For project change management, while it doesn't go away, it is likely that the process has to change because it was developed around a different way of doing business.
A process where changes must go successively from lower through senior change boards for approval won't allow agility. They might not even get approved before the plan changes again. Similarly if changes have to be committed through downstream business systems (manufacturing, purchasing, etc.) the change commitment process may not be able to keep up with your product changes using existing processes.
You still need to manage how changes are incorporated, but you might have to rethink how that's done. Saving Changes...
Gaurav DhooperAssistant Vice President| GenpactNoida, U.P., India
May 08, 2019 3:06 PM
Replying to Kiron Bondale
...
Gaurav -
which change management are your referring to? Project change management or Organization change management? In the former case, adaptive approaches are more open to change in requirements/scope but even then, if there are major changes affecting funding, committed release timelines or major scope components, a PCR might still be used. If you are referring to the latter, then it is an ongoing activity in projects following an adaptive lifecycle as we introduce change multiple times (early & regularly) and outcomes like a change strategy or plan need to evolve over the life of the project based on changing requirements.
Kiron
Thanks Kiron for providing your valuable feedback. I am referring to Project Change Management.
...
1 reply by Kiron Bondale
May 09, 2019 7:27 AM
Kiron Bondale
...
Success with adaptive approaches requires shared understanding & alignment on the target (to avoid us taking a random walk to no where). This should normally be captured in a charter or project/product vision and if it changes dramatically you are likely looking at a new business case. From there, it really depends on the project and the culture/standards of the organization as to where you baseline. For some companies, they'll bring it down to an Epic-level whereas others would draw the line at the feature/theme-level.
But even if there is significant flexibility provided on scope, the impacts of scope changes on other constraints need to be considered and if those fall outside of established guardrails, then formal change control procedures should be followed. The definition of these guardrails might be done in the CM plan for the project or might be part of the organization's PM policies/standards.
Kiron
Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Great responses from the group, but it is Stephane's response that resonates the most with me. When there is no defined scope, it is challenging to manage scope creep and more significant changes throughout execution. My recommendation is to use something like OKR. Drawing a line in the sand with strategic and tactical themes can help to ensure any changes are in line with the overall goals. Also having sprint goals that align with the overarching theme also keeps things in check. But, still, in the end, it is a challenging process. Saving Changes...
Thanks Kiron for providing your valuable feedback. I am referring to Project Change Management.
Success with adaptive approaches requires shared understanding & alignment on the target (to avoid us taking a random walk to no where). This should normally be captured in a charter or project/product vision and if it changes dramatically you are likely looking at a new business case. From there, it really depends on the project and the culture/standards of the organization as to where you baseline. For some companies, they'll bring it down to an Epic-level whereas others would draw the line at the feature/theme-level.
But even if there is significant flexibility provided on scope, the impacts of scope changes on other constraints need to be considered and if those fall outside of established guardrails, then formal change control procedures should be followed. The definition of these guardrails might be done in the CM plan for the project or might be part of the organization's PM policies/standards.
Almost like the other type of changes. Saving Changes...
Gaurav DhooperAssistant Vice President| GenpactNoida, U.P., India
May 09, 2019 7:27 AM
Replying to Kiron Bondale
...
Success with adaptive approaches requires shared understanding & alignment on the target (to avoid us taking a random walk to no where). This should normally be captured in a charter or project/product vision and if it changes dramatically you are likely looking at a new business case. From there, it really depends on the project and the culture/standards of the organization as to where you baseline. For some companies, they'll bring it down to an Epic-level whereas others would draw the line at the feature/theme-level.
But even if there is significant flexibility provided on scope, the impacts of scope changes on other constraints need to be considered and if those fall outside of established guardrails, then formal change control procedures should be followed. The definition of these guardrails might be done in the CM plan for the project or might be part of the organization's PM policies/standards.
Kiron
Thanks Kiron for a detailed perspective Saving Changes...
