Jade Meskill, Clayton Lengel-Zigich, Roy van de Water, Derek Neighbors and Drew LeSueur talk about new changes to the SCRUM Guide.

• “The Development Team”
• Commitment vs Forecast
• Burn down charts
• Release planning not necessary
• Sprint backlog items bye bye
• Ordered vs prioritized

Transcript

Jade Meskill:  Hello and welcome to another episode of ScrumCast. I’m Jade Meskill.

Clayton Lengel‑Zigich:  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.

Jade:  Today we want to talk about the new addition of the Scrum guide that came out from Scrum.org. There’s been a lot of controversial changes that have been made. Some tweaking to the language, a few different things and we’re just going to go down the Scrum update bullet point by bullet point. Share some of our feelings and opinions.

To kick it off, let’s talk about the first change that they talked about here. The team of people performing the work of creating an increment, is the development team regardless of the work performed by individual team members, they are known as developers. What do you think about this?

Roy:  I like it. I can tell by the way you are looking at me that you don’t like it Jade.

[laughter]

Jade:  I’m just moderating here. [laughs]

Roy:  I like the essential idea of it because I’ve seen with multiple scrum teams that when they go in they run across the concept…we even came across with this at Integrum last week where we said, “What if only one guy is able to perform this specific task”?

We have all these people who are able to work but there’s one thing like, “That’s Jade’s job. Jade’s the only one who can handle that.” I think that’s a big problem. I think that is what they’re trying to address here, is that everybody should be cross‑functional, everybody should be able to perform any of the work inside of this sprint.

Clayton:  I think some of the hangup comes from as a developer, like software engineer, you think of the word developer meaning someone who writes software. I think if you take a step outside of that you could say the word developer really means someone who’s developing something that gets to potential shipable software. I guess I’m OK with this one. I don’t think there’s too much wrong with it.

Derek:  I think that one of the problems you have is on a lot of teams you might have Q&A, and database administrator, an architect. Everybody identifies themselves differently, and so in other language if it’s said the programmers there would be people who say, “I’m not included in the team because I’m a Q&A person, I’m not a programmer.”

By switching it to developer I think they’re using a little bit softer language. I think you could even argue that it allows for scrum outside of software. So from a project management framework perspective, a developer could be anybody creating something. If I’m developing something, whether it be a courseware, or a piece of art, or whatever, I’m a developer. I think that they are softening the language for the some ability to go outside of the network.

Drew:  Yeah, I agree as well, I think the core idea of this change is to unite the team, and let’s give them the same name.

Jade:  All right, let’s move on. The next bullet point ‑‑ Development teams do not commit to completing the work planned during the sprint planning meeting. The development team creates a forecast of work it believes will done, but that forecast will change as more becomes known throughout the sprint.

Roy:  That sounds like the exact opposite of a locked‑in sprint. The idea’s always been ‑‑ we lock in the time, the development team gets to establish the scope. If, now we get half‑way through the week and I don’t think I’m going to be able to make it. In traditional Scrum, that would be a huge deal and you would have to have an early sprint termination, and you’d have to replan or restart your sprint, and that should be a painful process because that should happen very rarely.

Derek:  To me, this is the pussification of Scrum.

Jade:  That’s the exact word I used before we started.

Derek:  Straight up ‑‑ it went from, this is a contract whereby you commit to the work ‑‑ you get to decide how much work you commit to, you commit to it, and the other side of the contract is that you do not have to accept change that comes in as part of that contract.

In fact, at one time, my understanding is that the right way to abnormally terminate a sprint because of change, was to physically throw yourself on the floor and scream bloody murder like a young toddler until you got your way that the change went away or that management was sufficiently known that bad things were happening between the contract ‑‑ between the team, the development team and the product owner.

And now we’re using language that says, “Well, you know, the team just kind of says that they would like to get this stuff done, but if the world changes, and stuff happens and we’re not really making a commitment.”

Roy:  I think, too, the guy that coined that way of doing an abnormal sprint termination is Kent Schwaber, one of the guys who signed the…

