Good afternoon, everyone. Kumar Dattatreyan here from Agile Meridian. And in this episode, I'm going to be talking about making and keeping commitments.
So, for those of you who are here, hopefully, have some people live, join soon, so we can actually make this a conversation. But from my perspective as an enterprise agile coach, I run into a lot of teams that are practicing Scrum or Agile. One of the biggest, most frequent questions I get, in fact, this came up just not too long ago, maybe a couple of weeks ago, from someone in a coaching setting, was how to deal with teams that don't keep their commitments.
They make a commitment. Now, this is in the context of Scrum, but it really applies to any team or even an individual, right? You make a commitment, And the expectation is from whoever you made the commitment to, the expectation from that person or entity is that you keep it, that they expect that you're going to deliver whatever you committed to deliver by a certain time. And so the question is, what happens when you don't deliver what you set out to deliver?
I think the biggest thing that happens is an erosion of trust, right? So, I make a commitment to be home for dinner by 7 p.m. every day, and I'm always late. And so my partner, wife, whoever it is that I made the commitment to, she's going to start, that trust is going to start eroding because, again, I'm not keeping my word, right? I'm not making it home on time to have dinner with her.
And so it works the same on a team. So as a team, when you make a commitment to the product owner, if again, this is a scrum team, but it works with any team, say you're a scrum team, and you say, all right, we commit to delivering these five stories by the end of the sprint. Then, two weeks roll by, or however long the sprint cycle is. At the end of the sprint, you're not able to deliver those five stories, and the product owner knows nothing about your inability to or the constraints that kept you from delivering those five stories until the end.
And so the end comes, and you deliver four. Okay. First sprint. All right. You know, the team's still new. They're still learning. It's no big deal. But as you start to do this repeatedly and repeatedly, where you commit something, and you don't deliver on those commitments, it becomes expected. The product owner or the stakeholders will say, oh yeah, the team, they always say they're going to give us this, but we have to pad our buffers because we know that they're late. And so we're going to ask for more so that when they deliver, and they deliver less than what they say they will, we'll still be okay.
And so there's an erosion of trust. And I kind of go back to Patrick Lencioni and his model, the five dysfunctions of a team. The foundation for any team to be high functioning is trust. And so if you think about a team operating in an environment, whether the team is agile or not, that team operates in a larger context. And so when the team commits their stakeholders, its stakeholders, and they're not able to commit, sorry, deliver on that commitment, it erodes trust. And so, how do you win that trust back? You've got to deliver. You've got to deliver on those commitments. It's as simple as that. And the thing is that when things go awry, and you're not able to keep those commitments, what do you do?
Well, in Agile, we have a perfect mechanism for that. It's the daily stand-up or the daily scrum. And that's what it's for. It's for team members to talk amongst themselves to say, hey, we made this commitment. We committed to delivering five stories at the end of the sprint. How are we doing? And maybe it's halfway through the sprint, and none of the stories are ready. So it's time to raise the flag and say, hey, we've got a problem. We might need to adjust the scope of these stories. We want to deliver something. Product owner, help us prioritize what is most important to deliver, especially if you're not able to deliver everything that you set out to deliver.
So, for teams that are not using Scrum or Agile, how do you do this? It's the same basic premise. Scrum just has a mechanism in place for teams to review their commitments on a daily basis. But if you're not using Scrum, you're not using Agile, it doesn't mean that you don't keep your commitments. It just means that you need to come up with some other mechanism to do that and review the constraints that might keep you from delivering on your commitments.
So what can you do about this? And for anyone in the audience, please weigh in. I'd love to hear from you. So what do you do about this? Be realistic with your estimates. If you think that you can, You can deliver whatever it is you can deliver. You need to be realistic as a team. You need to come up with realistic goals and realistic aspirations. And if you don't think you can deliver something, you need to be very honest and say, I'm sorry, I don't think we can do that by the end of the sprint. There’s a lot of unknowns wrapped up in that work. And so we need to break it down. That's what the planning sessions are for in Scrum, right? And the whole team needs to be involved.
Too often, I see, especially with the distributed nature of the work that we have now, that people are off-camera. They're not really involved in the art of planning when commitments are made. And when it comes time to make the commitment, people say, yeah, yeah, sure, we'll do that. Because they're kind of used to not delivering, and nothing really happens to them.
But let me tell you, things are happening. That team has no trust, or that group of people has no trust with their stakeholders. And so it's really important that if you're building a trusting product owner or stakeholder community that will back you when things don't go well. You have a legitimate reason for not delivering your commitments; you need to do everything you can as a team to build a shared understanding of the work that you're committing to so that you can make effective and valid commitments.
And the next thing, of course, is if you can't, then you need to communicate early and often if you cannot meet the commitment. You know, whatever it is. Transparency is the key to building trust. The more transparent you are, the more visible you are in whatever constraints are holding you back and the more understanding your stakeholders are going to be. You know, everyone's been through it. You know, this is not a new thing. Everyone has these types of difficulties. And so it's just a matter of being transparent with whatever the problems are. The sooner you speak up, the more options you're going to have, too. So if you're on day two or three of your sprint cycle and you realize this user story is so much bigger than I thought. Don't keep that to yourself. Bring it up. Bring it up in the stand-up. Say something. And if you make your commitments on a consistent basis, then you will be able to reap those rewards where your stakeholders, your product owners, are going to trust you.
They're going to start allowing; that's not the right word, but they're going to be more comfortable in you as the team making decisions. They're going to be more comfortable with hearing your opinions about product decisions. Because, again, you're keeping your commitments, you're building trust. And so your stakeholders are going to trust you; this team is awesome. If they have something to say, then I'm going to listen to them.
And then, finally, learn from your mistakes. If you're not able to keep a commitment one sprint, okay. Why? Why weren't you able to keep that commitment? What can you do differently in the next sprint to be better able to keep your commitments? And so, if you're not doing retrospectives as an Agile team, shame on you. That's your chance to improve the way you work together. And if you are and you're still not improving, then examine your retro. Retro your retro to figure out why your team isn't getting better.
And for those of you who are watching that aren't using Scrum or Agile, you can still do these things. Meet on a regular basis, review your commitments, and make sure that you are on track to deliver them. At the end of your commitment cycle, when you deliver whatever it is you're delivering, and you're not able to meet everything that you delivered, and your stakeholders didn't know that you had a problem, then review why you weren't able to let them know. And retrospect on what you can do differently in the next commitment cycle that you have to be better.
It's all about getting better. It's all about making small measured improvements. All right, well, that's all I have for today. It's just a short little segment on making and keeping commitments. Hopefully, you found this helpful. I see there is a comment. Retro your retro. Yes, Freddie. Retro your retro. That's an important thing to do on a regular basis. So, anyone else watching, please, if you have a comment or a question, let me know. I'm going to stick around for a couple of minutes. Thanks for your comment, Freddie. Appreciate that.
And let me think if there's anything I missed. The only last thought, I guess, is just be careful what you commit to. And when you do make a commitment, move heaven and earth to meet it. Now, I mean, a lot of teams will under-commit and over-deliver. And that's not a good thing either.
Be aspirational in your commitments to a certain extent. It doesn't mean that you can never reach it. You want to be able to deliver what you commit. And you want the work that you commit to to be meaningful, to be hard, not easy. And so when you're actually making those commitments, people sit up and take notice.
Yeah, exactly, Freddie. I love that. Leverage the information from the retro to see if you can create metrics from your retro. Yeah, I love that. What does that mean? Create metrics. That means that, say, you have retros, and you come up with some actions, and the actions are either taken or not. That's one way to illustrate the benefit of the retro. We took these actions. We had five actions. We did all of them. Even more valuable is what was the impact of those improvements. Did we actually improve in the ways that we thought we would improve? So, track that, track those metrics. And you're right; psychological safety is incredibly important to establish trust within the team.
And I would argue, Freddie, thank you, Freddie, that trust sort of radiates outside too. So when you make and keep commitments, you start to build trust and safety with your stakeholders, with whoever you're making the commitments to. Right. And so they start to trust you more. They start to become, as I mentioned before, more comfortable in giving you more decision-making authority and rights, if you will.
All right. I want to keep this fairly short. Thanks for the comments, Freddie and whoever else is watching. I can't tell. And we will be back next week with another episode of the XSCALE series. So, we're going to be talking about permaculture and ecosystems thinking. So a higher, broader, more theoretical topic. So if you're into that, join us at the same time on Tuesday. All right. Thank you very much. I appreciate your coming to this show. And I'll see you next time. Bye-bye.
