Achieving Successful Scrum Team Dynamics

Scrum has the potential to boost your team’s productivity, but realizing that potential is up to you. Mitch Lacey, agile coach and author of The Scrum Field Guide, explains why ensuring greater success starts with improving your organizational alignment.

In the world of Scrum it’s fairly common for organizations to quickly jump into practicing the agile methodology and then become frustrated or disappointed when they don’t see significant immediate results. Of course, going through the motions of Scrum and actually practicing it effectively are two very different things. In fact, as Mitch Lacey explains in this weeks’ Labcast, the road to the latter starts much earlier in the adoption phase — by establishing the right organizational and team dynamics.

This Week’s Guest

When I’m talking with a senior leadership bringing Scrum in it’s all about organizational alignment. How do we understand the culture that we want? How do we highlight the principles and values more of the competencies that we want within the organization and people to achieve the end goals?

— Mitch Lacey, author of The Scrum Field Guide

Key Takeaways

• To truly make scrum a success, integrate it into your company’s culture and organizational alignment.
• When it comes to reluctant members, stress Scrum’s ability to change the direction of a project so they get what they need.
• Scrum starts at hiring. Don’t hire based strictly on technical ability. Consider competencies.
• Consider two approaches for your Scrum of Scrums: The Bottom-Up Perspective and the Top-Down Perspective.
• Prioritization is key. Meeting with your customers and stakeholder at the beginning of sprints to identify and prioritize issues.

Listen Here

Labcast 122: Scrum Team Dynamics with Mitch Lacey

Subscribe to Labcast

Transcript

Kevin: Hello there and welcome to another edition of Labcast. I’m your host, Kevin Caine, and today I’m joined by Mitch Lacey to talk about scrum team dynamics. For those of you who don’t know Mitch, he’s an agile practitioner and consultant and the founder of Mitch Lacey and Associates, Inc., a software consulting and training firm. Hey Mitch, thanks so much for joining me today on Labcast. How are you doing?

Mitch: I’m doing fantastic. Thank you very much for hosting me.

Kevin: Yeah. It’s great to have you here, and I’m excited today to talk about scrum team dynamics. At OpenView, we’re great proponents of scrum, it’s something we use in our organization every day. I know it’s not something that all people use, and so my first question to you is what advice do you offer people who are looking to bring scrum into their organization?

Mitch: Advice on bringing scrum into the organization is an interesting one. I have a large banking customer in Western Europe, and they’re going through this transformation right now, and as you can imagine from a banking perspective, they’re fairly formal in their processes. They have a PMO office and stuff like that, and we see this uprising of teams, where they’re wanting to do scrum and they’re wanting to adopt the agile principles and values, and that’s sort of colliding with upper management, and I’m working with them to bring scrum into the organization both from a grassroots level, a mid-management level, and then in December I’m going to be having a discussion with their C-level execs to talk about what does it mean to bring scrum into the organization, and then from a mid-management and a C-level organization, what does it mean to actually adopt it? There are several key items here that I think are really critical.

Number one is culture. A lot of people play lip service to culture, and I hear this all the time where yeah, we have to have a good culture in order to support scrum, and our culture doesn’t support it, therefore we can’t do it, so how do we bootstrap it, and this is what my discussion coming up with the C-level folks is going to be focusing on this around culture and how do we embrace not how we do things, but the values and the goals and the objectives.

For example, one of the things that these people want to see is they want to see faster response times to customer requests. In order to accomplish that goal, a traditional project plan would be laid out. The scope document would be created, the project plan would be created, the budget would be created based on all of the master requirements documents, at that point, the team would be built and frankly committed, and it would be told, “You must hit this date, you must take this time, you must hit the scope.” And then the problem is because things are unprioritized, having a prioritize product backlog. Since things are unprioritized and you multiple projects like this going on, these teams are constantly getting thrown into different directions.

So, when I’m talking with a senior leadership bringing scrum in, it’s all about organizational alignment. How do we understand the culture that we want? How do we highlight the principles and values more of the competencies that we want within the organization and people to achieve the end goals? And then what is our role as leaders inside the company to be able to make sure that we as leaders know the direction that the business is going, we know the vision of the business, and we understand why we’re going there? So that way whenever there’s a question from a team member who is three, four, five, six levels below a C level exec, they can sit there and they can go off, I know where to look and I know why my project is more important than this other project, therefore when the other project is asking me questions and saying I need four months of your time, my scrum master, my product donor, the answer is simple. The answer is no because that project is lower priority. This project is higher priority, and now we have organizational alignment around the rules. So, that’s a large basket of stuff, but…

