Episode 140 - 05 Dec 2019
Grab your FREE copy of the Scrum Cheat Sheet: https://www.developmentthatpays.com/cheatsheets/scrum
Watch Pragmatic Dave Thomas in action: https://youtu.be/a-BOSpxYJ9M
The five Scrum values - aka the 5 things that are valued in Scrum - are:
We are dissecting Scrum to take a look at it piece by piece.
We've looked at the artifacts.
We've looked at the events.
We've even looked at the three pillars that underpin Scrum.
But there's one area that we've yet to cover. Some would argue the most valuable area of all. I'm talking, of course, about the five Scrum values.
Welcome to Development that Pays, my name is Gary Straughan, and as you may know, I'm from the northeast of England, Newcastle to be precise.
Now, the northeast is known for its heavy industry, things like shipbuilding and coal mining. It's not really known for its touchy-feeliness. There's a low tolerance for management speak.
Now, myself, I've been away from the northeast for quite some time. I've done a little bit of management training on the way. And I've got to the point, finally, where I can say things like "strategic thinking" and "vision statement" without pulling too much of a face.
But there's one term I've always had a bit of a problem with and that is "values". The mere mention of the word was enough to make me shut down and not listen anymore.
At least, that was the case until I happened to be watching a video on YouTube, a presentation by a guy called pragmatic Dave Thomas. His presentation is called Agile is Dead. Actually, it makes pretty interesting viewing. I'll put a link in the description below. Anyway, it's maybe two year's ago, I'm watching the video, it's on in the background, I'm concentrating on something else. But then, I here something that just stops me in my tracks. Here's the exact clip that caught my attention.
"Now, we picked the indexed cards, we divided them into piles, depending on what they were about. And it became clear that what we wanted to look at was kind of like the values of our software, you know, what is it that we value when we're writing software."
Did you hear that?
"What is it that we value when we're writing software?"
Is that really the same as values? Because "things that we value", that sounds okay to me. It's perfectly clear, perfectly descriptive. And it doesn't trigger me in any way at all. Yes. So, in a second, pragmatic Dave Thomas, you rewired my brain and I no longer have a negative reaction to values. So, this episode is probably thanks to you. If I hadn't seen that clip, I probably wouldn't have made it.
What are we here to talk about today? Oh, yes, of course. The five Scrum values. Or should that be "the five things that we value in Scrum"?
The five values are:
We're gonna be going through them in that order. though, I'm sure other orders would work just as well. And we're gonna start as we usually do, with a quick visit to the Scrum guide. Actually, let's save that to just a little later. I'll explain why when we get there and instead, get right in with the first value, the value of openness.
We can draw a straight line from the Scrum value of openness to the Scrum pillar of transparency. Without transparency we can't inspect. Without inspection we can't adapt, we can't improve. Now, Scrum is open in many ways. Anyone can add a new item to the product backlog.
The Scrum meetings, the Scrum events are open. And if the team has a board, then even the work is visible.
Everything then, out in the open. Inside the team, openness means getting used to talking to other people about your work, to discuss options, and especially, to reach out for help when things get a little tricky. In short, openness is a precondition for effective collaboration. And it goes without saying, or at least, I hope it does, is that we need to be open in order to change, and in our agile worlds, change is, after all, the norm.
Hand in hand with openness comes the Scrum value of courage.
It takes courage to ask for feedback. It takes courage to be open about your work, especially when things aren't going smoothly. It takes courage to speak up when you think the wrong course of action is being followed. And it takes real courage to take on the organization, to push back at actions and behaviors that are preventing your team from performing at its best.
It also takes courage to accept that in our agile world very little is truly predictable and things will go wrong from time to time. Talking of which, when something does go wrong, whose fault is it?
Just take a moment to look back at that question and what it implies, what it assumes. We know from Systems Theory that when things go wrong in an organization, 80% of the time it has nothing to do with the person, and everything to do with the system. And yet, when something goes wrong, we have a strong tendency to point the finger, to find a scapegoat. And it's such a strong tendency, that I has a name. It's known as the fundamental attribution error.
Better than when things go wrong to start from an assumption of positive intent. to come from a place of respect.
For collaboration generally and within a Scrum team specifically, we need the opinions, the experience, the abilities of everyone in the team, and that only happens, that's only possible, in an environment of mutual respect.
Remember that the Scrum team is both cross-functional and self-managed. Everything starts and ends the team. Everything starts and ends with respect.
In Scrum, we are asked to, and by the way, given every opportunity, to focus.
We are members of just one team, we're not spread across multiple teams. Within the team, we're given just one role. We're asked to take responsibility for just one product backlog. But in Scrum, focus more than anything is on doing the work. And that's best illustrated by this rather lovely picture here. This group of people is working hard, but each individual is pulling in a different direction. This team is also working hard, but in this case, each team member is pulling in the same direction. In each case, the effort expended is the same, but the distance traveled, the value delivered, is very different.
Now, this brand of focus isn't left to chance in Scrum. When the team gets together to select items for the Sprint backlog, it asks to be allowed to focus on working on those items for the duration of the Sprint.
Jeff Sutherland, one of Scrum's founders, describes commitment as the linchpin of Scrum.
Of all the Scrum values, this one is perhaps the most controversial, or at least, the most misunderstood. You see, when it comes to commitment, it's all about who is making the commitment and what exactly they are committing to.
Do you, by any chance, have school-age children? And have you ever been to a parents' evening? Well, if so, picture this scene. You've just had some rather worrying news delivered to you about your child's performance in mathematics. Seems like grades have slipped markedly since the last time you sat in that chair. Well, quick as a flash, horrified by the situation, you commit on behalf of your child to an immediate and drastic improvement. How do you think that would play out? Let's rewind that. The bad news is delivered and you as the parent manage to hold your tongue. There's an awkward period of silence and then, your little one looks up, looks straight to the teacher and says, "I'm really sorry, "I've kinda have lost a little bit of focus "over the last term or so, "but those grades, well, they're never gonna happen again. "I'm gonna really knuckle down." How do you think that will play out? Can you see the distinction? An external commitment, me committing on behalf of my offspring versus an internal commitment. It makes all the difference in the world.
Coming back to Scrum, when a Scrum team gets together to select items for the Sprint Backlog, it makes a commitment, a commitment to goals that it has set for itself, an internal commitment. Now, this is a commitment that should never be held against the team. If a Sprint Backlog contains six items and then, at the end of the Sprint, one of those items is still outstanding, well, that's just the way life goes sometimes. It does not represent a broken commitment. As any sports team will tell you, it's possible to play with full commitment and still lose the game, a reminder, then, that the commitment isn't to the final score, the commitment is to the way the game is played.
The Scrum Guide
We are well overdue for our visit to the Scrum guide. I've saved it until now because, as you'll see, it provides an almost perfect summary of what we've talked about today, and also, a pretty good summary of what we've talked about, throughout this entire series on Scrum. So, I'll thank you for watching and yeah, let's get over to the Scrum guide.
"When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum team members learn and explore those values as they work with the Scrum events, roles and artifacts. Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum team. The Scrum team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum team. The Scrum team and its stakeholder agree to be open about all the work and the challenges with performing the work. Scrum team members respect each other to be capable, independent people."
Watch "Openness, Courage, Respect, Focus and Commitment" on YouTube.