Derek:  That’s correct. I think what they are trying to do is remove absolutism or pragmatism, and I think by softening the language they’re going to do the exact opposite of that. So they went from something where it’s very hard ‑‑ you terminate the sprint in this way, and you’re a total asshole about it ‑‑ even if it’s the right thing to do.

To now, “We don’t want to ever say you ever really make a commitment because that’s sometimes not the right thing to do,” and I think that really it’s a middle ground where you should be making a commitment.

The commitment should be something that you really honor. But, if there is valid reason to change, to terminate, or to do that, or there is some ability to negotiate, I think you should be able to do that. I think, by going to the wishy‑washy language, they really don’t help anybody. You’re going to have teams who say, “I don’t have to commit to anything. What are you talking about”? If I can only do a 5, even though I told you I could do a 50, that’s Scrum.

Clayton:  Yeah. I think that the second part of this, where it talks about how more we’ll become known during the sprint, I think that’s just another way of saying “negotiation.” I think we do that now already, where, if something comes up, you can negotiate that. Maybe it’s a big deal, maybe it’s not.

I think the change from commitment to forecasting, what’s been interesting for me is, if following all this on Twitter, there’s been a lot of people that have said things like, “I think ‘commitment’ is a great word, because I want the development team to feel the weight of the world on their shoulders, like they feel like, ‘Hey, this is a really big deal.'”

Then, other people are saying, “Gees, the weight of the world, and I want to make the development team feel like they have to do it.” Those are all very negative words. I agree with you that’s a pussification.

Derek:  Scrum pussies.

Clayton:  Right. It’s like, “Let’s be very gentle and let’s be very cautious of not making people feel bad,” that kind of thing. I agree that there’s a lot to said be for the feelings, the emotions, and the words that we use, but, at the same time, I don’t think that the “commitment” stuff is negative, necessarily. I don’t think that has to be a negative thing. I think that can be viewed as a positive thing.

Roy:  I think that too. As far as the negative emotions of saying, “You have to get this done,” “Well, yeah, I committed to it. I said that I would get this done,” and whether you see that as negative or not, it shouldn’t be a negative thing. If I said I can get this done, then there shouldn’t be anything negative about me getting it done. That should be a positive thing.

Derek:  I’m pretty trying to go back to my wife and say that I’m not really happy that we’re married and I made a commitment. I would like to forecast that we will be together for the next six to seven years…

[laughter]

Derek:  …and we can renegotiate another six to seven years…

Jade:  …as more information becomes available.

Derek:  …if we get more information.

[laughter]

Clayton:  I will say that, since I read the actual longer‑winded update about “order” versus “prioritize,” which we’re going to get to in a second, I will say I will withhold judgment on this one until we get the full explanation, but my gut feeling is that it’s what we’ve been talking about.

Roy:  My other thing is one of the things that Derek mentioned when he was talking about the pussification of Scrum, where the idea of the commitment is that I say I’m going to get this done and commit to absolutely getting this done and locking the sprint. That’s my part of the deal.

The other part of the deal is that I won’t get interrupted with any requests. That’s not really a sacrifice, but, if I don’t make that promise that I’m going to get something done, and if I don’t give something from myself, then why should the other people, why should stakeholders or product owners respect the fact that I have a locked‑in sprint? If I can change my mind halfway through, why can’t they?

Drew:  Also, I think, with the word “commitment,” right, Clayton, you talked about how people might feel bad if they don’t get it done, or it’s the downer term. But still, I think, obviously, there are going to be times where you don’t reach your commitment, through whatever reason.

But the fact that it is a commitment and they set it as a commitment, and then you didn’t hit it, that brings up a conversation: What causes you to not hit your commitment? And that brings up, maybe, an underlying issue: If you just say it’s a forecast, and, “Oh, we didn’t hit it. Oh, it’s OK, because it was a forecast, anyway,” then, maybe, the underlying issue of the real problem, “Why you didn’t hit your forecast or commitment”? It’s not going to be brought up.

