Happy Friday,

You probably noticed that this email is coming to you later than normal. I've been helping someone get ready for a Scrum Master certification and wrote a large list of questions and answers that I handed to the team and said, "After you're done with the Daily Scrum, how about using 2-3 minutes to quiz him?"

They loved it.

That turned into a longer conversation that ate into my newsletter time. I apologize for the delay.

I think quite a lot about small changes that reinforce bigger changes or ideas. There's an article I should write that explores more of this, but for now, I want to drill way way down into something that many teams experience and how to use that moment as an opportunity to strengthen a team.

Teams often experience pressure to change the scope of a sprint while it's in progress. There is a lot that is going on in that moment and a lot of ways it can happen, but this email isn't about all those things. It's about how to use that moment when the team feels the need to change scope in a sprint.

You see, the stronger they are as a team the more this moment would become a team discussion. More than deciding if they should alter their scope, it's how as a team they want to address it. Often, I use this moment to do just this. Someone says they need to change scope, and I offer a reminder that the team should weigh in on how to handle it. Even if they feel like they have no choice but to do the work, making it a team concern gives options, help, and awareness of the impact of the change.

In the case where the team is not much more than a collection of staffed individuals, the person who believes scope should change simply changes it and carries on with their impression of the work. More often than not this doesn't end the way everyone thought it would. By accepting that work, the individual made a trade on behalf of the team.

Let me give an example that almost everyone has experienced. A team has a sprint and is operating with the concept of sprint commitments, or the idea that a good sprint is one where everything planned gets done. I bring this up because even though this hasn't existed in a decade, people keep doing this. Anyway, a manager comes to one of the senior developers and asks them to look into an issue. The developer readily agrees and does so. What they thought was a few hours becomes a few days. The sprint ends, and sure enough they failed their commitment and while the team shoulders the blame for failure, the individual added the risk.

In the same scenario, but with a stronger team, when a manager taps the senior developer on the shoulder, the developer negotiates something like a timebox to give to the manager's issue. That timebox is informed by how much time they believe they can give without jeopardizing the sprint. Then the developer brings it up with the team that they're doing this, and that they think the sprint will be fine. The timebox expires, the issue isn't resolved, and the team meets to decide what to do about it. The manager, after the team asks, agrees the work isn't that important and can wait and the team completes their sprint.

The only real difference in these scenarios is the presence of a team. Scope changes all the time, its part of being agile. The question is more about how a

team responds to that moment, and what we can do to call forth that team

instead of treating them as a pool of individual resources.

I'd love to hear your take on this! What opportunities have you found to strengthen a team in little ways? Have you seen these scenarios before?

Articles and updates

This week I wrote an article about some steps I follow when I introduce an activity as a facilitator. I cover how you prepare, what to focus on, and how long it takes, and why winging-it doesn't work.

Click here to read more

Enjoy,

Ryan Latta