Kevin: So, sounds like what you’re describing there is largely sort of a higher level look at how you can bring scrum into your organization, what needs to happen from a culture and organizational standpoint. What about for the folks that are kind of in the trenches? Those people who are five or six levels down they are just describing? How do you recommend getting them on board, particularly if they’re not from sort of a software background, which is really where scrum originates, and that sort of its tradition and origins?

When you’re working with those bankers, or you’re working with marketers, or folks who aren’t that traditional background, how do you get them sort of to wrap their head around it and get them on board?

Mitch: Yeah. What you’re classifying there, typically, are the business people. You have end-user or you have people who have needs, wants, and desires. They need something to help them do their job better, and that typically revolves around software. Now, those people don’t really care if it is software and not. They don’t care about ETL transactions and stuff of like that. What they care about is: “When I do this, I get that.”

And so what I do those customer base is, from a sales perspective, is I typically go back and I’ll ask them and I’ll say to them, “How many times in the past have you gotten what you wanted when you have asked for it up front?”

And everybody says “Well, I get what I asked for, but it’s not what I mean.”

And I go, “tell me the difference on that,” and they say, “Well, I laid out what I thought I wanted. I laid out this picture, and then people went off and they built it for me and they came back and they showed it to me at the end, and they said here’s your stuff,” I said “Wow, this is really cool but it doesn’t do the following five things that I expected it to do.” At which point, the people that did the work say, “Yeah, well that wasn’t part of the requirement.”

And the person is, the customer of course sitting there going well, “I didn’t know it was part of a requirement are not part of a requirements. I just assumed that you understood what I was doing and what I needed to do to solve my problems, and what you’ve built doesn’t solve them.”

So I always start off with that, and the stories are always the same. The team built something. They built what was asked for, not what was meant. So then in terms of adopting scrum, the question becomes: How many opportunities for feedback would you like within this project to be able to influence its outcome and direction? And people say, “well I’d like as many as possible.” As many as possible is one a day, so on a one year project you’re going to have essentially 280 opportunities, they go, “all that’s too many.” I say OK, the traditional project come here going to have one opportunity, which is at the very end. “That’s not enough.“

So we have, it’s too hot, it’s too cold, and then it’s just right. I find just right to be right around two weeks. So how about every two weeks we get together and we review what we’ve done, and this is your opportunity to influence and drive change with the understanding that the changes you introduce will be free and the things that we replace will be sacrificed.

“I don’t like that, what do you mean sacrificed?”

What we’re doing, essentially, is we’re taking a bottle of water, take one liter bottle of water, and we say that we have one liter of water in there right now, and determine at the end that we didn’t really want one liter for, we really wanted 750 milliliters of water and 250 milliliters of oil, for whatever reason. Fantastic. We identified that early we can do that. But if we identified late, we can’t. So then, we’re going to deliver what you asked for, a liter of water, or we can deliver what you need, 750 milliliters of water, 250 milliliters of oil with the understanding that the water that was originally spent out does not add as much value as what was replaced.

So I talked with those business people in that sense. I never use the word product backlog, I never use the word Scrum, I say it’s an opportunity to influence the direction of the project so that we can help ensure that we are building what you asked for, are building what you need and not what you asked for, and it’s a way to simply manage risk. And they love that, because from a business sense, manage risk, manage costs, yes, that’s what we’re doing. Manage timeline, exactly. We don’t want to get to the end and figure out we delivered the wrong thing. We’d rather figure that out soon.

Kevin: I’ve talked to a number of different sort of Scrum experts like yourself over the last couple of years, and some of them, like Jeff Sullivan, kind of point to the fact that a lot of teams practice Scrum but they don’t actually do it properly, and they’re not getting the full benefits as a result. Part of that seems to come down to scrum team dynamics, and so I’m wondering, what some of the mechanisms that teams can use to kind of make sure that they operate and run more effectively. I know one of the things we do here, and I’m sure you promote to others as well the idea of having these scrum of scrum meetings, where scrum masters come together and they bubble up the issues that their individual scrum teams have surfaced, and then kind of figure out at a higher level how to resolve them, how to remove the impediments and the cross team issues. I wanted to get your sense of what the best practices are around that, and if you could speak to that a little bit more broadly for our audience.

Mitch: Sure. So on the scrum of scrums, let’s actually step back because the thing that you identified was Jeff and other people, we all see this that teams don’t get the full benefits. I’m a firm believer that the full benefit starts at hiring, and I want to just give a quick rant on this. I had an article that came out in the Better Software Magazine, SQE publication around hiring and it’s going to be a chapter in an upcoming book that I’m writing. What I’m doing is I’m experimenting in companies around changing interviewing practices.

