Today marks an exciting day: The new Scrum Guide was released just this last Wednesday and marks some big, notable changes. The release of the new guide also marks Scrum turning 25 years old.
Join Dan Neumann and Sam Falco in this episode as they discuss all of the changes from the previous 2017 to the new 2020 guide, share their thoughts and key takeaways, and provide further insight on what some of these changes could mean form Scrum, Scrum teams, and Scrum Masters going forward.
- Notable changes to the new 2020 Scrum Guide:
- From 17 pages to 13 pages
- Clarifications on the daily Scrum, why you have it, and what its purpose is
- The statement about the immutability of Scrum went from being an endnote to being placed front and center
- They’ve taken out all IT-specific language; the 2020 Scrum Guide is explicitly reaching out to an audience beyond IT and software development
- “Developer” no longer means “coder”, it’s applied to anyone developing a solution (if you are developing a product, you are a developer)
- The new language used in the guide will make it easier to teach and apply to a broader audience (such as marketing campaigns, artistic endeavors, etc.)
- Doing away with two levels of teams (no more Scrum team which has a development team), it’s just a Scrum team now
- All roles are within the Scrum team (i.e. the Scrum team is responsible for all product-related activities)
- In the 2017 version, it says the increment must be useable
- A greater emphasis on the fact that the Scrum Master is accountable for the Scrum team’s effectiveness by enabling the Scrum team to improve its practices within the Scrum framework
- Clarification around one of the ways that the Scrum Master serves the team: “By causing the removal of impediments” vs. “removing impediments” in the 2017 version
- From “self-organizing team” to “self-managing team”
- Commitment has taken on a greater significance: Each of the three artifacts now comes with an associated commitment
- Before, the commitment on the Scrum team was to the Sprint goal; now, the product backlog has its own commitment (the product goal), the Sprint backlog retains the Sprint goal as the commitment, and the increment commitment is the definition of done
- This change emphasizes the importance of a long-term vision and eliminates the previous criticism that Scrum is just about going Sprint-to-Sprint
- Closing thoughts:
- Scrum itself inspects and adapts
- Jeff and Ken are hearing and listening to what people are saying about the Scrum Guide and are striving to help people understand it better
- It continues to evolve at a good rate
- Be sure to go read it through, start-to-finish
Mentioned in this Episode:
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.
Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner. I’m your host, Dan Neumann, and here with Sam Falco, regular contributor, co-founder, hosts some episodes all around wonderful guy.
Sam Falco: [00:30] That’s exactly what I was going to say.
Dan Neumann: [00:34] They won’t believe it. If you say it though. I don’t, I don’t think that’s how it works. Yeah. Okay. I’m a wonderful guy. Trust me, typically, at the end of the episode, we have a little bit of the, uh, what have you been reading lately? What’s part of your continuous learning journey and it’s all well and good that we do that at the end. We thought though, this time we had flipped that and put that at the beginning of the episode. So, Sam, what have you been reading as part of your continuous learning journey?
Sam Falco: [01:03] The new Scrum guide, Dan.
Dan Neumann: [01:05] The new Scrum guide. Oh, we should make an episode on that, which is exactly what we’re going to do.
Sam Falco: [01:11] Like nobody saw that coming. It’s not like it’s the episode title or anything like that.
Dan Neumann: [01:16] I never took acting classes.
Sam Falco: [01:17] I did act on stage for many years.
Dan Neumann: [01:25] Oh no. Is there a video?
Sam Falco: [01:28] Probably somewhere.
Dan Neumann: [01:30] I’m Googling that later. Maybe it was in the eighties. I mean, yeah.
Sam Falco: [01:34] Maybe somebody converted one made some yeah. VHS tape. That’s really grainy.
Dan Neumann: [01:37] Um, but anyway, going back to what we’ve been reading right there is, there is a new version of the Scrum guide.
Sam Falco: [01:48] So 2017 was the last one. And, um, Ken Schwaber teased this coming on his blog a while back and here it is. Dropped earlier this week and it is a big change. Previous revisions have clarified some things that they have sometimes added material. Um, I can’t remember which revision added the Scrum values as an explicit part of the Scrum guide, but this is a huge change. First of all, we’ve gone from 17 pages to 13 pages, which is huge. Well, it’s small, but it’s a huge change.
Dan Neumann: [02:32] Well, almost every time something gets changed, refined new software, it bloats documents, they get bigger, more, more prescriptive, more wording, more clarification. And so to have the Scrum guide becomes slimmer was a surprise to me.
Sam Falco: [02:49] Yeah. Yeah. And I’m really glad that they did. Um, I had seen something from Ken that said that essentially what they looked for was anything where people were arguing over it, any sort of thing that became dogma and well, did it need to be in, there was their attempt. They being him and Jeff was their attempt to give people guidance more trouble than rather saying, here are some events, some artifacts and some roles they interact like this have at it. So that’s part of the impetus behind stripping things out that don’t really need to be in there. For example, uh, way back when, when I read my first copy of the Scrum guide, that there was the, uh, direction for the daily Scrum saying that the team members answer these three questions then in, I think it was the 2017 revision. They said, no, that’s just a guideline. You could run your daily Scrums that way. And in the new version, those three questions do not even appear. It is simply why you have a daily Scrum, what its purpose is. And the, uh, specific guidance is the developers can select whatever structure and techniques they want, as long as their daily Scrum focuses on progress toward the Sprint goal and produces an actionable plan for the next day of work.
Dan Neumann: [04:26] Yeah. And you know, so many times, even though these, the three questions in the 2017 version were an example of how they could do it. And it moved from what did I do yesterday to, how did I help the team towards the Sprint goal? There’s still, you know, it, like you said, it became dogma. They were the three questions and there became a real lack of critical thinking, uh, towards that. And honestly, I think it made it hard to move away from the pattern that looks a lot like a status report to a Scrum Master when they show up for the daily Scrum.
Sam Falco: [05:00] Absolutely. I think as a Scrum master or as an agile coach, if I’m spinning up a team after this, probably people have already heard these three questions. They’re going to say, do we have to answer the three questions and where previously, I would say, we don’t have to. It’s just one way you could do it. I might now say, would that be helpful? Or what else might you want to do and encourage them to change it because they can do whatever works for them within the confines. And that kind of makes me think of another change that I noticed right off the bat. And that is that the statement about the immutability of Scrum, which used to be the end note in the Scrum guide about if you don’t do all of the things and you’re not actually doing Scrum and that caused all sorts of arguments. Um, people, you know, trying to say that, well, this is, this is dictated and therefore it’s not agile because it’s valuing a process over individuals and interactions. And in this version of the Scrum guide, it is right up front, right? Changing the core designer, ideas of Scrum, leaving out elements are not following the rules of Scrum covers up problems and limits the benefits of Scrum potentially even rendering it useless. Note that they’re not saying you can’t change it. They’re saying here it is. If you change anything, it might not have the effects you want.
Dan Neumann: [06:36] Yeah. And they do still have the, the immutability park at the end, but there they give you a why for, if you want to use the Scrum framework and realize its value, do the things embrace the values, support the pillars of transparency inspection that adaptation. Right.
Sam Falco: [06:54] Yes. And that was why I noticed that right up front here, here, we are saying, this is a complex adaptive system. Beware of changing anything because it might render it useless, but they, if that’s, if the implication is, if you want to, that’s fine. Just be aware that this is put together over a long period of time by people who really knew what they were doing and paid attention to details. And everything’s here for a reason.
Dan Neumann: [07:23] And around that what I, what I liked was essentially, um, paraphrasing, it says, Hey, try it as, is it being Scrum in this case and determine if the structure helps you achieve goals and creates value. If it doesn’t that’s okay. Don’t do it is what I inferred from that. Right. Here’s here’s Scrum. It’s defined, try it. If you don’t like the results you’re getting that’s okay. You don’t have to do it.
Sam Falco: [07:50] Yeah. And I like that as well, because I frequently run into that attitude of, well, how do we make Scrum work for us? And then I’ll get a description of some, some patterns or some business practices. And then, well, if you really have to do those things, Scrum might not work for you. So maybe don’t do Scrum. And people are often surprised, you know, aren’t you a Scrum trainer? Shouldn’t you be singing the praises of Scrum? And I do. I think it works very well for a wide array array of development efforts, but it’s not right for everything. And the idea that we have to force everything into this mold, I think was foreign to Scrum in the first place. I just think people, uh, tried to make it go that way. And here we have the authors of Scrum saying, that’s not true. Try it if it works for you. Great. If it doesn’t certainly you might look at well, why isn’t it working for us? Is could we get benefits out of this by changing some of our practices? But if the, to that is no, we really can’t change these practices for whatever reason, then you don’t do it.
Dan Neumann: [09:01] So, uh, early in the document, it talks about generating value through adaptive solutions for complex problems. And one of the changes that you pointed out when we first started talking about it before clicking record was this, isn’t just for IT that like they’re explicitly reaching out to make the audience more than IT.
Sam Falco: [09:23] Yeah. That’s, I mean, people have applied Scrum in all sorts of ways. There is a, I’m a high school in Arizona. It’s a charter school that uses Scrum. The students are taught Scrum. The staff and faculty are taught Scrum and they use Scrum, which is fascinating. It’s not an IT school. It is just as a high school. Um, so there’s an example of Scrum being used well beyond the purposes that Jeff and can dreamed up originally in the nineties. And it has evolved forward when I teach the professional Scrum classes, PSF and PSM. It’s one of the things that I talk about is that, well, this doesn’t have to be IT. And in some instances, we’re talking to people who really aren’t IT, we’re talking government agencies, we are talking, uh, other sorts of complex work that is not IT. And so by stripping that out of the Scrum guide, it makes it easier for people to start adapting it because they’ve not just specifically said, Hey, we can go beyond IT. They’ve taken out things like there’s the reference to testing or design, or I don’t even think the word requirement appears in this.
Dan Neumann: [10:42] I don’t recall seeing it.
Sam Falco: [10:45] But the idea is they’ve taken away all of that IT-specific language because it’s not just for software development anymore. It’s for any sort of complex work.
Dan Neumann: [10:55] Yes, I think the only, the only word that really for me seems to still speak it is the term developer, Scrum Master Product Owner and developer. And I don’t know how that applies or, or, um, yeah, I guess IT developers in an education sense. It just works. You’re not the Scrum Master. You are not the Product Owner, but you are on the Scrum team.
Sam Falco: [11:16] Right. You are developing the product. Therefore you are a developer. And we used to say this anyway, before this change, when we would talk about the development team, that it didn’t just mean developer, meaning coder, it meant anybody who’s involved in developing the product. So in this case, now we’re moving beyond that idea that you, uh, you have to be a coder. You have to be involved in IT in some way. And just, if you are developing a solution, if you are developing a product, you are a developer. And this, the quote that I highlighted in this, we’ll use the word developers in Scrum, not to exclude, but to simplify, if you get value from Scrum, consider yourself included. So that inclusive language really hammers it home. There’s a lot of other changes in here that really jumped out at me and one that I love, I like a lot of this. This is a, this is fascinating. Um, no, I’m really excited to buy this change because it’s going to be easier to teach it to a broader audience is going to be easier to apply it to a broader audience. Just think about other types of areas where we could be applying this: Marketing. Uh, a marketing campaign could be something we are developing, using Scrum. We can apply it to artistic endeavors. Uh, really a, um, a theater endeavor. I was an actor a long time ago. It’s sort of a Scrum team. You’ve got your, your, your cast, your crew. You’ve got your director as a Product Owner, essentially with the vision. And you’ve got a stage manager who is sort of like a Scrum Master. So you could, I would love to see somebody. So, you know, we’re, we’re gonna, we’re gonna do a play and we’re gonna use Scrum to develop it.
Dan Neumann: [13:33] We were doing a coach community of practice, a Scrum Master community of practice. I forget what official title it had at this one place. But yeah, we had a guy who managed a theater troupe in the evenings. That was what he did for fun and applied Scrum. And by the way, he kinda got the people’s side of agility too. And it was way better than some technicians who have tried to fill the Scrum role. They just kind of sometimes miss the whole people side. So yeah. Wonderful change to make it less IT-focused. Yeah. Want to talk about commitment.
Sam Falco: [14:04] Yes. Let’s talk about commitment. Let’s do the commitments been this hairy nightmare sometimes for, for me as a Scrum master, as an agile coach, because it comes with all this weird baggage, right? Uh, an early draft of the Scrum guide said that the team committed to the PBIs selected. That was changed to, we commit to a goal, not scope, not set in specifically in those words, but it did say that we commit to a goal and commitment then as one of the Scrum values, one of the things I always have to talk about is this is not commitment in the terms of we are going to do this, or we’re going to, uh, stay awake all night, getting it done, that it is a commitment to, to working together, to working on quality, et cetera. And in this iteration of the Scrum guide, commitment has taken on another significance. And that is that each of the three artifacts now comes with an associated commitment. So before our commitment on the Scrum team was to the Sprint goal now, and that’s, that’s associated with the Sprint backlog. Now the product backlog has its own commitment. That’s the product goal we’ve introduced to this concept of a forward-looking larger objective than just Sprint to Sprint, to Sprint. Sprint backlog of course retains the Sprint goal as a commitment. And the increments commitment is the definition of done, which now loses the quotation marks around done little scare quotes that used to be there.
Dan Neumann: [15:45] It’s not really done. It’s just air quote and done air quote done.
Sam Falco: [15:52] Is it done or is it done, done.
Dan Neumann: [15:55] Done, done? Yeah. How many Done’s could we put it through? Right?
Sam Falco: [15:58] Right. And it just sort of sounded like dun dun dun.
Dan Neumann: [16:02] And I, so I like the, you mentioned the product goal. So a new, a new concept that emerged. And what I like about that is it really helps inform the Sprint backlog. I was in a conversation recently and there was the hey, when this product needs to happen so that the organization can do this. And I was like, Holy cow, like, that’s brilliant. Like somebody, somebody cares. We have, we need this so that we can achieve this over here. And it was the first time. Cause then that informs the product backlog and you go need that need, that don’t need that. Don’t need the other thing we want that. Not that because you go, okay, we need to achieve this. This is our goal. And now you can ruthlessly go through that backlog and throw stuff that is aligned to that out.
Sam Falco: [16:50] Right.
Dan Neumann: [16:52] I got excited. That was fun.
Sam Falco: [16:54] It is exciting. When people understand that in here, this also speaks to a criticism I’ve seen of Scrum. I don’t know if this was part of their thinking, but I have seen Scrum criticized because it didn’t have that longer goal explicitly in it that, well, you’re just going to be going Sprint to Sprint and you lack a larger vision. Now that’s silly because just because the Scrum guide didn’t say you shouldn’t have, I just mixed my language up just because the Scrum guide says that you didn’t.
Dan Neumann: [17:24] Love the negatives. Yeah. Um, yeah. The Scrum guide didn’t prescribe the product to goal, right. So it doesn’t mean you shouldn’t still have one.
Sam Falco: [17:36] There was a lot Of things that you should do or good to do that aren’t in the Scrum guide, the Scrum guide also, doesn’t tell you that your Scrum team should probably bathe every day
Dan Neumann: [17:50] I’ve been working from home long enough that I can. If I didn’t run, that might not happen.
Sam Falco: [18:06] But this one’s really important. Also as personal hygiene, I feel like we’ve lost the thread.
Dan Neumann: [18:10] Come back to this thread, the thread let’s commit to the thread.
Dan Neumann: [18:14] Let’s commit to the product goal for having a quality podcast.
Sam Falco: [18:22] But the, the explicit, no Scrum does care about a longterm vision. A product goal, making that explicit, I think is a good move because it gets rid of that criticism that you’re not really, uh, steering a steady course that you’re just going from Sprint to Sprint. Well, each Sprint is a step towards that product goal. And, and as you say, it’s easier to get rid of things. It’s easier to say we shouldn’t be pulling the team in multiple directions. Let’s just get them to focus on what’s important to the product instead of just stuffing things in the backlog that are anything we think that the team might need to work on.
Dan Neumann: [19:06] Right. The backlog was just list of stuff a lot of times. And so now we have a product goal. You have Sprint goals that are intended to be steps towards that product goal, not just two weeks worth of activity, three weeks, a months worth of activity. And then the increment is actually done. It has achieved its quality expectations, every Sprint as well.
Sam Falco: [19:32] Yeah. And then of course the Sprint goal gets added to the Sprint planning topics. That’s another change here used to be that the Sprint planning had two questions. What do we want to do? And how are we going to do it? And now we consider first, why is this Sprint valuable? What is it we are trying to achieve? And explicitly Sprint goal becomes the forefront of our conversation only then do we say, well, what is it we’re going to, to do in order to make that goal? And then how are we going to do it? So that’s another, another change. Those conversations were probably happening already with teams that were doing Scrum well, right? Because we were supposed to emerge from Sprint planning with a Sprint goal before, but now it is that right up front. The very first thing we talk about, why, why are we doing this? Why is this going to be valuable? And then the other big change. And I am so relieved to see this is we do away with two levels of team. We don’t have Scrum team, which has a developer team or development team, which used to drive my students crazy. It drove me crazy because you’d say team that, wait, which team am I talking about?
Dan Neumann: [20:48] Maybe this will finally do away with some of the chickens and pigs thing too, but that’s probably too much to hope for.
Sam Falco: [20:53] I haven’t heard that metaphor used in a long time.
Dan Neumann: [20:56] I didn’t say it on the podcast. When I was a kid, we had chickens and pigs and they’re awful little story about bacon and eggs. Yeah. Good. Okay. So Scrum team back to where we are, the Scrum Master, Product Owner, development developers. Right? Right. But not any development team, all one Scrum team.
Sam Falco: [21:19] Right. And I just kind of wish this was a video podcast. So people could see the look on your face when you’re doing the old man Dan voice because some would tell you it was priceless.
Dan Neumann: [21:29] Oh, that’s again, no acting skills. You all this natural, maybe, maybe as part of year two for the podcast, we’ll eventually start doing something Facebook live or YouTube live. So they get the pure unadulterated unpolished over by our production folks. But back to the team.
Sam Falco: [21:50] A few more years when I’m closer to retirement.
Dan Neumann: [21:52] So Scrum team, Product Owner, Scrum Master, and developers.
Sam Falco: [21:58] Right. And that’s really important because there was sometimes a perception that Product Owner wasn’t part of the team because all their Product Owner was part of the Scrum team, not part of the development team. And I would hear people say, well, the Product Owners shouldn’t be in the retrospective that’s for the team. Yeah. Yes. The entire team of which the product teams is apart now, there’s no longer that argument. And so the language changed from typically three to nine members of a developer team development team to 10, or fewer members typically on a Scrum team. So we just changed that, that number. And then the entire Scrum team is responsible for all product related activities. So that phrase is in there. So again, it’s not the development team is responsible for developing the increment and the product owner goes away. The product owner is part of the Scrum team as, as the product owner always was. But now it’s explicitly part of the role responsible for all product related activities, product owners involved in that, and is accountable for creating that valuable, useful increment, every Sprint.
Dan Neumann: [23:05] Yeah. And, and what I also liked about that kind of Scrum team responsible for all product related activities is it goes on to list out what some of those might be, which includes maintenance and operations. So it isn’t one team makes a mess and somebody else has to support that garbage. Or, you know, we’re going to write it, but you guys are responsible for making the performance and operating it. It’s like the Scrum team is responsible for the product.
Sam Falco: [23:31] Right. And that’s another, that’s something we’ve always taught, but people sort of fudged around that. I think partly again, because Done was in scare quotes, scare quotes, uh, and Done was, well, we got it to production. And as long as we didn’t sneeze on it, it would run. But once it’s in production, it’s y’all’s job to fix it a maintenance and support team. No, the whole Scrum team is accountable for that. And I think that that also contributes to an attitude of wanting to create higher quality increments. Because if you knew, you’ve got to support this thing, well, you’re not going to kick the can down the road as much.
Dan Neumann: [24:10] Something that jumped out to me about the increment kind of hopping back a little bit to artifacts. But, I think the 2017 version talked about potentially releasable increments and the new one refers to the increment must be usable. And I thought that simplification, okay, is this thing useful? It doesn’t talk about releasing it. Well, does that mean to production, to UAT, et cetera, use this increment, the thing we built actually useful.
Sam Falco: [24:38] Yeah. Yeah. The phrase, the word usable. Yeah. The phrase usable appeared in the last Scrum guide. It may have appeared in earlier versions as well, but it did get overlooked for that, that loaded word potentially releasable. And there’s always an argument about that. Like, I, I can remember every class I taught, well, what does potentially releasable mean? And it seemed like a way out, Oh, potentially releasable doesn’t mean actually releasable so it can have all sorts of deficiencies. Or then there was the argument. What about user acceptance testing? Because our organization does it this way, and now we just say it’s usable. I like that simplification again.
Dan Neumann: [25:22] I’m sure there’ll be a new argument about it, but still it’s, I’m sure I’m optimistic. I liked the change.
Sam Falco: [25:29] Yeah, I did too. And I loved this, the Scrum master being accountable for the Scrum teams effectiveness by enabling the Scrum team to improve its practices within the Scrum framework. Once again, always a concept that was part of the Scrum guide, but highlighting that what we are there for is to help the Scrum team be effective. That is the role of the Scrum Master, none of this talk of servant leader, which is a, I don’t believe is in this version either. I mean, yes, it is the type of leader we need to be to be Scrum masters, but it kind of had this Jedi master mystic. We’re not quite sure what this is. No, here we go. How do you know if you’re effective as a Scrum Master, is your Scrum team effective because they’re continually improving. Awesome. Now I know this is my, this is how I’m adding value. Yeah.
Dan Neumann: [26:21] Much more clear than am I doing a good job of servant leadership.
Sam Falco: [26:24] Right. And also I loved that the Scrum Master, one of the ways the Scrum Master serves the team is by causing the removal of impediments used to say removing impediments. And I remember when I first became a Scrum Master, that kind of drove me nuts because there were impediments I could not remove by myself, had to get other people enlisted. And this is no, you are causing the removal. So, okay. How do I cause the removal, I go talk to people. I get them to help with removing impediments. So subtle maybe, but I really like that distinction being made.
Dan Neumann: [27:02] Regarding the team, an interesting change, uh, from self-organizing team. And now the term is self-managing.
Sam Falco: [27:12] Yeah. And that at first I didn’t care. Like I saw that I’m okay, just a change of terms. Right. And then I was talking about it with Becky Hartman. Who’s also a PST, one of our AgileThought colleagues. And she said, well, that just kind of up as we’ve always said, self-organizing doesn’t mean self-managing. So now we’re saying self-managing and what does that going to mean? And the more I thought about it, the more difficult it got in my mind. And here, I think what we’re talking about is, and Ken has said that self-organizing is a broader term than self-managing. And so what I believe has been meant as self-organizing before or considered to be self-organizing were organizational design questions. And we’re saying that’s not the province of Scrum teams, but that is for the organization at large to work on. Certainly Scrum teams could contribute their thoughts and their practices to that, but just self managing, how are we going to work together, get the work done. So I don’t think the way I have been teaching it changes just the word, but yeah, at first it was like, okay, let’s just a word change. And then it became a big existential, Oh my gosh, what am I going to do here? And then, uh, you know, all right. I think I figured it out. So I’ve come back to where I was, but it is, uh, it is, uh, a subtle change that many people will look will overlook, but I think it is important.
Dan Neumann: [28:49] Yeah. And it gave an example, you know, figuring out the what and the how and the who, that’s all part of the self-managing of that team to figure out how are we doing this? Who’s doing it. When are we doing it?
Sam Falco: [29:01] Yeah. Who’s going to sit over there by the window. Uh, I think is for the Scrum team to decide, Oh, you know, that kind of thinking without desk assignments.
Dan Neumann: [29:14] No, I ran into that third rail at a place I was at, uh, as an employee because people worked many, many years to go from the inner cubes to the window, the window cube to the corner window cube before they eventually were promoted into an office. Yeah. So in a lot of places, I agree.
Sam Falco: [29:34] Yes, I suppose so, but I’ve seen it work so well, just a natural thought on one of the teams that I was coaching, of course, the ninth floor in the Tampa offices at AgileThought, I have this beautiful view of the Bay, and there’s really not a bad view in the, in the office, but here’s your area for this team. And people just figured out where they were going to sit and no one told them you’re going to sit closest to the window. You’re you’re not people just figured out where they wanted to sit what was available. And it worked. I, I don’t think there’s, I don’t think it’s that big a deal, but I have seen it at organizations where it really is like this hierarchy and this weird, like, no, you have to ask permission to move one desk back so that you can be closer to the person you’re gonna be talking to every day. That’s just nuts to me.
Dan Neumann: [30:24] I think we should put a couple of the windows shots up as virtual backgrounds, I think it would make that happen. Put it with the show notes. It is nice. And so if it was a virtual background of the Tampa Bay,
Sam Falco: [30:34] Yeah. I remember the first time I went to a Tampa Bay, agile meetup that was at the AgileThought offices I walked in. It was, it was sundown or something was going down and it’s gorgeous. And I said to someone, I have two questions, one, how does anybody get any work done around here? And two, how do I work here? It took me a couple of years to get there, but anyway, we’re going way off topic.
Dan Neumann: [30:59] Yeah. But you know, occasionally check out agile thoughts website, occasionally we’re hiring Scrum Masters product owners. Um, yeah. There’s a lovely view of the Bay for folks in the Tampa area or for sure. Backgrounds for people like me to live in Indiana. Right. So Sam, what closing thoughts do you have about the latest revision to the Scrum guide?
Sam Falco: [31:17] Well, it’s exciting that we see once again, that Scrum itself, inspects and adapts itself, that it is not Holy writ handed down from on high, that never changes. But Jeff and Ken, see what people are saying about the Scrum guide. They see how people are using it and they react and respond in order to help people understand it better.
Dan Neumann: [31:44] I like that as well. It continues to evolve, you know, for me, you know, not at a goofy rate, but every once in a while, and this time it got a little slimmer, uh, there was a Facebook group, uh, related to Scrum Masters. I don’t know somebody was asking if I’m a Scrum Master interviewing what, you know, what should I kind of know or et cetera. And I’m like, know the Scrum guide. Right. Go read it again. Make sure you understand.
Sam Falco: [32:07] Sometimes for the first time I can’t tell you how many times. Yeah. I can’t tell you how many times I’ve talked to somebody and they say, Oh, I’m a Scrum Master. And I’ll say something about Scrum guide and they’re like the Scrum what now? You know, the thing that tells you how to do Scrum, Oh, I just do what I was handed to do.
Dan Neumann: [32:26] It used to be, I used to say, well, it’s only 16 pages. Now it’s only 13 pages. Read the Scrum guide. Be able to talk about how you do it well, or how you have tripped on yourself doing it. And from that, and I that’s free free job interview advice. If you, if you use terms like stand up and ceremonies and commit in an inappropriate way, you’re not going to get the job.
Sam Falco: [32:53] Or if you’re going to get the good. Yeah. You’re going to get the job at an organization. That’s doing Scrum, horribly wrong. Yeah. Um, which we see all too often, but I think, yeah, simplifying it down from 17 to 13 pages makes it even easier. You can read 13 pages for crying out loud. You can do it on coffee break.
Dan Neumann: [33:14] I’m a slow reader in defense of slow readers. It took, I mean, it was, it would be a long coffee break, but on that note, we’ll have to come up with something else to read for the next time we do this, Sam.
Sam Falco: [33:22] Yes. Yes, we will.
Dan Neumann: [33:24] Thanks for your time.
Sam Falco: [33:25] Ciao.
Outro: [33:28] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.