Podcast Ep. 128: The New Scrum Guide: The Three Changes YOU Need to Know About

Episode Description:

This week on the Agile Coaches’ Corner Dan and Sam are switching things up with a new episode format. In this episode, they’re looking back on Sam’s three-part Trainer Talk series on the key changes that were made in the new Scrum Guide that was released in November 2020.

This episode compiles all three of Sam’s Trainer Talks that focus on the three key changes that were made to the Scrum Guide around the product goal, the Sprint goal, and self-organizing teams. Sam shares his thoughts on why these changes are important to recognize; what these changes mean for organizations, Scrum Teams, and Product Owners; and the specific benefits that come with these changes.

Tune in to learn all about the three key changes that organizations using Scrum need to pay close attention to.

Key Takeaways

How has the Product Goal changed with the New Scrum Guide? Why is it important and what are the benefits?

What the Scrum Guide has to say about the Product Goal: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define ‘what’ will fulfill the Product Goal”
The Scrum Guide is now making the Product Goal an explicit part of Scrum (which is crucial in creating a unified vision for the team to work toward)
This change highlights the difference between a Product Goal and a Product Vision which is important because a product vision is lacking the characteristics of SMART goals (“specific, measurable, achievable, relevant, and time-bound” goals)
With the Product Goal in the Product Backlog, the rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal (this has specific benefits such as creating transparency, understanding what the value is that is expected to be created so that the team can validate if their efforts are creating the desired outcome, and in helping the team understand what should be in the Product Backlog vs. what should be out of it)
With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, it is possible to validate PBIs against the Product Goal
The Scrum Guide also says that “The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next” (which is hugely beneficial as it will help teams focus)
With a Product Goal and the expectation that the Product Backlog, by and large, contains items that emerge as a result of that Product Goal, it is possible to make much more meaningful Sprint Goals
The Product Goal helps the Product Owner move beyond being a mere order taker and, instead, create a stance where they are initiating requirements

How has the Sprint Goal changed with the New Scrum Guide? Why is it important and what are the benefits?

The New Scrum Guide underscores the commitment and purpose of a Sprint Goal
Jeff and Ken introduce a new topic for Sprint Planning in this update, which is: “Why is this Sprint valuable?” (In other words, “What do we hope to get out of it?”) — Asking this question helps craft the Sprint Goal
Establishing a Sprint Goal allows the team to create a well-rounded SMART (“specific, measurable, achievable, relevant, and time-bound”) goal
If you don’t have a Sprint Goal, the Sprint Backlog becomes just a list of Product Backlog Items to fill up a team’s capacity with no coherence to it
With a Sprint Goal, the team is able to create a coherent Sprint backlog that will help them meet their goals and objectives
Though there might be things in your Sprint Backlog that are not strongly correlated to the Sprint Goal, doing what is necessary to achieve the Sprint Goal needs to be the priority (If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a Sprint Goal themselves)
Once a Sprint Goal is established and it has helped the team select a coherent group of Product Backlog Items for their Sprint Backlog, the Sprint Goal then helps address the topic of: “How are we going to do it?”
Good Sprint planning includes creating a plan for working together and breaking things down into the tasks that the team needs to achieve
Without a Sprint Plan, there is a lack of transparency and the Scrum Team cannot see at their Daily Scrums whether or not they are making good progress towards the Sprint Goal
The Sprint Goal creates transparency and the ability for a Scrum Team to deliver reliably and predictably each and every Sprint (additionally, it helps establish a sustainable pace, which creates better morale and a more fulfilling work environment)

How has Self-Organizing changed to Self-Managing in the New Scrum Guide? Why is it important and what are the benefits?

Even though the change may seem merely semantic, it has a massive impact on how organizations will see Scrum in a new light and will be a shock to those organizations that have not allowed their teams to be self-organizing or self-managing at all
When organizations use Scrum but do not allow their teams to be self-managing this leads to a lack of engagement and a lack of ownership; it destroys morale and causes turnover
In Daniel H. Pink’s book, Drive, he discovered the three factors that truly motivate knowledge workers are autonomy, mastery, and purpose (and self-managing teams leverage all three of these things [and Scrum done well has all three built-in!])
Scrum gives team autonomy by allowing them to decide what to work on and in setting their own Sprint Goal
“Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that ‘This is my area and I don’t have to do anything else.’ We all expand our knowledge together and work together.” — Sam Falco
Self-managing teams create less overhead for managers as they don’t have to spend time directing people and telling them what to do
“Self-managing is serendipity in development” (when you hand someone a problem, get out of their way, and they will solve it in ways that you never could have imagined [and maybe even better than if you had solved it yourself!])
In complex product development, something new is always going to come up and there is an enormous amount of uncertainty — Scrum allows self-managing teams to adapt to this uncertainty as it arises and every Sprint offers an opportunity to change direction
You can work towards self-managing teams by empowering your Product Owners to make decisions and shepherd their products; feeding your teams with objectives, not tasks; setting the boundaries within which your teams can make their own decisions and steer their own course; encouraging the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes

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] Hello, and welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Dan Neumann and I really we want to appreciate you taking time to join me and listen to this episode, as well as hopefully other episodes. If you’re enjoying the Agile Coaches’ Corner podcast, I’d like to invite you to take a moment and either share the podcast with a friend of yours who you think might also get some benefit from it, or perhaps hop out and give us a review and let us know what you think and help other people find the podcast. So very much appreciate it. For our long-time listeners, most of our episodes are me joined by a guest and we have a fairly informal conversation about an agile topic and share some insights and some knowledge with you. This episode is going to be that, but a little bit different. A while back Sam Falco did a three part series on the Trainer Talk special episodes that we did, and he shared some insights on the new Scrum Guide that was released at the end of 2020. We’re going to share those episodes with you. And then I would like to share some thoughts. So what we’ve got is three changes that were made to the Scrum Guide around the Product Goal, the Sprint Goal, and around self-organizing teams. And we’re going to share Sam’s thoughts. And then I’ll be back to check in with you. Here’s the first Trainer Talk episode that Sam produced about the Product Goal and the new Scrum Guide.

Sam Falco: [01:58] The more I think about the new edition of the Scrum guide, the more excited I am about the changes. Scrum is still Scrum, of course, nothing changed about how Scrum works or the value it brings, but by stripping out prescriptive elements, Ken and Jeff have given us a Scrum guide that makes its purpose and value clearer. Organizations that truly embrace this iteration of Scrum are going to supercharge their product development efforts. Dan Neumann, and I talked about the changes to the Scrum guide in episode 106 of the Agile Coaches’ Corner podcast titled what’s new with Scrum that was released a few days after the Scrum guide came out. Now that we’ve had time to absorb the changes I wanted to revisit them. In this three-part series, I’ll examine the three changes that I think organizations using Scrum need to pay close attention to. And the one I’m going to talk about in this episode is the introduction of the product goal as the commitment associated with the product backlog. As I mentioned in episode 106, a criticism that I’ve seen levied at Scrum is that it doesn’t provide a unified vision for the team to work toward. Without that vision, the team lurches from short-term goal to short-term goal and developers struggle to understand what they’re building and why they’re building it. It’s true that Scrum didn’t tell you to create that goal, previously. Of course, nothing prevented a product owner from doing that either. And the best product owners I’ve worked with did. With the Scrum guide, making that product goal, an explicit part of Scrum, it’s going to make a big difference in the way people look at how they’re practicing Scrum. Here’s what the Scrum guide has to say about the product goal.

