After watching this video, you'll be able to discuss some anti-patterns to avoid when practicing scrum, and describe a checklist for measuring a healthy scrum team. So, let's discuss some anti-patterns. The first one is no real product owner. And I've seen this happen on a number of teams where nobody's really sure who the product owner is. There are a couple of people who seem to be in charge, uh, but clearly one person with a vision, uh, you know is not present. The other opposite I've seen is multiple product owners. I've been on scrum teams where there were two product owners and they didn't always agree on what to build. These are anti-patterns. There should be a clear person who's playing the role of product owner, who's the visionary for the team, who's setting the vision, and leading the team. Very, very important. Then if the teams are too large, you don't want to have, you know, 20-30 people on a team. They should be less than 10. We say, you know, five plus or minus two or seven plus or minus two. You really don't want to have large teams because that is an anti-pattern, uh, because communications becomes too hard at that point and then the teams are not dedicated. I've seen this happen multiple times. People are on multiple projects. You're in the daily stand-up and you say, What did you do yesterday?" and "Oh, yesterday, my manager pulled me off to work on another project." Clearly, that is an anti-pattern. You know that is a recipe for disaster. So, you want to make sure that if that's happening on your teams, your teams are not going to be successful. If the teams are too geographically dispersed... I realize we work in international companies all around the world, you know, my recommendation is put at least two people in a geography, in a time zone, so they can collaborate together, um, but it really works best when all the teams are together in one time zone, one geography. And then if your teams are siloed, you know, the team should be working as one cross-functional team. I shouldn't have to open tickets with other teams to get things done. Everything I need should be on that one team so that's very, uh, important. And then teams are not self-managing. The teams are not being told what to do, right? They're not being given stories to work on. The stories are in the backlog and they pick the next highest story off the backlog and they assign it to themselves, right? They're self-managing. It's critically important for the health of a scrum team. If you do these things you will fail. You should not wonder why you failed. You know you were implementing all the anti-patterns. So, let's talk about some health check items that you can look at and make sure that your team is healthy. One of them is that everybody is accountable. Scrum master, product owner, team members, uh, you know, they all are accountable for what they do. They all feel ownership and what they're delivering, uh, and when something goes wrong everybody chips in to make sure things happen right. So, they should all understand what their role is and act on that role. The second is that you're working in small sprints. Uh, if you're working in sprints that are a month long, two months long that's just too big. You need... you need to be organized around one or one to two weeks, two or four-week sprints. I don't like four weeks. I really like two-week sprints. Some people do one-week sprints. There's an ordered product backlog. This is key, right? If you go in and look at the backlog and it's not ordered you know things are in disarray and the stories don't have enough information for anybody to know what's going on. That's an indication that things aren't exactly healthy. Then, is there a sprint backlog, right? That you could visualize the remaining work. That's why we use a kanban board, right? So, we have these things in the backlog. We can look at them and very quickly and easily understand what is the work that's remaining in this sprint? What is the work that has has yet to be done? And then at sprint planning and forecast, a sprint backlog and a sprint are created. Teams should not be working without a backlog. Teams should not be pulling off the product backlog. You really want to organize around a goal for the sprint and all the stories for that sprint are in that sprint backlog. The results of the daily scrum results in planning work or replanning work so maybe, you know, something's not going as planned, you need to shuffle some stories, you need to add more people to a story. You need to get somebody help, uh, and maybe, you know, you replan as a result of that. So that's very, very important. No later than the end of the sprint, you've got it done increment, right? You don't want to have sprints where there's nothing to deliver. In the beginning, it's really hard to do this but once you get going there should be some new functionality that you're adding every two weeks that you can be, uh, you can demo and be accountable for. And then the stakeholder's offering feedback. I can't stress enough how critically important this is. The whole idea of delivering early and often is so that the stakeholders can look at it and they can offer you feedback and then you could decide whether you need to change the plan or change the product or change whatever direction you're going in. So that stakeholder feedback is very valuable. If you have sprint reviews and the stakeholders remain silent, not healthy. Not healthy. They really need to be speaking up and saying whether they like it don't like it, The product backlog is updated as a result of a sprint review, so when you do the review you may come up with new stories. You came up with new ideas, uh, you may decide that something should be implemented a little differently and so at the end of that review you go in and you add these new stories to the backlog, right? You want to take that feedback that the stakeholders giving you and add that to the sprint backlog so that becomes new stories that you could implement for your stakeholders. And then the product owner, the development team, the scrum master, they're all aligned on the work in process, right? So they know what's going to happen for their next sprint, uh at the sprint retrospective. You want to make sure everybody understands what went well, what didn't go well, what should we keep doing, what should we stop doing, and get alignment, so that in the next sprint, we do even better, right? We incrementally improve. In this video, you learned anti-patterns to avoid when practicing scrum, no real product owner, teams are too large, teams are not dedicated, teams are too geographically dispersed, teams are siloed, teams are not self-managing. The scrum health check provides guidelines for measuring a healthy scrum team.