Roy:  Right. We’re almost getting into the wishy‑washy territory of having the commitment be the same thing as estimates, where you’re like, “OK. Well, we didn’t do this in twice the amount of time as the other tasks, so our estimates are wrong. Well, who cares about estimates”?

In this case, they’re forecasts, but a forecast should be commitments, and they should be accurate. If they are wrong, we should do something about it.

Derek:  Yeah. I think it is they’re trying to soften the language to change the emotional tone. On that level, I don’t have a huge problem with it, but I also think that it does fundamentally change the contract or the original intent. This really changes it more to, “Ah, we’re estimating what we can get done this week,” opposed to, “We’re going to get this done.”

To me, one of the biggest things that I see people interested in adopting Scrum for is they want predictability in work, so that they can understand, as a sales team or as a CEO, how can I determine what the future of this company looks like based on the work that can be committed to. If it really becomes a super loosey‑goosey, forecasty type of thing, the predictability goes way, way down, because nobody trusts a forecast, especially when it’s really seen as a forecast.

Maybe over time, if you hit your forecast considerably and do that, then maybe it is something that people feel can be predictable. But I don’t know. I’m a little torn over this. I think they’re going a little bit too wishy‑washy for my liking.

Jade:  Let’s keep moving down. Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that remaining work for a sprint is summed and known on a daily basis. Trending toward completing the work of the sprint is maintained throughout the sprint.

Roy:  OK. If you don’t want a burndown chart, you want to represent it using something else, whatever. That doesn’t bother me. I think it’s a good idea to have a burndown chart, but I don’t think that particular format needs to be the case. I like that it says how much work is left. It needs to be known every single day. That makes sense.

Clayton:  I think they clarified this in some of the other documents where they wrote about the documentation. They say that they’ve tried to remove some of the tips and best practices, and they’re going to put those out as a separate document, so I think this is thinking that out.

Jade:  So they’re just going to move to best practices.

Clayton:  Right.

Derek:  I think this is a case where they so specifically said everything that happens in a burndown chart that it almost makes it say, “Really, you have to do a burndown chart unless you can come up with a better way to achieve all the exact same objectives of a burndown chart,” which, to me, is a good way, I don’t think they’ve softened what they’re asking for. They’re just being more open to different ways to do it that they may not know today.

Jade:  Let’s keep moving quickly through here. Release planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.

Clayton:  I think it falls in the same category.

Jade:  The sprint backlog is the product backlog items selected for the sprint, plus a plan for delivering them. There is no longer a required concept of spring backlog items, although that technique can make a great plan. A self‑organizing development team always has a plan.

Derek:  I think one of the clarifications here is that sprint backlog items is generally what I think a lot of teams call tasking. When you dig your stories from the backlog into the sprint backlog, the sprint backlog items are not the stories that you’ve selected from the backlog, moved into the sprint backlog, they’re actually the tasks for those stories, is my understanding of their original concept of a sprint backlog item.

In this case, I think they’re saying, “It’s not necessary that you task out all of the details of the stories to do the work, but a good team has a plan for how they’re going to do the work.” I take that very similar to the burndown effect, where they’re saying, “You still have to have this element if you’re doing a good job, but we’re not going to say the tasking is necessarily the way that you do that.”

Jade:  All right. Finally, the product backlog is ordered instead of prioritized, providing flexibility to the product owner to optimize value in his or her unique circumstances.

Clayton:  When I read this one, I had the same reaction as the forecasting commitment. At first glance, it’s just semantics, where it’s like, if you were really taking to the letter of the law, and you were saying, “I have to prioritize these, and, to me, priority means the most important ones at the top and the least ones at the bottom, and there’s no other way I can do it,” I guess, if you really took it that way, and you’re really being pedantic about it, then yes, that’s what you would think.

But I feel like you would be able to exercise some flexibility and say, “There’s some other ways.” This is more important, and I think they get into that with the blog post that they posted today about order, not prioritize, where they actually go into the details about this. I think they do a good job explaining why it really is just…they’re opening up the different ways that you could prioritize.