Sam Falco: [03:46] The product goal describes a future state of the product which can serve as a target for the Scrum team to plan against. The product goal is in the product backlog. The rest of the product backlog emerges to define what will fulfill the product goal end of the quote. So the product goal is the why of what we’re building and the rest of the product backlog that emerges from that why is the what. I like that statement that it describes a future state of the product to plan against. I think this shows us the difference between a product vision and a product goal. Now you’ve probably heard of SMART goals, SMART being an acronym for specific, measurable, achievable, relevant, and time-bound a product vision may lack some of those characteristics. And that’s why it’s different from a goal. Let’s imagine that we are running a vacation resort and our vision is to become the destination of choice for travelers to our region. That is pretty broad rather than being specific. It’s not measurable, or at least it’s not easily measurable. We don’t know if it’s achievable until we try it. While it is relevant to our business. There’s no time statement in there. So it’s not a SMART goal. It’s inspiring, but by itself, that vision is not enough to give a Scrum team what they need to know in order to move forward. A product goal is a concrete step toward realizing that broader vision. And it has more of the smart goal characteristics. It’s at the very least specific and measurable. Like the vision, we might not know if it’s achievable until we try it is relevant. And while it might be timeboxed, time-bound it isn’t always. Sometimes, as you, you know, we don’t set a release date. To declare that the release boundary is the features that the product must have and the release is flexible on the other hand and we often do have a time constraint for our imaginary resort. We might want to make a new product available around the time. People start planning their spring vacations for our tourist season. So our imaginary resorts vision is to be the destination of choice for travelers to the region. What would a product goal look like? It might be something like create a rainforest hike package that will appeal to young couples. That is specific and measurable. We know what it is we’re trying to achieve. We know who we’re targeting, and we will know when we’ve achieved it. It’s probably achievable. Certainly relevant. The only thing we’ve left out is time boxing. Now look back again at that definition of product goal. The product goal is in the product backlog. The rest of the product backlog emerges to define what will fulfill the product goal. That specificity of the product goal is in the product backlog has some pretty strong benefits. First of all, it creates transparency. We know why we’re building the product. We know whether it makes sense to keep building this product as we go. We can ask is the why still a concern? If not, we can end the product development effort or imaginary resort can look at whether young newlyweds are responding to our offerings or whether they even traveled to our region at a rate high enough to justify the cost of developing the new product. Another benefit is that the product goal helps us understand what value we expect to create. So we can validate if our efforts are creating the desired outcome. As our resort creates initial increments of the product, it can monitor how often young couples purchase the rainforest hike package, how much they’re willing to pay, and what they say would make it better. The product goal also helps us understand what should be in the product backlog and what should be out.

Sam Falco: [07:58] Our resorts goal is targeting young newlyweds. So the team can weed out child-friendly options for the product. I’ve seen a lot of product backlogs that are huge lists of unrelated requests. They’re like our requirements, junk drawer, all of this stuff we just shove it in there. And we don’t think about whether we really need it. Well, the product goal being in the product backlog and the rest of the product backlog emerging around it, we can always validate our PBIs against the product goal. Should this be in here? Would this contribute to the product goal? When someone wants to ask the team to do something, it gives Scrum teams a way to avoid non-value added work, or at least work that doesn’t contribute to the product goal. So that’s another benefit of the product goal. And remember the product owner can delegate product backlog management activities to others with a product goal that provides guidance to those delegates as to what they should doing activities like product backlog, refinement become easier.

Sam Falco: [09:01] The Scrum guide also says that the product goal is the long-term objective for the Scrum team and they must fulfill or abandon one objective before taking on the next. And that’s a direct quote. And I love that statement because it is going to help teams and organizations with the Scrum value of focus. A lot of teams face the problem of being asked to do too much. They’re asked to work on multiple products or work on multiple goals within one product. Sometimes there’s not a specific product at all that they have in mind. They’re just working through that requirements, junk drawer. It damages morale, damages performance. It damages the ability to deliver value for the organization with a product goal and the expectation that the product backlog by and large contains items that emerge as a result of that product goal. We can make much more meaningful sprint goals.

Sam Falco: [09:55] Remember that initial criticism that I talked about, the team’s lurched from sprint to sprint without any overall vision, this really helps each sprint become a step toward the product goal, which is a step towards a product vision. I’ll talk about the sprint goal and sprint planning in the next episode. Another benefit of having a product goal is that when the product owner isn’t available during a sprint developers can make decisions about product backlog items they’re working on to align what they’re building with the product goal, because sometimes the product owner isn’t available, people take vacations for one thing, but beyond vacations, a product owner isn’t going to be with the developers a hundred percent of the time, not if they’re going to be doing the rest of the job well, which is to be talking to stakeholders, understanding what they need, talking to customers, understanding what they need, doing market research. What is the competition doing? All of these activities take away from the product owner’s availability to developers. With a solid product goal, developers can move forward in the absence of the product owner, and then they can coordinate with their product owner when the product owner becomes available. Again, the product goal helps the product owner move beyond being just a mere order taker. A lot of times new product owners are just receivers of requirements are told you, just write down what stakeholders tell you they want. Your contribution is ordering that list, but we’re going to get all of the things stakeholders ask for. Those product owners are just proxies or scribes. They’re really not making decisions about what should be in or out of the product. What’s better is when product owners can move away from that receiver of requirements stance, and instead create a stance where they are initiating requirements, where they are a true representative of what’s good for the business and what’s good for the product. Here’s how this product will help the business. When someone asks for a new feature, the product goal helps a product owner take a stand that aligns with the product goal or it doesn’t. And here’s why. This helps product owners move toward an entrepreneurial stance, which helps in creating good, valuable products. So if you want to get more value out of using Scrum, make sure you have a strong product goal and power product owners and the Scrum teams of which they are a critical part to focus on realizing that goal.

