This is the fifth and final episode in our five-part series on the five scrum values. We wrap up our series with commitment with our guests , Michael Wallace professional scrum trainer at improving Michael ties , all five values together for us and brings it on home. As a series comes to a conclusion on this episode of the agile within
[inaudible]
Welcome to the podcast that challenges you from the inside can be more and discover the agile within. And now here's your host, Greg Miller. Okay, welcome back. This is the fifth and final episode on our continued series of the five scrum values. The last one we did on focus and this one's on commitment. Our guest today is Michael Wallace professional scrum Chainer with improving.
He has over 30 years in the it industry, strong development background coach, every role you can think of QA BA systems analyst, Mike stand at all. So thank you for joining us today, Michael. Thank you , Greg . Thanks for having me. Yeah, sure. So on our fifth and final episode here of commitment, so we've been going over the five scrum values. We did courage, openness, respect, and focus. If you've been following us along, this is on commitment. So let's dive into commitment, Michael.
Um , I mentioned the focus that was the most , uh, mentioned , uh, of the scrum values in the scrum guide. Commitment is actually number two. We know that , uh, they they're at least a , that word is mentioned more in the scrum guide. So it was , it actually is so focus the top and then commitment is the second most mentioned. Is that what you're saying? So focus has a lot of times
Commitment . Sometimes respect is four times, so it drops .
Okay. So drops off. So there you go. If you're a , if you're into, if you're someone who counts and into that time, there you go. So focus and commitment, the top two ones in the scrum guide. So commitment. Um, what do you have any ideas on commitment? What do you think that means? And what does the scrum guide trying to help us understand about commitment?
Well, as a, as a, as an agile coach , uh , one of the biggest challenges that we have, we touched on this in the last podcast is , uh , leadership, making commitments for the development team, for the scrum, for the scrum team and all of the research reading I've done. Uh , it's pretty clear that , uh, people take way more seriously commitments they make , um, rather than ones made made for them.
And in fact, there's a lot of evidence that people are, they , they don't necessarily have to get their , they get their way, but they have to be heard. And , and so if there are, there are people making commitments for the team, you know, setting somewhat arbitrary deadlines, at least arbitrary from the team's perspective. Yeah .
Um, and making commitments , uh, for the, for the team you're, you're S you're really starting off on the wrong foot , uh, with, with the people that are interesting and get the ,
Yeah, totally. This I'm actually glad to hear you say that. It's the second most mentioned this, this is again, another one that I've really experienced a lot of problems with, for the reasons you just mentioned. Um, just this year, actually just this year , um, someone high up in the organization actually committed the team to the board that we will have this piece of work done by a certain date. And that's exactly what you were talking about.
And that , um, you know, I know my reaction to that, but my reaction has to be tempered because of who it came from, but that is not for you, for those people listening there . I'm sure your experiences a lot, but that is not the way you want to run it.
So I know companies like to do that, especially when you're an executive level, they like to tell it's like, I always say like gun to your head and it's pushed in there, have to do it because of who it came from now in all my training , um, uh , I've always been taught that it doesn't matter who the request comes from. It should be put into backlog and prioritized even from the CEO. However, reality has shown me that, that, that usually never happens.
Usually , uh , the CEO is going to get what he or she wants because of the position. So I don't know how you break that. I don't think you can ever can, unless you get a CEO or executive that really understands. Um , but usually that person's making the decision. They mean, well, what we have to assume good intent. I try to assume good intent, right? Yeah. But this is one that, yeah. Uh, I've even got it from not, not that high up, but from , uh , project managers.
I remember talking to project managers multiple times when they come to us and they say, there's a deadline. And I say, well, where did that get that deadline come from? Well, it turns out, well, one of them actually told me, well, we were talking, we had this deadline who's we, I , I wasn't, I don't , I was never in any of those meetings. No one on my team was ever. So you're committing the team, sign up the team to do some work. When you have no clue how long we never got to look at the work.
We don't know what the requirements are. We can't give you an honest estimate. Uh it's like, it's like your car, like bringing your car into the shovel. It's making this noise. I need it done by. I want it done by tomorrow. I didn't look at it yet. Well, I need it done by tomorrow at two o'clock. Right. I got it. You know, that's when I that's, when I told someone I'd have it, you'd have it done. Would your car mechanic, would your karma camper would say, get out of here? I right .
I'm sure you've experienced the same thing.
And one of my favorite examples, I was , um, working for a large financial company. And the, the team I was working with was approached with a , uh , basically a backlog of work that they were told, had to be done by a certain day to meet regulatory requirements. Right. And so the first thing the team did was to go through the requirements, go through the backlog, put together some rough estimates and it became clear to them that there was no way they could meet that deadline.
In the current environment with the people they had and the time they had, there was no way they could meet it. Um, but then we, we, we reviewed the backlog, maybe a little harder and looked and discovered that in talking to the, to the regulator , the regulators or the people that wanted the work , um, we discovered about of the backlog really wasn't required.
It was nice to have things well, this, this was a situation where they were going to have to do some reporting every six months or whatever. I don't remember the timeframe now. And so there was a book of work that definitely had to be done, but there, there was also some things in that backlog to make it easier for the organization's employees to do the reporting. Right?
Some, yeah , some reports or I forget what they were now, but some different, some different tools that would make the internal people's job easier. Now these are good things I have , but the regulators don't care. How , how hard do you have to work to get the , get them their data. Right. Right. And so we were able to figure out that if we focused on a particular set of items that the regulators had to have , yeah . We could get those done.
The end internal people doing the reporting would have to do a lot of manual work to bring everything together and massage, whatever they have to do. Um, but we could still meet the deadline. And then once the deadline, once we got that first book of work done and the method, regulators deadline, we could go ahead and do those nice to have things. Yeah .
And so the next time they had to do this reporting, it would be a lot easier next time, but it wasn't going to be a lot easier this time, but they weren't, they were hoping that if they, if they labeled it as being required by the regulators, that it would force the team to add all their nice stuff . Yeah. Yeah .
I mean, I don't know if they've really thought it through that far, you know, smarts , but, you know, and they came up with a list of things they wanted done, and they said, we have to have this to meet the deadline. And they really didn't have to have all of it to meet the deadline. And so they weren't, you know, they were trying to get the team to commit to things that were not , uh , real right . Another situation.
Uh, I had another situation where a , uh , organization had made a , uh, acquisition.
They , uh , were doing some work to integrate that , uh , the company, they bought integrate their stuff and into the existing companies , um , systems and things to make a seamless experience and leadership made commitments as to the , to the , uh , to the , a wall street analyst , to customers that they were going to have all this done by a certain date without, without really getting any input, at least from the, from the doing the work. Yeah .
They might've gotten a commitment from the leaders of the people doing the work.
Yeah. Right .
But I worked, I, you know, I worked with several of the teams doing the work and, you know, every time I met with them , it's like, yeah, we're not going to get this done. I don't know what they're thinking. And , but it was, you know , not a safe environment to say, Hey, we're not , uh, we're not going to get this done, so.
Right. Right. Yeah. So as we're talking through here, it , it, it seems, so we've been talking so far about , uh, commitments maybe , uh, put to the team right. Given to the team. So there's another aspect, another side, whereas the team, the team committing to work, I think , um, so now in the scrum guide, you're gonna have to correct me here, you know, more than I do it now, my understanding is I know they took that word out , uh , commitment. And that was forecast.
And now with the new one, I don't know if the new one, I know the new one was strengthened with accountability. Right. But did the word commitment come back or is it still forecasting?
Well, the, the, so what's, you're referring to , uh, and it was actually something I used to like as an manager , um, the, the way it was worded , uh, up until I think it was 2017 that the , uh , the development team would bring what would commit to getting the product backlog items done, basically. And as a manager, I was okay with that because in my head, you're , you're telling me that I'm going to let the developers decide how much work they're going to get done in the next two weeks.
Right . So when we're running a two week sprint, it seemed fair to me that they would guarantee me that it would get done, that they would commit to it. And as a manager, I thought that was pretty fair. But what I eventually figured out what was not fair about it was, and this is something I teach leaders all the time. Now, if, if you push the team too hard, if you push people too hard and ask them to work beyond a sustainable pace, I can guarantee you that quality will go down. Yeah .
Because that's the main lever that the people doing the work have to go faster. They do more, you know, developers to do more, you know, cutting and pasting, they'll run less unit tests. The QA folks won't run as many tests. Um, you know, they'll rush things through. And so if you push people too hard, they will reduce quality.
In fact, I've told leaders if you're, if you're gonna tell people to on a sustainable pace, go ahead and tell them to reduce quality, because that's exactly, well , I don't want them to reduce no , well , I don't care. But if I throw you off , go off of the tall building, you will hit the ground. I mean, it's just a law of gravity, right? If you make the team , um, commit to things that can't get done, they will reduce quality.
So they changed that to forecast as far as the actual units of work that gets done. But what they did do is make it clear that the sprint goal is what we're committing to. And the sprint goal is never getting all the PBI has done all the product backlog items. Right , right. Right. Sprint goal is something like we want to improve the customer's , uh, search capability.
And so we're going to bring in these , uh , eight product backlog items, this is going to improve the customer search capability. Now we've forecast that we can get all eight done, but it's also likely that if we only get seven done the customer search capabilities still improved. Yeah . Not quite as much as we had hoped, but it's, but we still met the sprint goal of the search capability being improved.
And so they've , there's a lot of commitment in the scrum guide that commit to the scrum goal. Um, the , the, the whole scrum team is committed to the product goal, which is a new thing in the scrum guy. Um, they're committing to each other as a team , um, that they're going to do the best they can, that they're , they're committed to the success of the team. They're not, they're not focused on individual achievements, but committed to the team succeeding . Right.
You know , that's another, another challenge that we have as coaches sometimes with, with people that are new, to maybe new to scrum is they they've been working in an environment for so long that rewarded heroes and individual contributions and scrum as a scrum is a team sport. Um, you know, you're playing basketball, you're not playing golf anymore . And so you can have , we have a superstar that hogs the ball , uh, in a basketball team. And , uh, they may not win very many games. Right.
Um , because you gotta have all the players , um, and you're, you're going to have people that are a little better, obviously you're not, everyone's skill level is the same, even in basketball or on a scrum team, but they have to all work together to be , uh , successful. And so they have to commit to each other to do that and, you know , committed to continuous improvement , uh, committed to delivering value, those sorts of things. Yeah . That's a whole nother, yeah. That's more commitment.
Yeah. So
One thing , uh, as you were talking that one thing, and that I re I didn't realize this, I think it wasn't , I took your class. And then I also read the new scrum guide when this kind of a , it kind of dawned on me , um, that you correct me if I'm wrong here. Um, cause I , I might be, but, and based on what you just said, so if I bring in, I'm not committed. If I bring in 10 stories in a sprint and say, not all of them are, are , um , not all of them go towards the goal.
That'd be maybe seven out of 10 that would have them go towards the goal. And three of them are, you know, we have, maybe we had the , we had more room, we brought in three more stories to do something else. Okay. Uh, but we're still focused on that. There's seven. So we get the seven done. Uh, and we don't, we don't get the other three done, say we don't get those done at all. Um, would you say that, well , we met our sprint goal. Right.
But what , we're not, because we're not committing to all 10 stories. So we still , um, we still made our commitment. Right.
I think it depends on how you structured the, the , um, the spread goal. So again, if the sprint goal is to improve search capability and those seven items did that, and there were three bug fixes, you didn't do. Um, I would, I would call that a success, but I can also see a scenario where one of those bug fixes is critical , um, to some something, you know, in the organization. And you would make that part of your sprint goal. Okay. So it depends.
I, to me, it would depend on whether those three items were, you know, Hey, we've, we've, we've identified these seven, that'll meet this sprint goal of improving search. We still got some room, Hey, let's pick up a couple , uh , stories of things that have been annoying people. They're not really , uh , you know , a big deal, but you know, there's a misspelling on a page or, you know, something, something just annoying and we don't get around to it.
I, you know, I would, I would, as a coach, I would call that a success. But if, if that, if one of those bugs were something that was preventing us from , uh, going into production or , uh , was a critical failure in some way, then I would make that there's nothing that says a sprint goal can only be one thing, but let's go back to focus again.
Yeah .
I ideally this , the, it would be improved search capability in the story , but it might be improved search capability and fix this bug , uh , or , or make this change. That'll keep the out of jail and we have to do it. And, and so we have less focus. We , we focus as much as we can. I tell teams all the time. You're not, you're never going to be ever going to be perfect in everything. When , when you're doing these things, you , you just got to do the best you can and focus as, as best you can.
I've had teams that had the , that had to , uh , support three different products, three, four different products . Yeah. Um, as much as we could, we tried to create , had a situation where, okay, this Brent , we're going to focus on product day . And so we're going to, we're going to bring in some , uh , all the things we're going to bring in and our sprint backlog are going to be things for product day. And that, that would give us some focus, but some, some sprints , you couldn't do that.
Um, and there's, there's no way to, if that's the org , the organization's priorities are that we have to get these three different things done, or these three different products. And we only have one scrum team. You're not going to have as much focus, but you're going to do the best you can. Yeah . Right.
You know, you can't, you can't, of course it , um, it's just the, you know, you have to, you have to deal with the, you have to play the cards you're dealt and , um, you know, in a perfect world, you have three products, you'd have three scrum teams, but if we're a small company teams , so we do the best we can, we try to figure out , uh, you know, maybe we can't focus in that area, but maybe there's other areas that we can really hyper-focus in and try to make up for some of that.
Um, all of these values that we've talked about, you're , you're just going to do the best you can. And one of the things should be talking about in your, in your retrospectives is Heller . How are we doing on these values? Are there some, some things , uh , that we could be doing better, that we have some control over when, when scrum teams come to me and say, they want to make some sort of change, they want to , they want to do something differently.
My first question is, well, how does that impact the scrum values or the agile values? Right. Um, if it's, if it's a positive impact , um , yeah, let's try it. Um, typically if you're trying to change scrum, like I'll have teams that want to do daily scrums twice a week. Yeah. That's a big one. How does that increase our, you know , transparency or focus or, you know , um, of course it doesn't in a positive way. Right.
So we probably don't want to do that, but if they come to me and say, Hey, we want to add cotton bond , um, to our work , um, you know, that's going to improve our focus and, and , um , some of the other, in our commitments , some of the other values, then, Hey, let's try it. If it's, if it's going to make it better.
That's interesting take, you know, I never thought about that. So, yeah. So, yeah, so you're always, you're always, you're always coming back to the five values and when they ask you to make a change, that's why I like that .
Yeah. You have to describe as again, just a framework. It's not very , um, prescriptive. Although my, my Kanban friends, you know, they think it is, but right . Cause they're , their guide is, you know, three or four pages. Maybe There's a lot less prescription there. Um, but it's a different, it's a different animal, but , um, there , there's not a lot of prescription and scrum purposely , um , gives you the ability to make it your own.
And as long as you keep within those Chrome values, again, as a coach , uh, I'm fine with that. It's all about figuring out what works best for the team. And if you have this thing they want to do on prove their commitment or improve their focus or their openness RNA or any other values , um, then I'm all for it. If it doesn't, then maybe we should think about what's our real problem we're trying to solve.
And is there, is there a better way to solve it without , um, without decreasing our commitment to these values?
Right. One, that's a good one. Commitment to the values. I like that one , one other , um, there's so much we could talk about here. One other aspect that I'd like to touch on that you mentioned a little bit, there was , uh, so we talked about commitment , uh, the team committing to the work we talked about , uh, maybe outside folks committing the team to work. Um, there's the aspect of , uh , commitment to one another on the team. Um, what can you, what can you say about that?
Yeah, I think I mentioned earlier , um, one of the things they commit to , um, I believe as a scrum team is committing to do their best , uh, committing to the success of the team , uh, committing to, to high standards of performance , uh, committing to their, to their definition of done, which of course , uh, addresses in a big way, the, the , uh , quality standards for the , uh , for the team. And, and so, yeah, there's, there's awful lot of commitments around.
And then, and then the, I think the scrum framework does a pretty good job of, of reinforcing that idea. We have , uh , you know, we're committed to delivering a Doug Dunn increment. And of course our definition of done promotes a commitment to quality and continuous improvement . Our product backlog enables a commitment to transparency where people can see what's planned. Um, the sprint backlog , uh , is commitment to transparency to our progress.
So there's an awful lot of, you know, in the daily scrum, the team in many ways makes a commitment to each other as to what they're going to get done over the next 24 hours. Right. Um, now again, you have to be careful that you don't push somebody so hard that they start reducing quality to meet their commitments. Um, but you know, the, the daily scrum sort of enforces a little bit of a peer pressure sure . And meeting those commitments.
Um, in fact, I always liked that aspect of it where I thought, I always thought scrum , uh, did a really good job of , of, of sort of , uh, making transparent , uh, people that were struggling to get things done. Um, I've got a couple of situations where there'd be someone on the team that always seemed very busy. Um, but I really never got anything done.
And , but like , you kind of hide it until you, until you had a daily scrum, because evidently because you made something a daily scrum , uh , so , uh , what'd you get done yesterday. If you come to the daily scrum enough times where you don't get anything done, you're , you're obviously not meeting your commitment , uh , to the team. Of course, the team's first reaction should be, you know, how can we help you? Right.
Um , because we're all going to run into situations where, Hey guys, I'm so sorry. I know I told you I had this done and I ran into this random to that. Sure . And somebody else has jumped in , um, and commit to helping you, because again, we're, we've made a commitment as a team to get the work done. That's one of the things I don't like about some of the tools we use where, you know, work items get assigned to a single person yeah. On that item.
And , and so leaders like to go in and say, okay, how many story points did Joe get done? Oh yeah . I seen that . Maybe Greg, yes. I've seen, you know, once you start doing that, of course , um, your commitment, openness and everything else goes out, the window shuts down.
Yes. But if we're judged on how , um, on how well we're doing as a , as a team, it makes it much easier to commit to each other, to, you know, again like a basketball team, you know, if I don't have a shot, I should pass it to you. If you've got a shot and let you make the basket. Right. Because this more about , um, us winning the game than that , me getting the most points. Right.
That's such a fine line. Yeah . Uh, but yeah. So , um, another thing commitment in , in my , it can be a scary word. Right. I mean, I mean, I mean, it, it has a lot of connotations. I mean, it , when I first read that, I'm like, that's a big word for a lot of people commitment. Oh, you mean like I'm signing up for something like with my first born or in blood and holding me to it.
But I mean, it's not that, you know, over that, but, but in a way, I mean, yeah, we are, you know, we, I try to tell my teams, you know, we're telling our private donor , we're telling the business, we're going to get this done in this next two weeks. And they're counting on that. I do try to impress upon them that we need to make sure, like you said, to do our best, but if something goes wrong, we just need, we just need to be able to explain it.
I mean, I need to be able to explain it, why we didn't get it done. You know, maybe someone was out sick, a death in the family, things like that happen. Life happens. Right. And we have to, and if we try, like you said, Oh, someone can pick it up, but maybe, maybe they were juggling too much. And then we just didn't get it done. And, you know, but yeah, yeah, go ahead.
That's where these, these, these , um, scrum values don't, they don't stand by themselves. If you just had commitment by itself, that could drive a lot of bad behavior with that commitment . We have to have openness. We have to have respect. We have to have courage, you know, the things that that Blake talked about. And without those , without those things , uh , commitment can, can cause a lot of bad things to happen by itself.
So I've always felt that the scrum values , um, they're, they're, they're tightly coupled they play off of each other rather. Well, yeah . And any one of them by themselves , um, aren't necessarily gonna drive the right behavior. But , um, if you have openness and respect and courage, you, you you're committed to doing the right thing. And sometimes the right thing is to tell somebody, we, we couldn't get this done or we were wrong. You know, that's openness, right.
Of course takes a lot of courage because as we all hate to be wrong and especially me and as my wife reminds me. And , um, but in a, you know, I , I tell product owners , uh, when we're, when we're looking at their , um, their product or release plans, whatever. Yeah . That is very important that you create an environment with the team , uh, that encourages them to be open.
You know, you want them to make commitments and they're going to do the best they can, but you don't want to wait and find out, you know, right before the end of the project, that we're not going to meet our deadline. You want to , you want them to feel , uh, to be, to , to feel , uh, to have the courage, to be open and to be able to let you know, Hey, we're , we're still a long ways out, but based on our current trajectory, it's not looking great for meeting this deadline.
Let's have a conversation about it now where we can actually do something about it. Um, I worked at one organization where they would do a biweekly , sort of a PMO meeting where the representatives would come in from each project or each team and report how they were doing, you know, red, yellow, green kind of fashion. And they did the coolest thing. If, if you went from green to yellow, you got a round of applause.
Cause you're, you're having the courage to let everyone know we might need some help or we might be , uh, uh, negatively impacting other initiatives. And we're letting you know. And of course you had to come up with a plan to , you know, to get back the green. But if you ever went from green to red and you skipped yellow, Oh yeah . You had a lot of explaining to do because wait a minute, what , why did you skip yellow? Did somebody get run over my car?
You know, I mean, you rarely go from green to red within a week or two. Right. There's usually a long period of yellow .
I would hope so. Yeah. And
You know , if you don't have openness, if you don't have courage, if people don't respect each other , um, then you, we have a tendency to keep it green, as long as we can get away with it, because we don't want to get yelled at, we don't want to be looked down on. And if you create a , an environment where people can , um, can be open about that stuff , um, then , um , you're going to be much better off as an organization.
Um, and I I've only seen that one place, but I thought that was really cool.
Oh yeah. Yeah. They definitely , um, they definitely tie together and I think you tied that up really, really nicely. So if you're listening to this show, this is, has been our , uh , final episode on the scrum values on commitment. Um, we've gone over if you're, if, if they're starting with this episode, I mean to say, please go back and listen to the other four episodes. Cause they all tie in neatly together. This one we've done with Michael on focus and commitment.
The fourth and fifth episode we did the first, second, and third was courage, openness and respect. So you can see here, Michael tied them all back nice and neatly together. They all intertwined with one another to form the five scrum values that make up scrum. So our guest today has been Michael Wallace . We've been talking about commitment. He is a professional scrum trainer for improving. He has over 30 years of it experience.
And as an agile coach, scrum coach and a strong development background, we thank you, Michael, for joining us. So this has been the end of the series. I'm disappointed to see this go. I really enjoyed the series. This is really something that's near and dear to my heart near and dear to this show.
So please reach out to me, Greg Miller at the agile, within.com with comments on this episode, the series, if you've enjoyed this series, as much as we have, please let me know any suggestions you have. Please reach out to me on social media. I'm on Twitter. I'm on Facebook. I'm on Instagram. Just look up the agile within.com. I'll come up. Know find me. Thank you once again. So much Michael, for joining us. Thank you everyone for listening and hope you've enjoyed this.
This has been Greg with the agile within where we help you to be more agile.
[inaudible]
.