Priority is not maybe the best way to do it, and there are lots of different ways to order a good backlog. You don’t necessarily have to order by ROI all the time. There’s some things that would be more valuable than others at different times, and there are a lot of different relationships that certain backlog items have.

You have to look at them all together. I think the document they’ve put out since then has really explained what they mean by this, so I think it makes more sense. If this helps people to understand the intent or the meaning behind what it means to order or prioritize a backlog, I think it’s a good thing.

Roy:  I agree. I’ve seen situations in the past where a product owner would go through, they’ll take 20 backlog items to go through, and 5 of them are priority one, 3 of them are priority two, and so on. Then they don’t think of it in terms of which one gets done first.

They’re like, “This one is really important. This one is more important than all of these other ones, but these are all about equally important,” and, when we get into sprint planning, that makes things very difficult, because, then, when we start the week, they don’t know which ones to pull in.

If you spend the time thinking about ahead of time, and the article that you mentioned talks about doing a bubble sort, where you take each story, you compare it to the one above and the one below, and say, “Is this one more important than this one”? Or, “Should this one be done first, or should the other one be done first”?

If you go through and order the entire backlog that way, I think you’ll get a lot more value out of that than just assigning a priority number to each one.

Derek:  Pussification of Scrum again.

[laughter]

Derek:  I think the problem is you’ve had 15 years or 10 years of, basically, poor definition of the word “priority” to product owners, probably from Scrum Masters or the development team, so everybody thinks of priority is low/medium/high, important/not important, critical…those are the words we think of when we think of priority.

I don’t think that’s the definition of priority. I think priority can be one, two, three, four, five, six, seven, and, when somebody says, “One through five were all the same to me,” I can call bullshit. Do you want to be in fifth place or do you want to be in first place? Those are not the same things.

You need to learn what is really number one, what is really number two, what is really number three, what is really number four…

Roy:  I think that’s the order addresses. That’s less ambiguous than prioritize, because prioritize can mean different things to different people, but order is always the order that they are on the backlog.

Derek:  I agree, but I also think it pulls out and also makes things a little bit less of a language do. Order doesn’t have nearly the urgency to being ordered. If you say, “Can you order those”? Yeah, you can order them, but is there an urgency to having them ordered?

Where a priority gives to me the thing that is on the top of the order is more important than the thing on the bottom of the order. If I order something, I can reverse‑order something, and the most important thing then be on the bottom or top. When I call something a priority, I expect the thing on the top to be the most important.

I think where they’ve gotten this muddy language is they’re like, “It’s by business value, or by this, and there are different ways you can prioritize, so we need to…” No. That’s not the fucking problem. I think that you can definitely prioritize by different things, and you can do that on a case‑by‑case basis.

You can come in and you can prioritize one week based on business value, and, another week, you can base on customer demand, whatever. You’ve got the ability at the end of each increment to move this however you want. The problem is that they don’t want to talk about the real problem with the language, and that is that telling product owners that they may have to make hard decisions. You have to know, “Is this story more important than this story”?

I think that most teams get away with letting product owners go, “Well, this block of things are all the same to me.” I don’t think calling it ordered is going to make that problem go away at all. I think it’s just going to compound it.

Roy:  I think there’s a problem too even with they’re using the word “important.” I think Drew and I have had discussions on this in the past. Let’s say you have two items. One is pretty important, and I’ve got another one that’s about half as important, but it takes a fifth of the time to complete.

When I’m talking about “important,” I mean it’s going to earn me a dollar value. The other one is going to earn me half the dollar value, but it’s also going to take one fifth of development time.

Derek:  That’s why the product owner gets the big bucks. He has to make that decision to say which one is the one that needs to be done first: the one that takes longer but makes me more money, or the one that I can get done quicker and doesn’t make me as much money?

Roy:  Or which ones I have are higher priority. I think “priority,” in this case, is a loaded word. That’s why I like the idea of doing it from order, like, “This one is first over the other one.”