Dan Neumann: [12:35] I hope you enjoyed those thoughts from Sam, as much as I did. I have to be honest. The first thing that Sam mentioned in there about the prescriptive elements of Scrum being removed, I think is a two-edged sword. There are elements of the prescription in the old Scrum guide that I thought were particularly valuable and maybe that’s a topic for another day, but I think of the elements around what makes up a good sprint review. I thought that was a nice, helpful checklist. Um, but here we are with the new Scrum guide and people smarter than me perhaps decided that those elements that were prescriptive were an impediment to Scrum being used effectively. And so they’re gone. I do appreciate the thoughts around a product goal that Sam was talking about. It’s more specific than just the product vision, and it talks about a very specific future state. And so for me, then that really helps development teams, Scrum teams figure out what they need to do now, meaning now towards that current product goal in what types of things can be deferred until later? So if your product goal maybe has a limited audience, you don’t necessarily have to have the most robust, the most scalable, the most performant, all those ilities that sometimes can drag development teams into imagining problems that might happen someday and then over-engineering or potentially over-engineering their solution. And never delivering things that helps refocus them on here is our goal for now our goal is something viable, lovable that can be shipped to an audience of a particular size. And then some of the fail safes and performance issues don’t have to be built in for now. So I really liked the boundary that that creates and the safety it creates for deferring more complicated things until later, allowing the Scrum teams capture value earlier and then focusing on a more sophisticated goal later. And so I really love that part of what Sam was sharing. Let’s hear what Sam has to say now about the sprint goal in the second installation.

Sam Falco: [15:23] The sprint goal, isn’t new to Scrum. It has been part of the Scrum guide for at least as long as I’ve been practicing Scrum. It’s what the teams commit to at sprint planning. Scrum teams are not supposed to commit to a scope of work, but a goal which guides us in selecting and adapting the scope throughout the sprint, the new Scrum guide underscores that commitment and its purpose. I think it will help teams understand why they’re doing sprint planning in the first place. But sprint planning is not merely an exercise in selecting the top X number of items off the product backlog and doing that until we’ve made sure that everyone is fully utilized. Imagine the air quotes I just made there. That’s not the purpose of sprint planning. And that view is one of the reasons that sprint planning becomes such a tedious chore for so many teams. Earlier Scrum guides talked about the need to craft a sprint goal. As part of determining what product backlog items we will select. In the new Scrum guide, Jeff and Ken, make it clear how important this activity is by introducing a new topic for sprint planning. Why is this sprint valuable? In other words, what do we hope to get out of it? What’s our objective here? What are we trying to achieve? To be perfectly blunt we’re asking what value are we going to provide in return for the stakeholder funding we’re spending?

Sam Falco: [16:57] So we start by asking the question, why is this sprint valuable and answering that question helps us craft our sprint goal. I talked in the previous episode about the idea of SMART goals, an acronym for specific measurable, achievable, relevant, and time-bound. I said that a product goal doesn’t need to fulfill all of those criteria, but with the sprint goal, I think we must. Like the product goal. the sprint goal is specific and measurable. We’ll know whether we have achieved it, but here we have a much better idea of being able to be achievable. We want to achieve our sprint goal every sprint. So we do need to select an achievable goal. And of course the sprint goal should be relevant to the product goal. And it’s time bound by the length of the sprint itself. If you don’t have a sprint goal. As I said earlier, the sprint backlog becomes just a list of product backlog items to fill up our capacity. There’s no coherence to it. And often that leads to other bad patterns like everyone having their own PBIs that they’re working on and the team doesn’t collaborate. Everybody works in their own individual silos. I’ll hear people say things like we need to stay in our lane. And then of course the daily Scrum becomes a dry recitation of what I did yesterday, what I’m going to do today. It’s a status report and it’s not a collaboration meeting.

Sam Falco: [18:29] These dysfunctions can stem from not having a strong sprint goal. If we have a sprint goal, then we can create that coherent sprint backlog that will help us meet it. Now, ideally the product backlog is ordered so that it’s easy to select items from the top and create a coherent sprint backlog. But there is some finesse and negotiation in that activity too. If the product owner comes to the team and says, listen, here’s what I’m thinking for the sprint. We need to start generating revenue for our web application. We need to build a way to accept payments. Just because something is at the top of the list, doesn’t mean we have to select it if it won’t help us achieve that sprint goal. And there’s also some negotiation between the product owner and the developers, the developers might say, here’s how much we think we can do. We knew you wanted all the credit cards and PayPal and Apple pay and so on, but we don’t have time to do all of that. And so we further refine that sprint goal to make it really clear what it is we’re trying to accomplish. For example, we need to accept at least three methods of payment. Sometimes teams ask, what about other stuff we have to do that isn’t directly tied to the product development. We’re talking about things like retiring technical debt building or maintaining infrastructure that needs to be taken care of. Maybe it doesn’t contribute directly to the sprint goal, but it needs to get done. And that’s fine. There might be things in your product backlog that aren’t strongly correlated to the product goal, but doing what is necessary to achieve a sprint goal needs to be the priority. If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a sprint goal themselves.

Sam Falco: [20:13] Once we have a sprint goal and it has helped us select a coherent group of product backlog items for our sprint backlog, answering the second question in sprint planning, what will we do? The sprint goal also helps us in that third topic, namely, how are we going to do it? Teams that work in silos once they’ve selected the individual items that they’re each going to work on, they go their separate ways. Everyone has their work to do, and they really don’t coordinate or collaborate with each other. There’s often no point in sitting there figuring out a plan. Each person is going to go off and do their own thing. When we’re truly working toward a common sprint goal. When we are working toward a common plan that derives from that sprint goal, it’d be hooves us to sit down together and figure out what our plan is. But even teams that aren’t working in silos will often skip the third part of sprint planning so that, and I hear this phrase a lot so that we can get started working. Well, figuring out a plan is part of the work. Good sprint planning includes creating a plan for working together, breaking things down into the tasks we need to achieve. We don’t need to forecast every single thing we might need to do just enough to get started so that we can show progress every day during the daily Scrum. And so that we can uncover what else we need to do as we go on. Without that plan, we have a lack of transparency. For starters, the Scrum team can’t see every day at daily Scrum, whether it is making good progress toward the sprint goal. They don’t know if they need to adjust their scope. They don’t know if they need to renegotiate which product backlog items belong in the sprint or what the scope of each PBI is.

Sam Falco: [21:57] But lack of transparency also means that people outside the team can’t tell if the team is being effective. And that probably means they’ll pester the team more, which has implications for self-management, which I’m going to talk about in our next episode. So having that plan means good transparency for everyone involved, and it gives us a much better chance of achieving a positive outcome. So a sprint goal flows from our product goal. The sprint goal should be a step toward achieving the product goal. The sprint goal creates transparency and creates the ability for a Scrum team to deliver reliably predictably each and every sprint, and to do it without having to overwork themselves. It helps us establish a sustainable pace, which gives us better morale and a more fulfilling work environment.

Dan Neumann: [22:59] I can’t tell you how many times I’ve had the sense that teams are just pulling items off the back of the product backlog. And while that isn’t the worst thing I could ever imagine happening, it can turn this empowering framework of Scrum into what a lot of times I’ve heard to referred to as the hamster wheel of Scrum. And I don’t know if anybody like me had a pet hamster when they were a kid, but hamsters get in that little wheel and they just run and run and run and run and they never get anywhere. And I’ve heard that complaint about the Scrum framework being, Hey, we do a sprint and it, and immediately the next one starts and that one ends and the next one starts and it becomes tiring. It becomes daunting. We’re just sprinting and sprinting and sprinting. I think the sprint goal and having really valuable sprint goals can enable teams to really see that we have done something that is really cool. We have done something that is valuable to the organization. It changes somebody’s life and it’s, that should be super empowering to teams. And so I really like thinking about what it would look like to have a real sprint goal. That’s very empowering and to get people moved off of we’re working on item number one, three, seven, five, two, and that’s not inspiring to anybody. So let’s talk about sprint goals and really making it something that matters and is connected to that product goal. And now let’s hear Sam’s thoughts about the change in the Scrum guide from self-organizing teams, which was the old wording to self-managing teams, which is the current wording.

