I recently worked with a team that was doing Scrum, though they were having a lot of last-minute changes coming from the customer support team. Part of the sprint was filled with new user stories, and part of it with the support tickets representing the customer feedback. Moreover, the business owner might jump in with change requests multiple times a day, stating those were urgent.
The company's attitude was that the customer request is gold, so no matter what, those should be addressed as the first thing. Backing it up with "There is only one constant in life: change. Especially now, in the age of digitalization."
As a result, the team was working in complete anarchy, unable to plan. They were not delivering even half of what was planned due to last-minute changes from management or support.
I hope you can imagine the situation the project manager was in.
This girl approached me with two requests:
1. How to plan the sprints in a way to address all those changes?
The 3 questions that I asked were:
- What's the ratio of incoming changes vs the ability to plan?
- How are the PBIs created and prioritized?
- Have you tried anything beyond Scrum to have a better visibility on the process efficiency?
Sometimes our focus goes in the wrong direction when we are in a chaotic situation, and what we believe is an axiom might just be the reason for the chaos.
So what we did:
- We draw the value stream to understand the change's frequency and the market's specificity.
- Some lean processes were introduced, like the WIP limits, categorization of requests, pull system, cycle time, and throughput. No matter the number of requests, the team can do as much work as its capacity and capabilities allow.
- We identified a prioritization model where the weighted shortest job first would have to contain the value/effort ratio and severity.
- We brought all request types into one board, defining different issue types with different flows.
- We followed with the lead time to plan capacity and bandwidth.
- We gathered in a big meeting to discuss the ownership issue. No matter who opens the requests, the final say should have the Product Owner. Who owns that role is a different topic.
2. As a leader, how to handle the chaos your team is going through because of the changes?
I advised her to follow this approach:
- Tell people what you know and what you don't yet know. People need information. Moreover, sometimes letting them know you don't have any information helps.
- Validate information. Gather more context, perspectives, conditions, and exceptions. Ask questions, and go beyond the Yes or No types. Explore the horizon for new solutions even outside the framework you're using.
- Remember your resources. You can use the processes you have, historical data, previous experience, the ability to communicate with other involved parties as the support team or business owner, the capabilities of your team, and the courage and ability to choose.
Agile does not mean doing whatever you want, even for the customers' sake. People might have strange desires and ideas, and they might have reasonable ones. However, wearing the change as a red flag can turn the team into a feature factory, sacrificing quality. Furthermore, this sacrifice will get back to you with a much bigger negative impact.
Having a clear process to control what you should work on now and the quality bandwidth you can provide can help companies deliver what is needed and manage change without unnecessary hassle.
Managing the change with awareness can also destroy existing thought patterns, opening up new possibilities and ways to think.
Hope you found it helpful :)
===
Whenever you're ready, there are 3 other ways I can help you:
1. Follow me on Linkedin to get daily tips on #agile, #team coaching, #scrum master growth, #agile leadership, #agilecoaching #culture
2. Work with me 1:1 to grow in your Agile leader role or help your team and company grow.