Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich.
Roy vandeWater: I’m Roy vandeWater.
Derek Neighbors: I’m Derek Neighbors.
Drew LeSueur: I’m Drew LeSueur.
Having A Sense Of Urgency
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.
The Customer Feeling Important
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?
How Should A Team Pace Themselves
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.
How To Encourage High Performance Teams
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.
Coaching To Goals Vs Setting Them For Teams
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.
The Interruption Trap
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.
That’s something that’s been very difficult because every time the development team tries to push for something like that, we get a lot of pushback from the organization because they have demands that need to come in the middle of the week and need to get done right away and they can’t wait until the following sprint before they get done.
Clayton: It sounds like “sense of urgency” means let’s break the scrum, iteration contract and sense of urgency really means I get to interrupt you with whatever I feel like is most important at that moment in time, and you have to do it because if you don’t that means you don’t have a sense of urgency.
Roy: That’s definitely a loaded way to put it, but it’s not inaccurate.
Drew: That’s part of it and even in the sprint there’s a sense of, this has got to get done before the sprint ends. It’s got to get done by Wednesday or something. Derek brought up the burndown chart and maybe it’s Thursday and your sprint ends tomorrow and you haven’t got all your points in. Then you have to have the conversation of, do you scope or do something, what do you have to do to get it done? This sense of urgency goes right along with that.
When you have a visibility either with the burndown chart or communication with the stakeholders, then you can talk about things that might not be apparent if you didn’t have that conversation.
For example, if there’s this ticket, or task, or story that comes in, and it needs to be done, and there’s a sense of urgency on it. If you’re being visible with the stakeholder on where your progress is then they may be able to say, “Hey, all right. We’re not going to hit the deadline here, what can we cut out”?
“Can we remove all the fancy styling? Can we remove all the fancy colors, and just get the thing out”?
If you have the visibility then you’re able to have those conversations. If you don’t have that visibility then you might start implementing some fancy styles, or whatever it might be, that’s just an extreme example, without knowing that that’s urgent, or that that aspect isn’t as important.
I think a real big part of the urgency thing is the visibility and the human interaction with the stakeholder or the client.
Mis-Defined Sense of Urgency
Derek: I was just going to say, I really like analogies. I’m thinking back to an analogy from an operational day.
I think some of it is that there’s this mythical IT creature, or software developer animal, that a lot of business people have that says, “Really good developers like to slave away in the middle of the night, and be fed pizza and beer, and solve really hard problems, and grind themselves to death.”
“By golly, that’s the American developer dream. It’s to just burn yourself until you’ve got nothing left.”
I think sometimes the sense of urgency is, “My friends on the golf course talk about the developers that are working until three o’clock in the morning. When they come in from their golf game the developers are just leaving for the day.” I think that what gets difficult for development teams that are trying to have sustainable pace is that urgency is defined in a funny way.
The analogy I like to say is I was an operations manager for a Macy’s department store. We had six different escalators in the building. We had one particular escalator that had all sorts of problems. It would consistently seize up and it would throw people, literally, off of the escalator when this would happen. It happened to be in the middle of a chain of three other escalators, so it would impede all traffic going up or down when this thing would go down.
We were short‑staffed usually during the highest traffic peaks because the people that would handle that sort of thing were the stock managers and the people that worked overnight and early in the morning.
What would happen is we would have one or two guys on‑call. This thing would go out, and they would call in. They would demand, “Drop whatever the hell you’re doing. The elevators are down. All business is down. Get somebody here right away.”
My staff would complain all the time, “Every third day we get a call that we have to get interrupted.” Then I would chew them out that they didn’t get their job done. They’re like, “Well, you know, the elevator went down three times, and I had to go run and get the keys.”
It was funny to me that it was always so urgent when that happened. But when I would go into the staff meetings, and I would ask the store manager what the update is on calling the Otis repairman to come out and repair the elevator, it was never a priority. It’s like, “Well, which is it”?
I think that product owners and stakeholders tend to do the same thing. “Oh, I want this thing right way,” but there’s some other bigger issue that could really solve the problem, other than technology, but that’s beneath them. So what, it’s just a stupid IT guy. Let him go program this or fix this defect. We don’t care about quality to actually go write an automated test, or something, to prevent this in the future.”
“It’s not worth our time. It’s not our priority there. But it’s a total priority that you get interrupted and then we scream at you that you don’t get your other work done because we keep interrupting you.”
Clayton: I think that does it. Intergrum will be at Open Agile Southern California in the next couple of days. We’re going to record some podcasts.
If you’re interested in that and you can’t attend make sure you listen to some future, upcoming podcasts. We’re going to have some material from there.
Roy: Won’t that be in the past when this gets released?
Clayton: No.
Roy: No?
Clayton: We’re going to release this one, and then we’ll release the others in the future. If you’re listening to this one then the next few episodes you’ll probably get some content.
Derek: He’s not saying, “Join us at Agile Open California.” He’s saying, “If you missed Agile Open California be sure to check in on our summaries.” If you have a time machine you can join us at Agile Open California in Irvine.
Clayton: Great Scott!