Current Episode

Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Each week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.

The Scrum framework is amazingly simple. If you don’t already know it, you can learn it well enough to teach to somebody else in under a day. The tricky part of the Scrum framework is not the framework itself, but the cultural change that has to take place to support it. Most organizations, when adopting Scrum or any agile approach, find it difficult to make this mind shift into really an agile state of mind. Well, today’s question comes from Amanda, and her organization is transitioning to Scrum and it sounds like they’re bumping up against a bunch of these cultural changes that need to take place not to support their new Scrum initiative. I don’t want to give it away, so let’s listen to her question and see if there’s anything we can do to help.

Amanda: Hi Adam. This is Amanda. My company is transitioning to scrum, and different teams are doing it with varying degrees of success. We don’t always have dedicated teams, so people sometimes move from one team to another. How much consistency between project teams should we strive for? How do we set those guidelines? What are some ways to make teams accountable for using the guidelines?

Thanks for taking my question!

Adam: Hey, Amanda. Thanks for your question. All right, let’s take a look and see if we can help you out. Now the challenge you’re going through is really common. Folks adopt Scrum, organizations adopt Scrum, thinking that they’ll just follow the framework and everything will be cool. They won’t have to change too much other than what it seems like just a small process on working on their projects. It turns out this ends up being a bigger project than all of that. It’s the cultural change, again, that has to take place to support this.

You ask in your question, what are some ways that you can make the teams accountable for using these guidelines. Well, I actually think that’s not the right question. I think it’s going in the right direction, but I don’t think it’s actually the specific question we should be asking here. It is unlikely that it’s your team that is deciding they should multitask. Now your team might be the ones insisting on this, but I suspect it’s an organizational impediment.

Now I think a good guideline that a team organization should follow is that a team member works on one dedicated team and doesn’t move around. Now when first adopting Scrum, it might not be possible to do that, in which case I think the guideline should be a team member will work on no more than two teams. Past that, you’re going to drive folks crazy. Frankly, with two teams, it will drive people a little bit crazy, but you don’t have to take my work for it. I would have a retrospective with my teams and find out what impediments they have for doing their work. And I suspect that one of the things that will come up is that they get moved around from project to project to project. And the reason I can make this guess is it happens pretty much with every team.

And there’s actually a theme called the Tuckman Model. I don’t know if you’ve heard of the Tuckman model before, but Tuckman was a psychologist for the US Navy. He defined four steps that every self-organizing team goes through. They go through these steps of forming, storming, norming, and performing. Maybe you’ve heard of the Tuckman Model and didn’t know that’s what it was called, because you’ve heard of forming, storming, norming, performing.

Well, the forming stage is where everybody gets together and they’re kind of polite with each other and not much happens. This would be like if you go to an event where you don’t know anybody and you introduce yourselves and make small talk. Not much happens, not a lot of work gets done, but it’s the beginning of forming as a team. You go from that into the storming phase.

And the storming phase is where people are finding out where they fit within the system, how they’re going to contribute, how they relate to others, how you get work done. This can be a little crazy. Good facilitation from a good Scrum master can certainly help, but it can be a little difficult in the storming phase. And the trick to all four of these steps is that while you might make it in to the second stage, for example, you’re not necessarily ever getting out of there. A team has to figure out how to get into the next stage together. And again, good facilitation will help, and there’s no right or wrong answer for how long a team stays in one of these phases, but eventually, hopefully, your team will move from the storming phase into the norming phase.

Now the norming phase is better than the storming phase in the sense that now some work is getting done and it’s not particularly chaotic, but they’re not a high performing team yet. If your team gets out of that stage and gets into performing, they are what we strive to get in agile teams. We strive to get a high performing team, a team that is stronger than its individuals, a team that is clicking really well together.

Now the trick with the Tuckman Model or just team dynamics in general is that if you change the makeup of your team in any substantial way, and on a Scrum team of five folks, a substantial way is one person, you go back to the same four steps. You’ll go back to the first step, and you start forming again. And hopefully, you get out of that stage and you move on to the next one. In all likelihood, if you don’t change much of your team, you just change one person, for example, you’ll get through those four stages, back to where you were, relatively quickly. But there is definitely a cost to changing the makeup of your team. And you might not ever get out of the storming phase again. For example, maybe the makeup of your team changed substantially, and because of the personalities and the ways of working and such on the team, you get stuck in one of those stages for a very long time. So there is a huge cost to switching up your team. And usually, we switch up teams because organizations require it of us.

So you ask about guidelines, and my guideline would be you should be on one team. And if for some reason that is totally impossible, start out with you can be in no more than two teams. There’s your guideline.

Next, I think you need to figure out how to implement this. I suspect it’s through some coaching conversations with the organizational leadership and management. They probably have control over how many teams people are put on. One of the arguments I normally hear in this situation is that, “Hey, we’ve got a lot of projects. There is no way to have a team per project. You can have one product backlog for each project, because we got 30 projects and we got 7 people, what are we going to do?”

Well, the first thing I would do is put all my work into a product backlog. Now I know it’s disparate projects and all going into one product backlog sounds like a misnomer. I guess it kind of is a misnomer, but it’s all right. Put it all in one product backlog, and prioritize that work, because you’ve got seven folks, and they can only work on one or two things at a time. So prioritize that product backlog, and by doing that, you will be moving work to people and not people to work. You’ve got a team that stays together for the long run. You don’t change the makeup of the team, but you changed the work that they are working on. Now there’ll be some context switching involved in that, but that’s okay. It’s going to be the situation if you’ve got 30 projects to work on, 7 folks to do the work, there will be context switching. Context switching is expensive, but not as expensive, I suspect, as switching your team up.