Sam Falco: [25:05] At first, when I saw that change, I didn’t think much of it. I thought it was sort of a search and replace type of thing. To me, Self-organizing and self-managing seemed like the same thing. I’d often thought that self-organizing was chosen to keep managers from freaking out. What do you mean the team is self managing, then what am I going to do? That might be a cynical take on my part, but even if the change is merely semantic, the significance is that organizations need to look at Scrum in a new light or we’ll look at Scrum in a new light. That phrase self managing is going to be a big shock to organizations that haven’t allowed teams to be either self-organizing or self managing. A lot of organizations sort of gloss over this concept teams aren’t really selecting what they’re going to work on, except in the very shallowest sense of they get to take the items that are at the top of the product backlog. Product owners aren’t really making decisions about what’s in the product backlog, except in the very shallow sense of deciding what gets worked on first. They’re still just taking orders from stakeholders, teams don’t craft their own goals. Goals are handed to them. Teams might be allowed to decide how to do what they’re told to do. Maybe we let them decide who sits, where, what their core hours are and that sort of thing. But there is a lot more to self managing than just allowing people to decide where they’ll sit and what they’re going to work on specifically today. What happens when we’re using Scrum, but we’re not allowing teams to be self managing? One frequent complaint about Scrum is that there are too many meetings. And I talked about this in a trainer talk episode last year, this complaint is common. When an organization imposes Scrum from the top down, here, you’re going to do this. They don’t change anything about the way they work. So all those other meetings that are on your calendar don’t go away. And by the way, here’s four more you need to do. Often organizations that dictate Scrum as a veneer, a top, their existing processes don’t see any better delivery than they were seeing before. Sometimes things get worse because now they have the added overhead of the events of Scrum and all of the things that go with that. And this leads to a lack of engagement, a lack of ownership. It destroys morale. It causes turnover. You not only can’t retain talent, but you can’t attract talent because word gets out and people hear that, Yeah, you don’t want to work there. That’s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay. Once they’re there. In his book, drive Daniel Pink examined what really motivates people in complex knowledge work domains, which includes product development. What he found was that what motivated people wasn’t being rewarded with money. The three factors that motivated knowledge workers are autonomy, mastery, and purpose. Autonomy is the ability to decide what am I going to work on? And how am I going to work on it? Mastery is the ability to continually improve your skills and purpose means doing something that’s meaningful, self managing teams leverage all three of those factors. And Scrum done well has this stuff built in a Scrum team, decides what it’s going to work on a product goal is more than just a statement handed down to the team. The product owner creates it and also collaborates with the Scrum team on it and on what the Scrum team needs to do to realize it. The entire, our team gets involved in that emergent product backlog map management. That’s autonomy. Another way that Scrum gives teams autonomy is that they set their own sprint goal.

Sam Falco: [29:13] No one says, this is what you’re going to be doing this sprint. Instead, the Scrum team talks about what would be valuable to do based on the feedback they’ve gotten so far and creates its own goal and a plan. And then of course, every day in the daily, Scrum, the developers meet and figure out how they’re going to move a little closer to the sprint goal that day. They’re responsible for coming up with that plan. Nobody else. Scrum encourages mastery. The Scrum team is accountable as a whole for delivery. So there’s no idea that, well, this is my area and I don’t have to do anything else. We all expand our knowledge together, right? Work together. And then of course, purpose is built into Scrum. We have that important product goal that tells us what we’re building and why. And it should be exciting for us.

Sam Falco: [30:00] A benefit of self-managing teams is that it takes away overhead for managers rather than there’s nothing for managers to do, now, they get a, a different focus for their activities. They don’t have to spend time directing people, telling them what to do, keeping an eye on their activities. The manager who introduced Scrum to me and the team I was on and who asked me to be the Scrum Master was so relieved when he could stop chasing us down for status reports when he didn’t have to be checking, being in on us and making sure we were doing things or telling us what we need I needed to do. He could just say, here’s what we need to accomplish. And we figured out the rest on our own, his management activities became about helping us grow in our careers. He would ask, what do you need to know? What do you need to learn? How can I help with that? That was both technical skills and for our ability to navigate within our organization. And that was a much more fulfilling experience for him. And frankly, for us, another benefit of self managing teams is you get this sort of serendipity in development. You hand people a problem to solve and then get the heck out of their way. We’ll solve it in ways that you never imagined, maybe solve it better than you would have. If you told them what to do, do using Scrum to manage a project, instead of using it to drive product development, misses out on creating valuable products and valuable outcomes, especially in the face of uncertainty, we can pretend that we can predict the future, but we can’t. And in complex product development, something new is always going to come up. There’s an enormous amount of uncertainty. Scrum allows us to adapt to that uncertainty as it arises in every sprint, we have a chance to change direction and self managing teams can do that faster than if they’re waiting for someone to tell them to do it. How do you get there? First say abandon the illusion of control. I had a manager once who really struggled with that. He had a deliverable that he’d been told, had to be completed by a certain date. He’d been told the scope and immovable target date and a fixed budget. And he was obsessed with making sure that everyone knew what he wanted them to do. And I said, let’s try to leverage Scrum for this. And he said, as long as everyone does what I say we’ll succeed. As a result, people didn’t take initiative when they needed to, for fear of getting slapped down, that project ran late and there was hell to pay as a result.

Sam Falco: [32:48] This is a terrible pattern and it repeats over and over again. We need to let go of the idea that we can control everything that we can predict everything upfront feeds your team with objectives, not tasks. Set the boundaries within which they can make their own decisions and steer their own course. Empower your product owners to make decisions and shepherd their products. Certainly they need to take into consideration what stakeholders need and want, but product owners need the latitude to make decisions about what is most valuable to do and give them the resources they need to make those decisions. Things like access to market data, access to customers. And so on. Encourage the Scrum team as a whole, to be accountable toward each other and toward achieving positive outcomes, encourage teams to do small experiments until the goal is achieved, or the goal becomes obsolete and then have them create a new goal. Give them a new objective. We can manage risk with small sprints where we constantly inspect and adapt not only the product and our progress toward the product goal, but also the team’s effectiveness, the processes they work with and the objectives they’re being asked to work on. As one of the principles behind the agile manifestos States build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. And they will. That’s the promise that self managing teams in Scrum offers. I hope you’ve benefited from this exploration of the changes in the new Scrum guide. I’d love to hear your feedback. If you have a question or a comment, please email us at podcast@agilethought.com.

