In the early days of my agile journey, I encountered a situation that left a lasting impression on me—a story about courage, one of the core values we, as Scrum Masters, often encourage our teams to embrace.

One day, my senior manager called me into his office with an urgent request. He needed some data from the team members, and it was crucial to have it as soon as possible. The task would take about an hour per team member. Deep down, I knew the right thing to do was to suggest that we schedule this task for the next sprint, which was only a few days away. But I hesitated. After all, it was my boss asking, and I felt obliged to comply immediately.

Returning to my team, I relayed the request. The room fell silent. I could sense their discomfort, and in that moment, I realised I should have pushed back against the manager’s request. Instead, I waited for the team’s response.

After what felt like an eternity, one of the team members finally spoke up: “Waseem, we’ll do it, but we’re going to miss our sprint goal.” I had already discussed the situation with the Product Owner (PO), who agreed to let the team take on the extra work since it was deemed urgent by management.

But in that moment, I was filled with regret. I had always coached my team to be courageous, to stand up for what was right—even if it was difficult. Yet, here I was, failing to demonstrate that very courage myself.

Determined to make things right, I told the team not to worry. I took the PO with me and went back to the senior management office. We explained the situation, emphasising that while the team could complete the task, it would put the sprint goal at risk.

The manager listened and then asked, “Did the team say that?” I nodded, confirming that they had. There was a long pause before he finally said, “Can we plan this for the next sprint instead?”

I walked out of that office feeling a mix of pride and disappointment. Proud that I had eventually stood up for the team, but disappointed that I hadn’t done so from the start. The experience taught me a valuable lesson—one that has shaped my approach ever since.

Now, when faced with urgent requests, I and PO no longer take them at face value. Instead, we ask questions like:

• “Can you help me/us understand why this request is urgent and how critical it is to address it within this sprint?”
• “Is it possible to incorporate this task into the next sprint, allowing us to focus on our current commitments?”
• “Can we prioritise this request in our backlog and address it during the next sprint planning session?”
• “Let’s discuss this request with our Product Owner to see how it aligns with our current priorities and sprint commitments.”
• “One of our Agile principles is to maintain a sustainable pace and focus on the sprint goal. How can we balance this new request with our existing commitments?”
• “Could you provide more details on the business value or critical need driving this request?”

This incident was a hard lesson learned, but it made me a better Scrum Master and a stronger advocate for my team.

What is your approach when dealing with similar situations?