Mike Lyons explains what makes Scrum teams effective: the Scrum team comprises three roles (Scrum Master, Product Owner, and Developers). He recommends team size of about seven ("seven plus or minus two") and emphasizes cross-functional teams that include all skills to design, build, test, and deploy value. Lyons cautions against siloed, functionally-separated teams, notes teams go through Tuckman stages (forming, storming, norming, performing), and stresses psychological safety, healthy conflict, and sticking together. He highlights the Sprint Retrospective as a key Scrum event for reflecting on how the team works and committing to one improvement each sprint.
Questions this video answers
Scrum Master, Product Owner, and Developers.
Seven plus or minus two (roughly 5–9 people).
The Sprint Retrospective.
Chapters
And so there you have the three roles that make up the Scrum team. So those three roles, the Scrum master, product owner and developers, all combined together form what we call the Scrum team. Now the sort of size of the team, like how many people should be on it. Well, we like to say it's seven plus or minus two. So somewhere in that range there's a sort of running adage in the industry that two pizza teams, that's the right size, a team you can feed with two pizzas. That's when you know you've got the right size look, you know, any smaller than, you know, four people, five people and you just don't have all the skill sets needed to get work in an enterprise level from, you know, design, build, test and deploy and any larger and communication starts to come in and take too long and things just seem to take longer with, with large teams. So really get that team size right. That seven plus or minus two would be a good number. And then a key takeaway here that I want to remind us of is that we want all of the skills needed on that team to do all the design, build, test and deploy of the thing of value that we're working on. A cross functional team is how we describe that. Very important to have again, right size and all of the skills needed to deliver the thing of value. And this is an important piece to remember. I've been, you know, I've spent a lot of time on teams that were sort of, you know, filled with requirements, gathering and that was the team and they might gather a number of requirements and then they're handing it off to a separate team, like a team of developers and developers just do all the development and then they would hand that off to someone else to test. And, and so you get these sort of silos of teams by function, you know, or maybe by platform even. And we want to avoid that. We want cross functionality on these teams and these teams, you know, they take time to get to high performing. It doesn't happen overnight. We follow the Tuckman stages of team formation, the storming and forming, norming and then, and then performing and all teams go through that. We want these teams to stick together and stay together. We don't want people sort of part time on these teams or you know, joining mid Sprint or mid release cycle. No, we want these teams to start together and stay together and even for extended periods of time. So the Scrum team again has those sort of features about it. And as these teams begin to move and move forward and grow Together and become high performing. It's sort of this idea of becoming part of an awesome team and there's a camaraderie there. Maybe you've been on a high performing team. I have, I've had opportunities to work with teams and as we sort of have this super high morale and you know, I sometimes will ask people like, how do you feel about work on Sunday night? And is Sunday night just sort of a dreaded, I don't want to go to work on Monday? Well, high performing teams, that's not really the case. We enjoy working together and you know, we enjoy learning together and getting smarter together. We challenge each other. Healthy conflict is a key indicator of teams. The willingness for one person to sort of tell another team member truth and you know, in a, in a humble way filled with grace, we want to tell truly truth to our fellow team members. High performing teams have that level of trust. So it's a very important aspect of that and really that comes with sort of some of the softer skills, if you will, of software development, solution development. Back in again in the 1900s we didn't really so much focus on that. It was developers developed to requirements and testers tested what they developed and they kicked it back to fix it if they found a problem. And so these high performing SCRUM teams, there's a, there's an incredible amount of teamwork and trust and psychological safety that we have on these teams. But let's give you an example of like one of the tools or techniques that really promotes that. And specifically within, within scrum, we have the SCRUM event called the Retrospective. We'll cover this in more detail in another lesson. But the retrospective is a time to stop and reflect back on how the team is doing. Not what the team did, that's certainly something we do in the Sprint review, but how we did and then committing to improving one thing as we go forward. The retrospective is an incredibly important event at the Scrum level. I've participated in many retrospectives and I find the best ones are those ones where we are consistently and transparently seeking to improve. And as a team, it builds trust, it builds teamwork and morale. When I know that someone has the trust to share with me an area I need to improve and I'm willing to receive that and go ahead and improve as a developer or team member, that is a piece of becoming high performing. Again, these are soft skills that aren't necessarily directly related to how we test or how we write user stories or how we develop code software. Now these are skills that are important to high performing teams. So again, the sprint retrospective one example of a technique that is used to build teamwork.