Dan Neumann: [34:38] As Sam said, we would love to hear your feedback. And in this last installment that Sam was sharing, it made me think of how many times I hear the perception that Scrum is just a methodology. It’s like another methodology, but this one’s the Scrum methodology, the Scrum masters, maybe like the project manager. If you really look at self managing teams and start to think, Oh, it’s just, you know, the waterfall framework, but I’m sorry if the waterfall waterfall framework. Yeah, when’s the last time you worked on a waterfall project that felt like a framework. And so it’s not like a rigorous waterfall process. Scrum is a framework. We want self managing teams. We want to trust the teams to figure out the best to deliver on the product goal, the sprint goal. We want them to organize around the work. We are them empowered to say, you know what? These particular activities are wasteful. We’re not doing them. We are going to invest in how we, as a team can get better. It’s really a fairly radical thing to think about self managing teams. So let that one just sink in for a little while. Self managing teams is a pretty radical part of the Scrum framework and it’s not just a different methodology. And we kind of iterate through a business requirements document in two week chunks and do blah, blah, blah. It’s a big shift when done well, when you truly fulfill the Scrum values and you use the Scrum framework effectively to really impact your business, it’s a big deal. And so I want you to think about that. Like Sam said, email us at podcast at agile thought ideas. If you loved what you heard here, emails, podcast@agilethought.com. If you think we’re idiots and are just totally wrong. Email us at podcast@agilethought.com, we will, we’ll take that email and we’d love the feedback. Thank you. And look forward to engaging with you. Next.

Outro: [37:04] 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.

Speakers

Dan Neumann

Principal Enterprise Coach

Dan Neuman is the Director of the US Transformation and Coaching practice in the Agility guild. He coaches organizations to transform the way they work to achieve their desired business outcomes.

With more than 25 years of experience, Dan Neumann is an experienced Agile Coach with a deep knowledge of Agility at the team and organizational levels. He focuses on achieving business outcomes by shifting both mindset and practices, resulting in a disciplined, yet practical approach to solving problems.

10 Things a Java Developer Should Learn These Days

We are halfway into the year and, looking back at what the last 2 years of the COVID-19 pandemic left us, we can say that the advancements on technology and all the different languages, frameworks and development tools have not disappointed us and even in many cases have overtaken us. It doesn’t seem that long since Java 8 was released more than 8 years ago and, although it is true that today the latest version is Java 18, we must remember that there are still many companies stuck with Java 8 and even a few with Java 1.4 a 1.6 and a few other legacy frameworks.Because of this great advance in programming languages and frameworks in recent years, many programmers could feel overwhelmed due to the large number of updates that we are exposed to in our industry. However, we have begun to see very marked patterns in different industries, and we believe it is important to mention what are the 10 things that every Java programmer should learn.

6 min read

August 25, 2022

Succeeding at Cost Takeout – Improving Cost Management Strategy

The cost takeout is a strategic initiative that can help your company become more efficient. The goal of the initiative is to determine ways to reduce expenses without sacrificing quality, speed or customer satisfaction. A successful cost takeout requires an accurate understanding of where costs arise in your business process and how those costs can be reduced through new technologies. In this guide, we’ll look at some of the most common drivers of costs in IT departments and explain how you can identify them within your own organization’s processes.Cost drivers are the factors that cause your costs to increase. They’re different for every business, but you can identify them by asking yourself: “What makes my costs go up?”

10 min read

February 7, 2023

Podcast Ep. 128: The New Scrum Guide: The Three Changes YOU Need to Know About

]

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]

Hello, and welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Dan Neumann and I really we want to appreciate you taking time to join me and listen to this episode, as well as hopefully other episodes. If you’re enjoying the Agile Coaches’ Corner podcast, I’d like to invite you to take a moment and either share the podcast with a friend of yours who you think might also get some benefit from it, or perhaps hop out and give us a review and let us know what you think and help other people find the podcast. So very much appreciate it. For our long-time listeners, most of our episodes are me joined by a guest and we have a fairly informal conversation about an agile topic and share some insights and some knowledge with you. This episode is going to be that, but a little bit different. A while back Sam Falco did a three part series on the Trainer Talk special episodes that we did, and he shared some insights on the new Scrum Guide that was released at the end of 2020. We’re going to share those episodes with you. And then I would like to share some thoughts. So what we’ve got is three changes that were made to the Scrum Guide around the Product Goal, the Sprint Goal, and around self-organizing teams. And we’re going to share Sam’s thoughts. And then I’ll be back to check in with you. Here’s the first Trainer Talk episode that Sam produced about the Product Goal and the new Scrum Guide.

]

Sam Falco: [01:58]

The more I think about the new edition of the Scrum guide, the more excited I am about the changes. Scrum is still Scrum, of course, nothing changed about how Scrum works or the value it brings, but by stripping out prescriptive elements, Ken and Jeff have given us a Scrum guide that makes its purpose and value clearer. Organizations that truly embrace this iteration of Scrum are going to supercharge their product development efforts. Dan Neumann, and I talked about the changes to the Scrum guide in episode 106 of the Agile Coaches’ Corner podcast titled what’s new with Scrum that was released a few days after the Scrum guide came out. Now that we’ve had time to absorb the changes I wanted to revisit them. In this three-part series, I’ll examine the three changes that I think organizations using Scrum need to pay close attention to. And the one I’m going to talk about in this episode is the introduction of the product goal as the commitment associated with the product backlog. As I mentioned in episode 106, a criticism that I’ve seen levied at Scrum is that it doesn’t provide a unified vision for the team to work toward. Without that vision, the team lurches from short-term goal to short-term goal and developers struggle to understand what they’re building and why they’re building it. It’s true that Scrum didn’t tell you to create that goal, previously. Of course, nothing prevented a product owner from doing that either. And the best product owners I’ve worked with did. With the Scrum guide, making that product goal, an explicit part of Scrum, it’s going to make a big difference in the way people look at how they’re practicing Scrum. Here’s what the Scrum guide has to say about the product goal.

]

Sam Falco: [03:46]

