Change is inevitable in all projects. In today’s hypercompetitive world where technology, market conditions, and business patterns are continuously shifting, change is the only constant.
However, the approach to managing changes differ in traditional Project management methods and Scrum. In this article we will understand how.
Change management in traditionally managed projects is closely related to Configuration Management. All changes are considered based on their magnitude of variation from a baseline value. The Project Manager is given tolerances within which he or she can manage the day-to-day activities and decisions of the project. When a Change Request exceeds the defined tolerances, the Project Manager must escalate the proposed change to higher levels of management and await their decision before implementing the change. The Project Manager first logs the request for change in an Issue Log or Change Log and then escalates the change to higher authorities. These might include the sponsor of the project, as well as other relevant stakeholders and decision makers. At some point, an impact assessment will be conducted. Based on the estimated impact of the change, a decision will be made regarding whether the change should be implemented or not. The Project Manager may also propose possible solutions to any problems posed by the change. If a decision is made by the higher authorities to proceed with making the change, the Project Manager is responsible for ensuring that the change is implemented correctly.
Change in Scrum works very differently as compared with traditional Project Management. The Scrum framework is highly tuned toward managing changes effectively and efficiently. Whenever the Product Owner or the Scrum Team recognizes a problem or defect or identifies a Prioritized Product Backlog Item that needs to be amended, replaced, or added, the change is made to the Prioritized Product Backlog. Similarly, senior management, the Product Owner, or Stakeholder(s) can add Change Requests to the Prioritized Product Backlog. The Product Owner and Stakeholder(s) approve Change Requests and reprioritize the Backlog accordingly. Whenever there is a problem or new requirement that needs to be addressed immediately and mandates a change affecting the current Sprint, the Product Owner terminates the Sprint, with approval from relevant stakeholders. Once terminated, the Sprint will be re-planned and restarted to incorporate the new requirements.
However, if the problem or change is not major and does not warrant a change within the current Sprint, the change will be added to the Prioritized Product Backlog and incorporated into the planning for a subsequent Sprint. This gives stakeholders the ability to respond to changes in the external environment, while still maintaining a certain degree of control over the ongoing activities within the project. Also, at the end of each Sprint, Done deliverables are demonstrated by the Scrum Team. These deliverables are potentially shippable and can be reviewed by the Product Owner and other stakeholders.
For more articles, click here