So, a traditional interview for a day, you’re going to have six people. And let’s say it’s for a technical person. So we have a developer that comes in, and they meet with person one, person to, person three, person four. Each one of the interviewers is looking for some specific technical need. How does the person solve this problem? How do they solve that problem? Where do their technical chops the lie? What are their boundaries in terms of C sharp, C ++ or SQL? Whatever they’re interviewing for. They determine that the person is a good candidate, it’s a good hire, they put an offer out, the person accepts, and a month later the person quits or gets fired.

This is a pattern that we’ve seen over and over again. Scrum of scrums will identify this, but it’s going to identify it too late. So if we talk about how to resolve this issue up front, I use this immersive interviewing process technique where we’re not looking for skills. Skills can be learned. What was looking for instead is competencies. We would be looking for the issues that would be identified in a scrum of scrums meeting around conflict, around culture, around human dynamics, and we instead put that up at the forefront and say, “Let’s focus on our interviews, let’s focus on interviewing for those applications, for those competencies to make sure that we have a right cultural fit inside the organization.” That way, we’re eliminating the need for solving interpersonal issues or fewer interpersonal issues later on down the road, which a scrum of scrums would help identify.

Kevin: OK.

Mitch: So, given that, now to answer your question scrum of scrums. I see this at two levels. I see this from a top-down perspective, and I see this from a bottom-up perspective. Now, the bottom-up perspective is of course at the team level where we have scrum masters or potentially team members coming together to say, “Here’s where we’re at,” having a normal huddle, having a normal sync. Here’s where we’re at commissioners issues that were seen. Very beneficial from a technical perspective, but what I often see missing is people from a product ownership level not meeting. And you see teams that get pulled in many different directions because they don’t have the understanding around the vision or the direction that the product owners are driving towards because the product owners aren’t meeting.

So from a top-down perspective, I’m a huge fan, firm believer that product owners need to meet on a daily basis as well to talk about what are the challenges we’re having with our customers. What are the problems that we’re seeing with their requirements, with their stories in the product backlog. Do we have any team challenges that we need to be aware of, because some of the teams are going to have to work cross-functionally, of course?

And then, most of importantly from a dependency standpoint, how have we as product owners structured our product backlogs or single product backlog to ensure smooth flow for the people doing the work such that we are eliminating dependencies and surprises? Because there’s nothing worse than getting into the halfway through of a sprint and have one team say, “Oh, I need this,” and then they go to the other team and say, “Where is this?” and then the other team says, “Oh, well, we don’t have that scheduled for two more sprints.” Then those guys got it, but we need it now. We need it now!” And of course, now stuff has hit the fan and there’s dysfunction within the organization.

So scrum of scrums, from a top-down level, I really find help solve those issues, but it’s often the most overlooked thing. So if there’s one piece of advice I would give listeners out there, would be scrum of scrums bottom- up, absolutely required, that’s great. Top-down? Even more required because it will help remove, it will help remove problems with regards to product ownership, product backlogs, story maps, and story dependencies.

Kevin: So one of the things that we run into here at OpenView, where we use scrum, is that we have a number of scrum teams, actually four, and so we meet on a regular basis as scrum teams to hold retrospectives and kind of figure out what our issues are and how to resolve them. But our scrum masters meet for a scrum of scrums meeting every two weeks and what happens is that a lot of stuff doesn’t come up because people are sort of resolving issues on their own teams and there isn’t a whole lot of sort of cross-team learning going on.

Mitch: Yep.

Kevin: And I’m wondering if that’s probably something that sort of symptomatic of these scrum of scrum meetings, at least initially, when people are first learning how to deal that they’re not surfacing all the issues that they should be in charge of bringing things to light that they needs to be. Do you have any thoughts on that?

Mitch: It is. And it’s all around, that’s all around prioritization. I see, when I see new teams, and even experienced teams, teams that are say, nine months into it even. I see this behavior where people will assume that all issues are created equal. They will go down the path of, “Wow, somebody is screaming, therefore somebody’s hair is on fire and I need to put that out,” and then everybody else starts screaming, everybody else’s hair gets on fire. Now we have all these issues that are trying to be resolved, but there’s no way to prioritize them.

The prioritization of these issues I see is really beneficial, number one, in the retrospective. Number two, what I like to do as a product owner is I meet with my customers and stakeholders once every two weeks. I have a recurring meeting at the beginning of the sprint where we review the product backlog, we review the release plan, we review the road-map, and what we do is we talk about the direction that we’re going for the next four to eight weeks, so two to four sprints.

In that meeting, I try to identify as many issues as possible, and then we simply triage them on a scale of zero to three, where zero is oh my, this is a showstopper and this has to be resolved right now to a three, which is hey, here’s an issue that’s on the radar and it may surface, and it may not, and it’s basically, it’s a modification of a risk management technique that is outlined in Waltzing With Bears by DiMarco. It’s an older book, but it’s still a fantastic read around risk management. Because managing these issues is still simply a risk management technique that I’m a firm believer a product manager needs to do.