The product goal describes a future state of the product which can serve as a target for the Scrum team to plan against. The product goal is in the product backlog. The rest of the product backlog emerges to define what will fulfill the product goal end of the quote. So the product goal is the why of what we’re building and the rest of the product backlog that emerges from that why is the what. I like that statement that it describes a future state of the product to plan against. I think this shows us the difference between a product vision and a product goal. Now you’ve probably heard of SMART goals, SMART being an acronym for specific, measurable, achievable, relevant, and time-bound a product vision may lack some of those characteristics. And that’s why it’s different from a goal. Let’s imagine that we are running a vacation resort and our vision is to become the destination of choice for travelers to our region. That is pretty broad rather than being specific. It’s not measurable, or at least it’s not easily measurable. We don’t know if it’s achievable until we try it. While it is relevant to our business. There’s no time statement in there. So it’s not a SMART goal. It’s inspiring, but by itself, that vision is not enough to give a Scrum team what they need to know in order to move forward. A product goal is a concrete step toward realizing that broader vision. And it has more of the smart goal characteristics. It’s at the very least specific and measurable. Like the vision, we might not know if it’s achievable until we try it is relevant. And while it might be timeboxed, time-bound it isn’t always. Sometimes, as you, you know, we don’t set a release date. To declare that the release boundary is the features that the product must have and the release is flexible on the other hand and we often do have a time constraint for our imaginary resort. We might want to make a new product available around the time. People start planning their spring vacations for our tourist season. So our imaginary resorts vision is to be the destination of choice for travelers to the region. What would a product goal look like? It might be something like create a rainforest hike package that will appeal to young couples. That is specific and measurable. We know what it is we’re trying to achieve. We know who we’re targeting, and we will know when we’ve achieved it. It’s probably achievable. Certainly relevant. The only thing we’ve left out is time boxing. Now look back again at that definition of product goal. The product goal is in the product backlog. The rest of the product backlog emerges to define what will fulfill the product goal. That specificity of the product goal is in the product backlog has some pretty strong benefits. First of all, it creates transparency. We know why we’re building the product. We know whether it makes sense to keep building this product as we go. We can ask is the why still a concern? If not, we can end the product development effort or imaginary resort can look at whether young newlyweds are responding to our offerings or whether they even traveled to our region at a rate high enough to justify the cost of developing the new product. Another benefit is that the product goal helps us understand what value we expect to create. So we can validate if our efforts are creating the desired outcome. As our resort creates initial increments of the product, it can monitor how often young couples purchase the rainforest hike package, how much they’re willing to pay, and what they say would make it better. The product goal also helps us understand what should be in the product backlog and what should be out.

]

Sam Falco: [07:58]

Our resorts goal is targeting young newlyweds. So the team can weed out child-friendly options for the product. I’ve seen a lot of product backlogs that are huge lists of unrelated requests. They’re like our requirements, junk drawer, all of this stuff we just shove it in there. And we don’t think about whether we really need it. Well, the product goal being in the product backlog and the rest of the product backlog emerging around it, we can always validate our PBIs against the product goal. Should this be in here? Would this contribute to the product goal? When someone wants to ask the team to do something, it gives Scrum teams a way to avoid non-value added work, or at least work that doesn’t contribute to the product goal. So that’s another benefit of the product goal. And remember the product owner can delegate product backlog management activities to others with a product goal that provides guidance to those delegates as to what they should doing activities like product backlog, refinement become easier.

]

Sam Falco: [09:01]

The Scrum guide also says that the product goal is the long-term objective for the Scrum team and they must fulfill or abandon one objective before taking on the next. And that’s a direct quote. And I love that statement because it is going to help teams and organizations with the Scrum value of focus. A lot of teams face the problem of being asked to do too much. They’re asked to work on multiple products or work on multiple goals within one product. Sometimes there’s not a specific product at all that they have in mind. They’re just working through that requirements, junk drawer. It damages morale, damages performance. It damages the ability to deliver value for the organization with a product goal and the expectation that the product backlog by and large contains items that emerge as a result of that product goal. We can make much more meaningful sprint goals.

]

Sam Falco: [09:55]

Remember that initial criticism that I talked about, the team’s lurched from sprint to sprint without any overall vision, this really helps each sprint become a step toward the product goal, which is a step towards a product vision. I’ll talk about the sprint goal and sprint planning in the next episode. Another benefit of having a product goal is that when the product owner isn’t available during a sprint developers can make decisions about product backlog items they’re working on to align what they’re building with the product goal, because sometimes the product owner isn’t available, people take vacations for one thing, but beyond vacations, a product owner isn’t going to be with the developers a hundred percent of the time, not if they’re going to be doing the rest of the job well, which is to be talking to stakeholders, understanding what they need, talking to customers, understanding what they need, doing market research. What is the competition doing? All of these activities take away from the product owner’s availability to developers. With a solid product goal, developers can move forward in the absence of the product owner, and then they can coordinate with their product owner when the product owner becomes available. Again, the product goal helps the product owner move beyond being just a mere order taker. A lot of times new product owners are just receivers of requirements are told you, just write down what stakeholders tell you they want. Your contribution is ordering that list, but we’re going to get all of the things stakeholders ask for. Those product owners are just proxies or scribes. They’re really not making decisions about what should be in or out of the product. What’s better is when product owners can move away from that receiver of requirements stance, and instead create a stance where they are initiating requirements, where they are a true representative of what’s good for the business and what’s good for the product. Here’s how this product will help the business. When someone asks for a new feature, the product goal helps a product owner take a stand that aligns with the product goal or it doesn’t. And here’s why. This helps product owners move toward an entrepreneurial stance, which helps in creating good, valuable products. So if you want to get more value out of using Scrum, make sure you have a strong product goal and power product owners and the Scrum teams of which they are a critical part to focus on realizing that goal.

]

Dan Neumann: [12:35]

I hope you enjoyed those thoughts from Sam, as much as I did. I have to be honest. The first thing that Sam mentioned in there about the prescriptive elements of Scrum being removed, I think is a two-edged sword. There are elements of the prescription in the old Scrum guide that I thought were particularly valuable and maybe that’s a topic for another day, but I think of the elements around what makes up a good sprint review. I thought that was a nice, helpful checklist. Um, but here we are with the new Scrum guide and people smarter than me perhaps decided that those elements that were prescriptive were an impediment to Scrum being used effectively. And so they’re gone. I do appreciate the thoughts around a product goal that Sam was talking about. It’s more specific than just the product vision, and it talks about a very specific future state. And so for me, then that really helps development teams, Scrum teams figure out what they need to do now, meaning now towards that current product goal in what types of things can be deferred until later? So if your product goal maybe has a limited audience, you don’t necessarily have to have the most robust, the most scalable, the most performant, all those ilities that sometimes can drag development teams into imagining problems that might happen someday and then over-engineering or potentially over-engineering their solution. And never delivering things that helps refocus them on here is our goal for now our goal is something viable, lovable that can be shipped to an audience of a particular size. And then some of the fail safes and performance issues don’t have to be built in for now. So I really liked the boundary that that creates and the safety it creates for deferring more complicated things until later, allowing the Scrum teams capture value earlier and then focusing on a more sophisticated goal later. And so I really love that part of what Sam was sharing. Let’s hear what Sam has to say now about the sprint goal in the second installation.

]

Sam Falco: [15:23]

The sprint goal, isn’t new to Scrum. It has been part of the Scrum guide for at least as long as I’ve been practicing Scrum. It’s what the teams commit to at sprint planning. Scrum teams are not supposed to commit to a scope of work, but a goal which guides us in selecting and adapting the scope throughout the sprint, the new Scrum guide underscores that commitment and its purpose. I think it will help teams understand why they’re doing sprint planning in the first place. But sprint planning is not merely an exercise in selecting the top X number of items off the product backlog and doing that until we’ve made sure that everyone is fully utilized. Imagine the air quotes I just made there. That’s not the purpose of sprint planning. And that view is one of the reasons that sprint planning becomes such a tedious chore for so many teams. Earlier Scrum guides talked about the need to craft a sprint goal. As part of determining what product backlog items we will select. In the new Scrum guide, Jeff and Ken, make it clear how important this activity is by introducing a new topic for sprint planning. Why is this sprint valuable? In other words, what do we hope to get out of it? What’s our objective here? What are we trying to achieve? To be perfectly blunt we’re asking what value are we going to provide in return for the stakeholder funding we’re spending?

]