Derek:  How is calling it “priority” over “order” any different?

Roy:  Because, even in the way that you described ‑‑ you said, “This one is more important than the other one” ‑‑ it’s not more important. It’s half as important. But it gets me money faster.

Derek:  How is it not more important? If I want it done first, it’s more important.

Roy:  I don’t think that’s necessarily the case.

Jade:  Priority doesn’t mean importance either.

Drew:  Right. People attach maybe money value with importance. “This makes me twice as money. It’s going to be more important. It’s going to be more priority.” But that’s not necessarily the case.

Clayton:  Yeah. The problem I have is I think a lot of the reasons they give for why they switch order is they talk about how there’s so much complexity about, to quote this article, knowledge of evolving market windows, market conditions, engineering dependencies, knowledge of business.

There are all these things that go into it. I feel like, if you’re the kind of person that really understands those things, where you could make use of this concept, the actual paradigm difference in ordering and priority, if you actually understand all those things, I don’t think you get hung up on the word “priority.”

I don’t think you say, “I have all this knowledge, I’m a very intelligent person, and I understand all the nuances, but the word says, ‘priority,’ so I have to do it by priority.” I don’t see that happening, so it seems almost meaningless at that point.

Roy:  But with the beginners, just people first coming into it, I think they do get hung up on the word “priority,” and I think that “ordering” would set them on the right path quicker than using the word “priority.”

Clayton:  But I think the point they’re making is that you can order a lot of different ways. I think you can prioritize a lot of different ways. In the product owner training that I attended, there were lots of different ways to prioritize. It wasn’t that you just prioritize by one…

Roy:  It wasn’t just alphabetical.

Clayton:  It wasn’t just you prioritize by ROI. There are lots of different ways to prioritize. I think, if you understand that and you realize it’s not just by what’s most important or just ROI, then it’s meaningless at that point.

Roy:  But I think it’s harder to get people to actually understand that and internalize that.

Clayton:  Yeah. Had they called this “order” originally, and then now they’re changing to “priority,” I guess we would be just having this exact same conversation.

Derek:  Here’s my problem with it: it’s the definition of why they’re making the change. If they said, “We’re going from ‘priority’ to ‘order’ because we feel “priority” is a loaded word that confuses new product owners,” I would be totally supportive. That’s not what they’re saying.

They’re saying, “We changed from ‘priority’ to ‘order’ because you can’t prioritize things by different things.” That’s [bleep] . I’m sorry. I’m sorry, flubber. You’re a [bleep]. Now, if you want to say that you changed it because the language is confusing, I absolutely buy that. “Priority” is absolutely a loaded word. But that’s not what they’re saying. I disagree with their reason for the change.

[laughter]

Jade:  All right. Hold on that wonderful note. Let’s wrap this thing up. Let’s take the next 30 seconds or so and just talk about what are your feelings overall with this change, what are you most afraid of. 10 seconds each, tell me what’s you’ve got.

Clayton:  All right. I think it’ll generate a lot of discussion on social networks, podcasts, and things like that, and, in six months, it’ll be totally forgotten.

Roy:  I think that generating the discussion is a good thing to bring visibility to the Scrum and agile. The only element on this that I’m really concerned about is the term “forecast” instead of “commitment.” The rest, I’m either impartial or I actually prefer.

Derek:  I love the fact that they’re actually making change for a framework that’s all about, and “Inspect and Adapt” has not changed much for 10 years, so I cannot give you credit for having the balls to make change.

[laughter]

Derek:  The thing that concerns me the most is the comment that says that we have worked “closely with the community,” and they name two people that they’ve worked within the community. I’m sorry, this community is now tens or hundreds of thousands of people. The way you approached change is probably not the best.

Drew:  Yeah. The only thing that I’m really fearful of is the “commitment” versus “forecast” change. I think that “commitment” is a good, solid word, and I would like to hear people use that.

Jade:  All right. Thanks a lot with that. We will wrap up this ScrumCast. Thanks for listening.