One of the principles of Agile underscores the importance of "responding to change." Though we are theoretically willing to respond to changes, we have difficulty determining their size. In truth, though the only constant in this world is change
, most of us are resistant to it. I have faced challenges in managing changes effectively, and the ways that I have handled them have worked most of the time. It’s about understanding what change really means to your team.
First, how do you react when a change comes in? Are you worried? Do you think it will add more work? Do you think it will impact your sprint deliverables? Do you think that your team will become demotivated? Are you disappointed that you have to re-do a couple of things? Let’s look into two scenarios that we might face in our Agile world.
Why are big changes coming?
You might wonder, “We did a good job at backlog grooming and sprint planning; why are so many change requests coming now, in the middle of the sprint?” Changes can be classified into two broad categories: 1) The change that you have foreseen, and 2) the change that is a surprise. For example, you see that a new building is under construction for your office, and you have to relocate within the next six months. This change falls in the first category; you can plan ahead for this change. But let’s say that the entire electrical supply in your office is down and you have to quickly relocate to another location to keep your business running. We could not anticipate this change, but we have to react fast to mitigate it.
If we relate this to our Agile world, we don’t have to worry about big, planned changes, because we have time to manage them. The unplanned urgent changes usually come in because product owners did not anticipate them; however, managing them is a priority. The business world in which we live has many competitors who can find opportunity in our delayed reaction or response to changes. As an Agile team, when a change is requested, we should always appreciate that it’s made for the benefit our business or customer. So no matter where we are in the sprint, we should welcome the change and plan to implement it. That doesn’t mean that you have to complete the change in the same sprint; it primarily depends on your team velocity and the time remaining in the sprint.
Also, you should not feel discouraged that you have to re-do a couple of things. Do not become demotivated because some of the user stories that you worked on previously are now obsolete. As part of a self-organized team, you should always respect the fact that whatever you deliver brings value to the business or product owners. Do you think it is worth delivering three user stories that don't bring any value to the customer/business just because you didn’t want to accept the needed change? Do you think that you would have added more value by making that one change instead of those three stories?
Why are small changes coming?
Do we really need to talk about the small changes? I think most teams have this attitude: “Do not worry about small changes. We can accommodate them.” Because they are small. Am I right?
Let’s consider another example. Suppose your team is developing a user story to take customer feedback for an online food delivery website. You have been working on a form that takes the customer name, rating, and comments. In the middle of the sprint, the product owner comes up with the idea that if we collect the customer home-address pin code, we can analyze the orders made in that locale to check whether other customers from the same locale have similar feedback. When the product owner comes to you with this change, the first thing the team thinks is, “OK, we just have to add a text box that takes the numeric input, and the maximum length is six digits. It’s a small code change. We can take it. No worries.” The team implements it and delivers at the end of the sprint.
Do you think we did the right thing?
Effectively managing changes
Although we may come from different backgrounds — Waterfall or Agile — the first thing we consider when a change comes in is how extensive the code change is. How many HTML pages do I have to touch? Do I need to import any libraries? Do I need to do regression testing? We tend to measure changes in terms of their implementation complexity. That comes naturally to us.
But it’s not the first thing to do when responding to a change. The first things we should ask or know are:
- What value add does this change bring?
- How does a product owner or customer benefit from this change?
- How does it help our business to progress or compete?
If we know and understand these things, we can implement the change more effectively. Let’s go back to the example wherein the product owner wants an address field. If you know the value that this brings to your customer, you can suggest a couple of things, like reading the customer address by using location services so that the customer doesn’t have to enter the complete address manually.
In summary, always welcome a change and respond to it based on the value it brings. Although size matters, value matters more. The graph below shows one relationship between the size and value of a change.
Although 100 points of the story are completed in Sprint 1, the value the story brings to the business is less. In contrast, Sprint 2 has given more value to the business, even though it has fewer story points.