Current Episode

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. Hey, everybody. So good to be chatting with you. I’m super excited about a new tool that I created that I think will help you immensely. I know it’s already helped me a ton, and I’ve only used it a couple times. I want to tell you about this tool by way of a story, but first, let’s frame it by way of a question. The question that I usually get is, how do we know if our team or teams are set up correctly? By set up correctly, the person is usually asking, how do I know if I have cross-functional teams? Cross-functional teams, of course, are teams that have everybody they need on them to get a unit of work out the door. They can solve a problem together, and without passing it off to somebody else, deliver value.

Scrum makes a big deal out of this. You need to have a cross-functional team so that you can make a commitment as a team and you can make it. The only thing that would stop you from making it to the finish line, to getting that thing out the door, is some sort of other impediment that came up, but it’s not going to be because you didn’t have who you needed on the team to do that work. Traditionally in traditional project management, we usually set up teams by component. We’ve got the database team, and the front end team, and the server side team. Each one of those teams does some work and then hands it off to another team. They usually have to write a bunch of documentation as well to hand it off to the other team so the other team knows what to do with that team.

Scrum teams, of course, they don’t do that. They’ve got all those folks on a team working together to get a feature out the door. That’s predicated, of course, on the idea that you actually have a cross-functional team, and it turns out lots of people think they do, but actually they don’t. This activity will help you figure out as an organization, as a team, if you do have cross-functional teams, and if you don’t, it will help point you in the right direction to correct that problem. Let me tell you the story about how I came up with this activity, and then you can figure out how to put it in practice with your team or organization.

I was recently doing some coaching with an organization. They had initially seven product owners for seven teams and a chief product owner for a big initiative they’re working on. Each one of these teams was correct scrum team size. There were three to nine folks, each team had a product owner. All these things are good. They’ve got proper size teams, they don’t have too little in terms of product ownership. But I was concerned from the beginning that there was probably a decent amount of overlap across the teams. Through some conversations with them, even though they were a bit resistant initially, they were able to get those seven teams down to three. They condensed them into three teams that made sense to them.

That was good, but we still had three product owners and a chief product owner for not that many people on scrum teams. Now, it’s not the end of the world. That structure sounds relatively reasonable in a lot of cases, but given our conversations, I was concerned that there was still a decent amount of overlap across the three teams. Through some conversations with them, they insisted that there was not, so I was certainly open to being incorrect. I’ve been incorrect about such things in the past, but I had this nagging feeling there still was overlap that we had not identified. On my coaching day with them, I had about 20 folks in a room, a big room with tons of wall space, and I had the teams in question, the three teams, or at least a bunch of representatives from each one of the teams, I don’t think we had every single person, I had them create a story map for each one of their work streams, or product backlogs in this case.

If you’re not familiar with story maps, they’re something put together by Jeff Patton. He’s written a book on it in the last couple years, and he has a PDF you can download that’s a Cliff Note version of how to build the story map, which I’ll link to. I’m not going to go into detail about how to create one here. I think that would make a good podcast episode in the future. For now, just know that they’re like a product backlog but with another dimension. They give you more context, more information about your product backlog in frankly, I think an easier to consume format. Somebody who’s not initiated to scrum or agile who’s never seen a user story before can take a look at a product backlog in the form of a story map and they can walk the wall. They can take a look at what’s in the story map, and with very little explanation from somebody who knows what the thing is, they can get a good idea of how the product’s supposed to work. They can even get a good idea of what’s coming up in the next release, for example.

I like using story maps because they’re a great way to get a bunch of people all working together to flesh out the ideas they have, the wants and needs the customers or market has, the ideas they have, into a big thing that you get a bunch of context on and you can see on a wall and talk about together. I think that product backlogs are quite useful when they turn into sprint backlogs within a sprint, but when you’re looking at the product for the next six months or a year, they can be a little limiting because you lose a ton of context.

Nevertheless, I had the teams create a bunch of items for this giant story map, or three actual separate story maps. Once we had the walls covered after a morning of this exercise, in hundreds of hundreds of three by five Post-its, I gave everybody in the room another task. I said, “It’s great that you have a current story map. Now I’d like you to take these red dots,” and I handed out a bunch of red dot stickers to everybody, “I’d like you to put a red dot on any item that you need one of the other two teams’ help with, or you need somebody’s help from outside of this room with.” Honestly, I didn’t have an idea of how many of these things might exist, but I had a pretty good idea that there were more of these things than the team expected. They started putting dots on items, and pretty quickly, within 30 seconds or a minute, somebody in the room said, “Could we just put dots on items where we don’t have dependencies, where we don’t need somebody else’s help?” I said, “Nope, no, you’ve got to put them on each item.” They said, “Well, we don’t have enough red dots.” I said, “Well, I’ve got more,” so I handed out some more red dots. They spent the next 15 minutes or so putting red dots on 80% or 90% of the items we had around the room.

