Back in the day, part of the strategy was to thoroughly document all initial requirements and pressure stakeholders to sign some kind of blood pact that could, later on, shield us to say ‘No!’. But, let’s be honest, even if we managed to consistently bounce back stakeholders’ new claims, chances are, the project would end up falling short. Why? Because the final result would simply not reflect business’ most recent needs. It’s like rubbing salt into the wound.
Rather than trying to stop the waves of change, Agile methodologies taught us how to surf them.
By following a more interactive approach, instead of focusing on upfront comprehensive planning, changes just become a natural part of the process. Embracing change and collaboration over contract negotiation is just some of the jargon you will find on the Agile Manifesto.
However, that doesn’t mean that Agile is a free pass to carelessly accept any arbitrary change. I believe we can all agree that there’s a fine line between what should be and what should not be accepted, and that’s mainly common sense. Knowing where that line is will set the tone and directly impact the success of your work. And that’s the hardest part!
There’s no silver bullet, but I won’t leave you empty-handed, just bear with me. As a Scrum team, here at Landing.Jobs, we are naturally open to change but we take extra care with changes that might mess up with our Sprint. Here are some of the things we consider when such a change knocks on our door:
- Understand where it comes from:
Digging for the underlying root will help you isolate arbitrary changes from actual feedback on your iterative process. Feedback is gold, take it and make it count as best as you can. - Assess the impact on the current Sprint:
Some changes might force you to rethink the work in progress. If you are lucky enough, those changes might actually contribute to your sprint goals, maybe just a few tweaks and you’re back on track. But that would be the least of your problems. - Question it’s value and urgency:
It should come as no surprise that most changes will try to damage your Sprint. Make sure to measure the value and urgency of such changes. By default, a change should only disturb the Sprint if those two surpass what’s already in Sprint. - Share the impact:
If a valuable and urgent change is trying to twist your Sprint you might need to drop something from the current sprint, something less valuable and/or urgency sounds reasonable. Put the cards on the table, make sure everyone is aware of the trade-off game and committing to it. - Adapt:
If you’re getting too many of those requests maybe you’ll need to adapt how the team works. Aim for shorter iterations, get the stakeholders closer to your process, use your imagination and don’t be afraid to experiment. Just don’t pretend you can fight changes without paying the price for it.
I’ve already been on teams that would promptly deny changes to the current Sprint. Although I do realize where that comes from, I also understand that simply sweeping change under the carpet has always been part of the problem, not part of the solution. That’s why we try to keep our minds open to changes, even during the Sprint.
As a last thought, some may argue that there’s no such thing as scope creeps on an Agile environment. I wouldn’t go that far, I believe it’s still there, just waiting for the opportunity to harm you. The main difference is that we now acknowledge change as a natural, valuable part of an iterative process and by using that as a foundation, we’re able to build something that’s ready for it.
João Aires is the Engineering Lead at Landing.Jobs and an experienced software engineer with a little crush for Python and a complicated relationship with JavaScript. He’s also known for always carrying a screwdriver in his pocket and for loving Tex-Mex.
0 Comments