Sam Falco: [16:57]

So we start by asking the question, why is this sprint valuable and answering that question helps us craft our sprint goal. I talked in the previous episode about the idea of SMART goals, an acronym for specific measurable, achievable, relevant, and time-bound. I said that a product goal doesn’t need to fulfill all of those criteria, but with the sprint goal, I think we must. Like the product goal. the sprint goal is specific and measurable. We’ll know whether we have achieved it, but here we have a much better idea of being able to be achievable. We want to achieve our sprint goal every sprint. So we do need to select an achievable goal. And of course the sprint goal should be relevant to the product goal. And it’s time bound by the length of the sprint itself. If you don’t have a sprint goal. As I said earlier, the sprint backlog becomes just a list of product backlog items to fill up our capacity. There’s no coherence to it. And often that leads to other bad patterns like everyone having their own PBIs that they’re working on and the team doesn’t collaborate. Everybody works in their own individual silos. I’ll hear people say things like we need to stay in our lane. And then of course the daily Scrum becomes a dry recitation of what I did yesterday, what I’m going to do today. It’s a status report and it’s not a collaboration meeting.

]

Sam Falco: [18:29]

These dysfunctions can stem from not having a strong sprint goal. If we have a sprint goal, then we can create that coherent sprint backlog that will help us meet it. Now, ideally the product backlog is ordered so that it’s easy to select items from the top and create a coherent sprint backlog. But there is some finesse and negotiation in that activity too. If the product owner comes to the team and says, listen, here’s what I’m thinking for the sprint. We need to start generating revenue for our web application. We need to build a way to accept payments. Just because something is at the top of the list, doesn’t mean we have to select it if it won’t help us achieve that sprint goal. And there’s also some negotiation between the product owner and the developers, the developers might say, here’s how much we think we can do. We knew you wanted all the credit cards and PayPal and Apple pay and so on, but we don’t have time to do all of that. And so we further refine that sprint goal to make it really clear what it is we’re trying to accomplish. For example, we need to accept at least three methods of payment. Sometimes teams ask, what about other stuff we have to do that isn’t directly tied to the product development. We’re talking about things like retiring technical debt building or maintaining infrastructure that needs to be taken care of. Maybe it doesn’t contribute directly to the sprint goal, but it needs to get done. And that’s fine. There might be things in your product backlog that aren’t strongly correlated to the product goal, but doing what is necessary to achieve a sprint goal needs to be the priority. If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a sprint goal themselves.

]

Sam Falco: [20:13]

Once we have a sprint goal and it has helped us select a coherent group of product backlog items for our sprint backlog, answering the second question in sprint planning, what will we do? The sprint goal also helps us in that third topic, namely, how are we going to do it? Teams that work in silos once they’ve selected the individual items that they’re each going to work on, they go their separate ways. Everyone has their work to do, and they really don’t coordinate or collaborate with each other. There’s often no point in sitting there figuring out a plan. Each person is going to go off and do their own thing. When we’re truly working toward a common sprint goal. When we are working toward a common plan that derives from that sprint goal, it’d be hooves us to sit down together and figure out what our plan is. But even teams that aren’t working in silos will often skip the third part of sprint planning so that, and I hear this phrase a lot so that we can get started working. Well, figuring out a plan is part of the work. Good sprint planning includes creating a plan for working together, breaking things down into the tasks we need to achieve. We don’t need to forecast every single thing we might need to do just enough to get started so that we can show progress every day during the daily Scrum. And so that we can uncover what else we need to do as we go on. Without that plan, we have a lack of transparency. For starters, the Scrum team can’t see every day at daily Scrum, whether it is making good progress toward the sprint goal. They don’t know if they need to adjust their scope. They don’t know if they need to renegotiate which product backlog items belong in the sprint or what the scope of each PBI is.

]

Sam Falco: [21:57]

But lack of transparency also means that people outside the team can’t tell if the team is being effective. And that probably means they’ll pester the team more, which has implications for self-management, which I’m going to talk about in our next episode. So having that plan means good transparency for everyone involved, and it gives us a much better chance of achieving a positive outcome. So a sprint goal flows from our product goal. The sprint goal should be a step toward achieving the product goal. The sprint goal creates transparency and creates the ability for a Scrum team to deliver reliably predictably each and every sprint, and to do it without having to overwork themselves. It helps us establish a sustainable pace, which gives us better morale and a more fulfilling work environment.

]

Dan Neumann: [22:59]

I can’t tell you how many times I’ve had the sense that teams are just pulling items off the back of the product backlog. And while that isn’t the worst thing I could ever imagine happening, it can turn this empowering framework of Scrum into what a lot of times I’ve heard to referred to as the hamster wheel of Scrum. And I don’t know if anybody like me had a pet hamster when they were a kid, but hamsters get in that little wheel and they just run and run and run and run and they never get anywhere. And I’ve heard that complaint about the Scrum framework being, Hey, we do a sprint and it, and immediately the next one starts and that one ends and the next one starts and it becomes tiring. It becomes daunting. We’re just sprinting and sprinting and sprinting. I think the sprint goal and having really valuable sprint goals can enable teams to really see that we have done something that is really cool. We have done something that is valuable to the organization. It changes somebody’s life and it’s, that should be super empowering to teams. And so I really like thinking about what it would look like to have a real sprint goal. That’s very empowering and to get people moved off of we’re working on item number one, three, seven, five, two, and that’s not inspiring to anybody. So let’s talk about sprint goals and really making it something that matters and is connected to that product goal. And now let’s hear Sam’s thoughts about the change in the Scrum guide from self-organizing teams, which was the old wording to self-managing teams, which is the current wording.

]

Sam Falco: [25:05]