Going into this activity, they really believed that they didn’t have a ton of overlap. This is not some deficiency in this team or group of people. For people that have not done this before, it always seems like there’s just a few overlaps, there’s not a ton. The reason this activity is so powerful and why I recommend it to you to use with your teams or even just your team looking at product backlog is that until we make this sort of stuff visualized, until we make it visible to everybody and we have a shared understanding of that through the visualization, it’s pretty nebulous. It doesn’t seem like there’s a lot of overlap.

The red dots are amazingly powerful, and here’s why. At the end of those 15 minutes, everybody was looking around the room at the hundreds of Post-its that they had created that morning, and they were looking at the hundreds of red dots that were on each one of those Post-its. There weren’t hundreds on each one of the Post-its, but there was dots on almost each one of the Post-its. This is so amazingly powerful because those red dots are what will get you in trouble.

What I said to the group, all 20 of them when they were standing around looking at all the red dots, I said, “Take a moment just to look around the room right now. At the beginning of the day today, we had nothing on the wall, and then you created a ton of product backlog items, which is fantastic. Those things, getting those things done are what are going to deliver value to your customers. Those are the things that are going to delight people. That’s the stuff that you’re going to be super proud of at the end of this release cycle. But those red dots, each one of those red dots that is up on a Post-it, is the thing that is going to kill your project. It’s the thing that’s going to make it impossible for you to deliver value or very painful to deliver value. It’s going to slow you down. It’s going to make this stuff take longer than you ever expected. Those red dots are the things that kill projects.”

Now, this is a very able group of people. The project probably wouldn’t have completely died, but it’s true that those red dots were going to make things very, very, very hard. After looking around the room for about a minute, there was quick consensus that those red dots were the things that were going to hurt them. The conversations they had after that about how to remove those impediments, how to form teams so that they were in fact cross-functional, were priceless. Those are the things that get in the way of teams being successful. It’s the reason why waterfall doesn’t really work for complex thought work like software development or other things.

Having a visual representation of this is amazingly powerful. I recommend that you sit down with your team, take the current product backlog that you have, and just put red dots on the items where you need other teams’ help, or you need people from outside your team, or the teams you’re really working with on a regular basis. Anytime you don’t have who you need on a team to get that thing done, put a red dot on it. This will drive really useful conversations like, “Oh, I didn’t realize that we needed the marketing department to sign off on this item. Man, maybe we should have someone from marketing join us, or sprints that have items like that. If we have items like that every sprint, clearly we need a team member from marketing on our scrum team. We don’t need to respect the boundaries of our organization. We don’t have to worry that the marketing person isn’t in the development organization. What we need to worry about is that we don’t have who we need on our team to delight our customers.”

If your team or organization has been struggling with delivering value every sprint, if you keep running into impediments in the form of not having who you need on your team, even if your team already knew that’s what the problem was, do this activity. Do this activity with folks from the rest of the organization as well. If your team knows this is an impediment but you have not been able to articulate to the rest of the organization why you need actual cross-functional teams, you haven’t been able to convince management to put other people on the team that are outside of your part of the organization, if they’re outside of development, for example, and you need them on the team, maybe need someone from legal as a subject matter expert to join you for sprint planning and maybe throughout the sprint, if you’ve not been able to convince people of that, get your items on the wall. Get them on the wall in some physical form on index cards or Post-its, whether it’s a story map or not, doesn’t matter. Get them up there, then get the red dots on the items that you have dependencies with other people for.

Make it visible. Make it visible to the organization. Have people come in and have conversations about this from outside your team or teams. Let those red dots speak for themselves and speak for you to help you get what you need to be able to deliver and delight your customers. You know where to get the red dots. You can get those at an office supply store or Amazon. You get Jeff Patton’s stuff on story mapping. I’ll put links to it in the show notes. You don’t need a story map to do this. You just need product backlog items, but I highly recommend story maps because they’re fantastic. I hope you found this helpful. I look forward to chatting with you next week. Until then, stay agile. Never change.