If you look outside of software and you look at sports teams, I suspect that you wouldn’t expect that a high performing, amazing championship team only got together and played once or twice a year. They probably played together for the year. And in most cases, they played together for much longer than that, and only small parts of their teams changed. That’s how they become high performing. So the same thing is true with the Scrum team.

Now in these conversations with management, I want to give you an exercise that you can try with them to help illustrate this, because people know logically that context switching or rather, changing the makeup of your team can be expensive, but they don’t really get how expensive it can be. So this exercise will help illustrate that. And before you try it with someone in management, I would suggest you try it yourself. So we can try it right now, unless you’re driving. If you’re driving, you’ll need to wait to listen to this part of the podcast. Well, you can listen to it now, but you can’t do this writing part. Do not write and drive. Bad idea.

So grab a piece of paper and grab a pen. We are going to make a table. The table is going to have 10 rows and 3 columns. You don’t need to draw the 10 rows, that will be fine. Just create the three columns for now. The top of column 1 will be labeled Project 1; the top of column 2, Project 2; the top of column 3, Project 3. Got that? Great. You’re also going to need a timer for this exercise. So I suspect you’re listening to this on an iPhone or some other smart device, you’ll want the timer from that. If not, go grab a timer. You can always pause me if you need to.

And the next thing we’re going to do is fill in those columns. And the way we’re going to fill them in, in the first part of this exercise, is by row. And let me explain what goes into each row. In the first row, under Project 1, you’re going to put the letter A. Under Project 2, you’re going to put the number 1. Under Project 3, you’re going to put the Roman numeral for 1, which is I. Then you’re going to move on to the next line, and on row 2, you’re going to put the letter B. And on column 2, on row 2, you’re going to put the number 2. And on column 3, on row 2, you’re going to put II. Makes sense? And I will put all these on the show notes so that you can sort of get a visual of this. I know it’s a little bit difficult to explain via audio, but I think you’ve got the idea.

So what I’d like you to do in a moment is start with Project 1, Project 2, Project 3 in the columns and fill in the rows as I described until you get to the tenth row which will start with the letter J, for example. And I’d like you to time that. We’re going to time how long it takes to fill in these columns row by row. So pause me for a second, start your timer and fill in the table and I’ll talk with you in a moment.

All right, welcome back. All right, so you’ve got a time for how long it took you to fill in that table. We’re going to do a second round here. So you’re going to start the second round in the same way, by creating three columns, and the first one will be Project 1, etc., just like we did before. But this time, instead of filling them out row by row, you’re going to fill them out column by column. So don’t do it yet. But in a moment, when you start the timer, you’re going to fill in, or fill down, I guess, A all the way through J. And then you’re going to move on to Project 2, and you’re going to fill in 1 all the way through the number 10. And then then you’re going to move to Project 3 and you’re going to fill in I, the Roman numeral for 1, all the way through Roman number 10, which is X. All right? You’re going to time this as well, and then you’re going to meet me back here. So go ahead and do that and pause me, and come on back.

All right, welcome back. Okay, if you are like most people, and I suspect you are, at least in this respect, the second time you did this was much easier and your time showed such, right? It showed that by not multitasking, by working on one project at a time, you got some huge performance increases. The same thing happens when you change the makeup of teams. If you have to figure out how you’re working on a team, how you’re going to do work together, if you’re going to go through that whole Tuckman Model, it’s expensive. And often, like I said, people will get this logically, but until they do that exercise, it doesn’t totally make sense. So I would use that coaching activity with management, with folk s that are saying, “Yes, but we cannot stop changing up teams.” Not true that they cannot stop making changes to teams. It’s that they haven’t decided that they are going to do that. It takes some will. It’s not easy, but it’s the right thing to do in most cases.

So Amanda, I hope that gives you some tools that you can use to help address this issue. Again, I wouldn’t focus on making teams accountable. I’d focus on making organizations accountable for this. And the first place I’d start is by getting feedback from your team via retrospective, and then I would have a conversation with management about how we could not switch up teams so much. And when you get pushback, which I suspect you’ll get a little bit of, try the exercise we just tried. It is quite possible that they’ll get some better insight into the difficulties of having to switch teams. Now it’s not, even after that exercise, it’s not a slam dunk. There’s still going to be some hard organizational change that needs to happen. And that’s okay, at least you, as an agile coach, as a Scrum Master, as an agilist is helping your organization identify these things and figure out how to move forward. So I hope you found that exercise useful.

And if you did, I would love it if you would leave some comments in the show notes. And to do that, you can just click on my face there in iTunes, if you’re listening to me on iTunes on your iPhone. If you just tap on my face, you’ll get the show notes. And you click on the link that says “Rate this episode.” If you leave a star rating or better yet, a review in iTunes, it’ll help get the word out about the show. I’d love to have more folks asking questions. In fact, I’d love to have you ask a question. You can go submit your question at GetAgileAnswers.com. GetAgileAnswers.com, right there on the home page, there’s a little widget where you can record your question and get answered on a future show. If I select it to answer on a future show, you will also get a deck of my Agile Antipattern Cards for free, for helping you, for leaving you message. Not only will you get cool answers to your questions, you’ll get a deck of Agile Antipattern Cards.

Thanks again to Amanda for recording her question, and thank you all for listening. I’ll see you next week on Agile Answers. Until then, stay agile. Never change.