Dilemma of an agile coach: Seamless change management

This blog is relevant for you if you either work with one or more development partners, or you are a development partner for a client.The mention of something as elaborate as "change control board" or change management guidelines in the context of Scrum has always taken me by surprise. It appears that the core values of scrum have not been completely understood. Having said that, the need for a seamless change management process cannot be ignored. Based on my experience of executing projects using Scrum for over a decade in multiple domains, here is my perspective on seamless change management.

Why is there a need for a change management process?

1. To assist stakeholders in understanding how scrum was designed to work with evolving requirements
   People often misunderstand the Scrum principle of accepting changes late in the development process. Changing sprint backlog stories even mid sprint is a common practice. Either by shuffling priorities and adding a separate set of stories in the sprint backlog or by changing the requirements specified in the stories that are part of the sprint backlog.

2. To manage unreasonable expectations from Scrum teams
   Often due to lack of understanding of the Scrum framework (refer to #1), the issue of managing change takes a more serious turn with questions like why a team was unable to complete a given set of requirements as per estimates. When requirements evolve this misdirected question points towards a waterfall way of working where requirements were frozen before proceeding to development. Such questions are asked more often than we'd expect.

In the context of Scrum, change management flows naturally when Scrum is understood properly. Here are three scenarios which can help reiterate the importance of Scrum and how to achieve seamless change management.

Scenario 1 – Ideal

Accepting changes late in development stages is hardly a challenge since we usually work with short duration sprints and changes to stories that are not part of the sprint are easy to accept as these won't affect the team's momentum. But, when the product owner requests shuffling stories in a sprint, there is something wrong. This could also mean improper grooming or poor prioritization on the part of the product owner.

Scrum does not mean adhoc development. It is a fast-paced development to bring desired benefits only when understood properly and executed as per the framework. Each ceremony serves a purpose and should be conducted with the desired objective in mind. Since Scrum is already ceremony heavy, introducing unexpected changes will confuse the team, impact their momentum and even exhaust them.

Scrum does not believe in "freezing requirements". A development team can discuss the stories in a sprint backlog with the product owner and allow the stories to evolve during the development phase as long as the end goal of the story doesn’t change. This should not mean that new requirements are added in the user story. If there are substantial changes, it certainly calls for a new user story. And Scrum being iterative, it is well within the framework to revisit a feature multiple times and keep improving it in each iteration.

If the changes suggested by the product owner are going to change the end goal of the user story and/or impact the size of the story, then that discussion should not be part of story development during a sprint.

To find a middle ground, the following approach can be useful:

• Once committed, do not change the sprint backlog.
• Continuously groom and evolve other unfinished stories that are in the product backlog.
• Discuss and evolve the stories committed to the sprint backlog, as long as the end goal of the story/sprint is not altered.

Scenario 2 - Middle ground

If the team is developing on cadence but releasing on demand, or basically unable to create a shippable increment with every sprint, then the following approach can be considered:

• During sprint planning, development teams commit to a sprint backlog and the team should also keep a few buffer stories from the top of the backlog estimated.
• During sprint execution, the PO can request to remove a story from the sprint backlog if he/she strongly feels that the story in its current form will not help achieve sprint goals.
• The development team can pick the highest priority story from the product backlog AFTER completing other committed stories in the sprint backlog.
• The team can continuously groom and evolve other unfinished stories that are in the product backlog.
• It is also fine to discuss and evolve the stories committed in the sprint backlog, as long as the end goal of the story/sprint is not altered.

Stories that are removed from the sprint backlog go back into the product backlog. From there, they can be groomed properly in backlog grooming meetings or the PO can choose to close this story and create a new one. Whether this story will make it to the upcoming sprint or not will be decided in the sprint planning meeting.

Scenario 3 - Extreme

In some projects, clients insist on following Scrum, but don’t truly understand the spirit of Scrum. Building a better understanding with the client over a period is important in such situations. During this time, they can understand the Scrum framework and the best practices to achieve desired benefits.

Meanwhile you can take help of identifiers, labels and prefixes to track changes in the sprint backlog.

In one of our projects, we used the labels of RC (Requirement Change) and CR (Change Request) for each user story that was changed during sprint execution and added something new during sprint execution every time. This allowed us to collect required data points with which we could showcase the impact on the team's momentum due to frequent changes.

The recommended approach for such scenarios is to take a few steps back, and spend more time in grooming and prioritizing the product backlog. If that is not possible, explore another execution methodology instead of Scrum. Depending on the situation the choices can be Kanban, Scrumban or even waterfall.

An agile coach can help you select the best-suited execution methodology. In fact, at Nagarro we’ve helped many clients on their Agile Transformation journey. Learn more about our enterprise agile offerings or reach us at info@nagarro.com for more.