At first, when I saw that change, I didn’t think much of it. I thought it was sort of a search and replace type of thing. To me, Self-organizing and self-managing seemed like the same thing. I’d often thought that self-organizing was chosen to keep managers from freaking out. What do you mean the team is self managing, then what am I going to do? That might be a cynical take on my part, but even if the change is merely semantic, the significance is that organizations need to look at Scrum in a new light or we’ll look at Scrum in a new light. That phrase self managing is going to be a big shock to organizations that haven’t allowed teams to be either self-organizing or self managing. A lot of organizations sort of gloss over this concept teams aren’t really selecting what they’re going to work on, except in the very shallowest sense of they get to take the items that are at the top of the product backlog. Product owners aren’t really making decisions about what’s in the product backlog, except in the very shallow sense of deciding what gets worked on first. They’re still just taking orders from stakeholders, teams don’t craft their own goals. Goals are handed to them. Teams might be allowed to decide how to do what they’re told to do. Maybe we let them decide who sits, where, what their core hours are and that sort of thing. But there is a lot more to self managing than just allowing people to decide where they’ll sit and what they’re going to work on specifically today. What happens when we’re using Scrum, but we’re not allowing teams to be self managing? One frequent complaint about Scrum is that there are too many meetings. And I talked about this in a trainer talk episode last year, this complaint is common. When an organization imposes Scrum from the top down, here, you’re going to do this. They don’t change anything about the way they work. So all those other meetings that are on your calendar don’t go away. And by the way, here’s four more you need to do. Often organizations that dictate Scrum as a veneer, a top, their existing processes don’t see any better delivery than they were seeing before. Sometimes things get worse because now they have the added overhead of the events of Scrum and all of the things that go with that. And this leads to a lack of engagement, a lack of ownership. It destroys morale. It causes turnover. You not only can’t retain talent, but you can’t attract talent because word gets out and people hear that, Yeah, you don’t want to work there. That’s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay. Once they’re there. In his book, drive Daniel Pink examined what really motivates people in complex knowledge work domains, which includes product development. What he found was that what motivated people wasn’t being rewarded with money. The three factors that motivated knowledge workers are autonomy, mastery, and purpose. Autonomy is the ability to decide what am I going to work on? And how am I going to work on it? Mastery is the ability to continually improve your skills and purpose means doing something that’s meaningful, self managing teams leverage all three of those factors. And Scrum done well has this stuff built in a Scrum team, decides what it’s going to work on a product goal is more than just a statement handed down to the team. The product owner creates it and also collaborates with the Scrum team on it and on what the Scrum team needs to do to realize it. The entire, our team gets involved in that emergent product backlog map management. That’s autonomy. Another way that Scrum gives teams autonomy is that they set their own sprint goal.

]

Sam Falco: [29:13]

No one says, this is what you’re going to be doing this sprint. Instead, the Scrum team talks about what would be valuable to do based on the feedback they’ve gotten so far and creates its own goal and a plan. And then of course, every day in the daily, Scrum, the developers meet and figure out how they’re going to move a little closer to the sprint goal that day. They’re responsible for coming up with that plan. Nobody else. Scrum encourages mastery. The Scrum team is accountable as a whole for delivery. So there’s no idea that, well, this is my area and I don’t have to do anything else. We all expand our knowledge together, right? Work together. And then of course, purpose is built into Scrum. We have that important product goal that tells us what we’re building and why. And it should be exciting for us.

]

Sam Falco: [30:00]

A benefit of self-managing teams is that it takes away overhead for managers rather than there’s nothing for managers to do, now, they get a, a different focus for their activities. They don’t have to spend time directing people, telling them what to do, keeping an eye on their activities. The manager who introduced Scrum to me and the team I was on and who asked me to be the Scrum Master was so relieved when he could stop chasing us down for status reports when he didn’t have to be checking, being in on us and making sure we were doing things or telling us what we need I needed to do. He could just say, here’s what we need to accomplish. And we figured out the rest on our own, his management activities became about helping us grow in our careers. He would ask, what do you need to know? What do you need to learn? How can I help with that? That was both technical skills and for our ability to navigate within our organization. And that was a much more fulfilling experience for him. And frankly, for us, another benefit of self managing teams is you get this sort of serendipity in development. You hand people a problem to solve and then get the heck out of their way. We’ll solve it in ways that you never imagined, maybe solve it better than you would have. If you told them what to do, do using Scrum to manage a project, instead of using it to drive product development, misses out on creating valuable products and valuable outcomes, especially in the face of uncertainty, we can pretend that we can predict the future, but we can’t. And in complex product development, something new is always going to come up. There’s an enormous amount of uncertainty. Scrum allows us to adapt to that uncertainty as it arises in every sprint, we have a chance to change direction and self managing teams can do that faster than if they’re waiting for someone to tell them to do it. How do you get there? First say abandon the illusion of control. I had a manager once who really struggled with that. He had a deliverable that he’d been told, had to be completed by a certain date. He’d been told the scope and immovable target date and a fixed budget. And he was obsessed with making sure that everyone knew what he wanted them to do. And I said, let’s try to leverage Scrum for this. And he said, as long as everyone does what I say we’ll succeed. As a result, people didn’t take initiative when they needed to, for fear of getting slapped down, that project ran late and there was hell to pay as a result.

]

Sam Falco: [32:48]

This is a terrible pattern and it repeats over and over again. We need to let go of the idea that we can control everything that we can predict everything upfront feeds your team with objectives, not tasks. Set the boundaries within which they can make their own decisions and steer their own course. Empower your product owners to make decisions and shepherd their products. Certainly they need to take into consideration what stakeholders need and want, but product owners need the latitude to make decisions about what is most valuable to do and give them the resources they need to make those decisions. Things like access to market data, access to customers. And so on. Encourage the Scrum team as a whole, to be accountable toward each other and toward achieving positive outcomes, encourage teams to do small experiments until the goal is achieved, or the goal becomes obsolete and then have them create a new goal. Give them a new objective. We can manage risk with small sprints where we constantly inspect and adapt not only the product and our progress toward the product goal, but also the team’s effectiveness, the processes they work with and the objectives they’re being asked to work on. As one of the principles behind the agile manifestos States build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. And they will. That’s the promise that self managing teams in Scrum offers. I hope you’ve benefited from this exploration of the changes in the new Scrum guide. I’d love to hear your feedback. If you have a question or a comment, please email us at podcast@agilethought.com.

]

Dan Neumann: [34:38]

As Sam said, we would love to hear your feedback. And in this last installment that Sam was sharing, it made me think of how many times I hear the perception that Scrum is just a methodology. It’s like another methodology, but this one’s the Scrum methodology, the Scrum masters, maybe like the project manager. If you really look at self managing teams and start to think, Oh, it’s just, you know, the waterfall framework, but I’m sorry if the waterfall waterfall framework. Yeah, when’s the last time you worked on a waterfall project that felt like a framework. And so it’s not like a rigorous waterfall process. Scrum is a framework. We want self managing teams. We want to trust the teams to figure out the best to deliver on the product goal, the sprint goal. We want them to organize around the work. We are them empowered to say, you know what? These particular activities are wasteful. We’re not doing them. We are going to invest in how we, as a team can get better. It’s really a fairly radical thing to think about self managing teams. So let that one just sink in for a little while. Self managing teams is a pretty radical part of the Scrum framework and it’s not just a different methodology. And we kind of iterate through a business requirements document in two week chunks and do blah, blah, blah. It’s a big shift when done well, when you truly fulfill the Scrum values and you use the Scrum framework effectively to really impact your business, it’s a big deal. And so I want you to think about that. Like Sam said, email us at podcast at agile thought ideas. If you loved what you heard here, emails, podcast@agilethought.com. If you think we’re idiots and are just totally wrong. Email us at podcast@agilethought.com, we will, we’ll take that email and we’d love the feedback. Thank you. And look forward to engaging with you. Next.

]

Outro: [37:04]

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.

Agile Podcast: Agile Coaches' Corner