Kevin: You mentioned a second ago prioritization and how important that is, so switching gears for a second, I wondered if you could talk us a little bit about the prioritized backlog and what it is, how it works, and what’s the best way to create and maintain it? I think that’s something that some teams struggle with as well.

Mitch: Yeah. Well, one of the funny things that I see always happens at the beginning of a project is a product owner will go off, they’ll meet with the customers in the stakeholders, and they come back with anywhere from 100 to a thousand stories. At all different levels. And the product owner, the poor product owner says, my head’s in a blender and I don’t know what’s going on, team, help me. And the team looks at it and they, “You got 1000 stickies on the wall, man, I can’t help you with this.”

This is a problem I kept encountering over and over and I actually documented this in my book The Scrum Field Guide, prioritizing and estimating large backlogs. The beginning of any project, one of the things that I always do is I get my customers and stakeholders in the room and we take a wall. And I try to use a really big wall, probably 10 feet high by at least 40 feet wide if I can. The bigger the better, and basically what it is is it’s this. The things on the left are small, the things on the right are big. The things going vertically up and down, the higher up they are, the higher value, the lower they are, the lower value.

And what this allows us to do, then, from a team perspective is come back and say OK, this grouping here on the left feels like about a one, so we take some tape, we draw down the line one. OK, now where’s the two grouping? Where’s the three grouping? Where’s the five grouping? What we do is we start batching these stories with different priorities. We start batching these stories into these different groups to give us on high level estimate look, where we’re able to say “These feel as a group about three,” and then we go back as a team and we look through them one-on-one and say, “Yeah, this is really a much bigger product owner, tell me what this means.” And we do this with customers and stakeholders in the room is well. So that way, we can get a better understanding across the board around, again, what was meant not what was asked for.

At this point, coming out of this meeting after doing this technique, is we now have a rough sketch of a product backlog that is loosely estimated. Again, because we didn’t go through planning poker on every single story, because if you did that for a thousand stories or even 500 stories, it would take days. What we did is we were able to through infinity sequencing, we were able to map the stuff out and come up with rough group estimates that allow us to have an initial plan that we can then review with our customers and stakeholders and say, “With a degree of confidence of say 60 percent, here’s what we believe.”

60 percent meaning that if we believe this project is going to be, let’s say we have 1000 points, OK it’s going to be anywhere from 400 to 1600. Or 600 to 1400, whatever that range will be.

Kevin: Sure.

Mitch: And what that allows us to do, then, is say if we look back at the cone of uncertainty, what we’re trying to do is move down the cone where we have a more definitive approach so that way our customers have a better understanding around what it is we think we’re going to get and when.

Now, the priority in this exercise is really helpful because it really fleshes out, it fleshes out the conflict that stakeholders have around the crybaby attitude, which is “No, my stuff is more important,” “No, my stuff is more important,” and then they go back and forth around who’s stuff is more important. And this basically helps wash that and say, “Look, everything can’t be high-priority. If everything is high-priority, everything is no-priority, which means for me, as a product owner, I will determine where the value lies. Do you want that, customer?” And they go, “Well, of course not.” “OK, so let’s be adults.”

Kevin: Got it.

Mitch: Yeah, sorry. Long answer to a short question, sorry about that.

Kevin: No, no, it’s great, it’s really great. So is the maintenance of that than that sort of ongoing process of moving the stickies up and around and kind of figuring out?

Mitch: Yeah, exactly. So the ongoing process then is if you have a dedicated room where you’re able to actually keep that as your product backlog and not move it into an electronic tool, that becomes a product owner’s job. I would meet in that room with my customers and stakeholders at the beginning of the every sprint, typically on a Wednesday. I would then meet with the team and that room to do the grooming session, typically on Wednesday of the following week. So that way, we have basically this central work space, because I want that room to essentially be a living, breathing product backlog.

If you want project road map status, you go there. If you want project team or daily status, you go to the team and you listen to the stand up and look at the rundowns.

Kevin: That’s great. Well Mitch, I really appreciate your time today. Before I let you go, can you just let her listeners know where they might be up to get in touch with you?

Mitch: So, my website, MitchLacey.com. Twitter handle is MG Lacey, and I don’t do Facebook. Also, the road map, the timeline that I talked about, is up on my website in the resources section where it basically lays out when I do these meetings, I find people have a lot of value in them. The chapter that we talked about was chapter 29 in my book, prioritizing and estimating large backlogs, and that’s in The Scrum Field Guide.

Kevin: That’s so great, thanks so much. It’s been really fascinating. I appreciate your time today.

Mitch: OK. Thanks for hosting me again, and great talking with you.

Photo by: storebukkebruse