Creating a Sense of Urgency
The Agile Weekly Crew discuss creating a sense of urgency around the work that needs to be done.
Clayton Lengel-Zigich, Roy van de Water, Derek Neighbors, and Drew Lesueur discuss creating a sense of urgency around the work that needs to be done.
Displaying a sense of urgency to the customer so they feel important.
Creating a sense of urgency to the developers so they stay focused.
No urgency is unmotivating
Perpetual urgency is unsustainable
Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich.
Roy van de Water: I’m Roy van de Water.
Derek Neighbors: I’m Derek Neighbors.
Drew LeSueur: I’m Drew LeSueur.
Clayton: Recently, we’re having a discussion on the team. Roy had mentioned that one of the things that he saw was that someone at the higher level of the organization was saying that they think that every… was it ticket, Roy? Every ticket, every emergency, every interruption, everything should be super important and there should be a sense of urgency around everything. Is that accurate?
Roy: No. I think it was more along the lines of every ticket should have a sense of urgency. Like every ticket is more important than another. When a ticket is more important, that its urgency should be felt throughout the entire organization. The entire organization should feel like the team is rushing to get it done as quickly as possible because we know it’s important.
Clayton: Can you describe what a ticket is just for some context?
Roy: In our case, a ticket would be like a story. It could be anything from a defect to a feature that needs to be implemented, just something that needs to get done.
Clayton: So everything is super important and there should be a sense of urgency around everything. So everything is urgent?
Roy: No. Not everything is important. I think that’s a big thing I took away from that…the thing I brought up to the team here, was about how the things that are important, like the rest of the organization.
Like, we have customers that interface with the organization. When they have something brought up, it is important to the organization that that customer knows that they are very important to us and that we are working very hard to fix that issue, and working very quickly, as quickly as possible, because we know that it’s important and they need it now.
Clayton: When I think of “sense of urgency,” I think of if I were, say, in some management position. I could say, “I want my team to have a sense of urgency so they feel like they need to get things done and it’s not just screwing around.”
From the customer perspective, “sense of urgency,” it seems like “sense” takes on a different word where it seems like you’re saying, “I want to give the customer the appearance that what they’re saying is very urgent to me. So I want them to have a sense that we are being urgent about getting their things solved.”
Roy: Right, exactly. I think sometimes too, because some of our stakeholders are people that are within the company, they also should feel like their stuff is very important.
Clayton: Derek, you were at the center, maybe playing devil’s advocate with this one earlier. What are your thoughts?
Derek: I see this expressed a lot of times in terms of velocity. I’ll see a team, “We’re going to commit to 20 points,” let’s say, and they are at 15 points on Thursday and to the outside world it looks like you’re not going to hit your 20 points and you seem to not really care about it.
I think I’ve seen this even internally, “Hey, we’ve committed 75 points and so at the end of day one we should be five points burned or zero points burned. At the end of the day two we should be 14 points burned and we’re no points burned.” Yet there’s no visible difference of the team from if they were completely out of track.
I think that a lot of time scrum masters or product owners or stakeholders start to say, “Where is the panic? A team should be panicking at this point.” I think that’s something I get conflicted with because in some ways I agree with it and in some ways I disagree with it.
The ways that I agree with it are that I think that a high performing team should constantly be pushing themselves to their limit but not overstretching themselves. I would akin this to say a long distance runner. A sprinter sprints all out and then has plenty of time to recoup, a long distance runner has to meter themselves.
I think in a sprint you’ve got these…most marathoners I know go by miles. They say, “I want to be running in an x minute mile for the first two miles and the next three miles I want to be running this. They have some pace that they’re trying to get to and if they’re behind pace they’ll try to improve that pace.
I think that when teams don’t set a pace or a velocity and they’re not trying to keep in rhythm with that and they don’t have any urgency to that. That’s to me a sign that they’re probably not on the path to be a high performing team.
However I think that it’s also dangerous to say that a team should always be panicked. Because most competent marathon runners I know don’t run a race completely panicked. They’re measuring themselves, they’re checking themselves, they’re pushing themselves accordingly but they also know what their bodies are like. They’re very self‑aware, so they’re not panicked all the time.
I think that to me, it depends on which direction you’re coming from. If you’re coming from the direction of like, “I’m really upset because my team doesn’t look like they’re panicked all the time. They must not be trying hard,” that’s dangerous. If it’s, “The team doesn’t seem to be pushing themselves” I think that might be valid.
Clayton: Let’s say that I as the manager have decided that…my understanding, it’s not good for me to say, “I want my team to be panicked and I want to rush them along” or something like that. I acknowledge that I want them to be pushing themselves to improve and all those things. What are some positive ways that I can help them or that the team can go towards that type of behavior rather than just being “everything’s urgent and I’m real panicked”?
Derek: In going back to the marathon runner, everybody knows what my body type is like, because I’m not a long‑distance runner in any way, shape or form. Some of this is setting goals for yourself, measuring yourself against those goals and then reflecting. This might be, “I’m going to set a velocity of x and my goal is to hit that, and it’s part of if I’m doing a one‑week sprint or a two‑week sprint or a four‑week sprint, whatever that is, I should be able to calculate some interval whether I’m on pace to hit that or not.”
A team that says, “We’re going to do velocity of x over some duration of y,” and they do not break that duration down to smaller segments to check themselves velocity‑wise ‑‑ that to me is a sign that they’re probably not a super high performing team, because what they’re doing is they’re hoping that at the end of their sprint, that they got the time or velocity that they’d hoped for.
Good, strong teams have some way of saying, and this is where the burndown chart comes in, but I think that people abuse the burndown chart and they just look at it as, well, here’s the burndown chart, and they’re not actively pacing themselves against that burndown chart.
Hey, we’re two days into a 10‑day sprint and right now we’re charting to be off by 5 or 10 points. What are we going to do to fix it? Are we going to put in some extra time, are we going to reduce scope, are we going to try to negotiate? What are we going to do to try to be able to finish on time? To me that’s not the same as panicked, but if a team’s not having those conversations, I’m going to suggest that they’re probably going to fail more often than they’re going to succeed.
Roy: Let’s say I’m in charge of a team that’s working beneath me and I recognize that they’re not performing. Would it be a good idea for me to try to push them by setting goals for them?
Derek: I don’t think so. Let me rephrase that. I think that you can ask them ways that they can be more successful. You could probably suggest setting smaller goals within a larger goal and then if they’re not hitting those smaller goals, start to have a conversation about, “Hey, how come we’re not hitting this”? “What could we do to potentially hit this”?
You could do that. If you’re actually setting a goal ‑‑ you say you’re going to do 20 points in the next five days, therefore you need to do 4 points a day and if you’re not I’m going to crack the scrum whip on you. Probably not a real effective way to get the team to perform.
Clayton: One of your other examples that you were talking about, Roy, was that this person who wanted this kind of sense of urgency was talking about it not just for the team, for the development team, but also for the whole organization. In talking to that and having that meeting, what do you see the other people in the organization, maybe the stakeholders or the product owner, how do you see them implementing this new drive toward sense of urgency about everything?
Roy: If something comes in that’s very urgent that it gets to cut everything in line that’s inside the current sprint. We don’t really have the concept of a sacred sprint, where nothing can get into it.