Jade Meskill: Hello and welcome to another episode of ScrumCast. Iâm Jade Meskill.
Clayton LengelâZigich: Iâm Clayton LengelâZigich.
Roy vandeWater: Iâm Roy vandeWater.
Derek Neighbors: Iâm Derek Neighbors.
Drew LeSueur: Iâm Drew LeSueur.
Development Team
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 shippable 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.
No Commitments , Just a Forecast
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 Ken 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.
No More Burndown Charts
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.
Release Planning Isnât Necessary
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.
No Need To Decompose Work
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.â
Product Back Log Ordered, Not Prioritized
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]
Discussion And Change Is Good
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.