Thanks for the movie. Another common mistake that fits into what you've shown is being open to making mistakes. We often assume the role of people who know the answer to everything or should know it. We also want to protect the team from making mistakes
Absolutely! I gave a keynote talk at a conference a handful of years ago that was all about being willing to admit mistakes or that you don't know the answer to everything. I had everyone in the audience practice saying out loud, "I might be wrong." :) If you're interested, you can watch it for free here: www.mountaingoatsoftware.com/training/courses/let-go-of-knowing
Another mistake I see scrum masters make is allowing themselves to becomes the team admin. Whether it be recording notes from meetings to updating Jira tickets for the team because they do not do it.
Great one! This is a very unfortunate mistake. When Scrum Masters become viewed as team admins the organization will eventually view them as not very valuable. Thanks for commenting.
Hi Mike, thank you for this video. I would like to add one more to the list. Scrum masters allow a sprint review to be skipped because “they have nothing to show to stakeholders”. Sometimes because they failed to finish anything but sometimes because they are struggling how to present something technical (eg a new API end point)
1. Giving the team solutions 2. Telling the team what to do, rather than selling 3. Running the standup 4. Skipping daily scrum or retrospectives 5. Don't take the Scrum guide as gospel 6. Thinking everything is a user story 7. Letting work roll from one sprint to another.
Great video Mike. I started working with a new senior team and am facing the 3rd point. The team, based on its previous experience, believes that the daily scrum should be managed by the SM or TL. I had a one-on-one conversation with team members to explain the philosophy why it is more convenient for the team to manage the daily scrum and not just by one person, but some of them are still not convinced. For example, QA said it's up to the developers to run it, not us. and it's true what you said, I feel like the team gives me the status and I'm there to inspect them. so I lose the opportunity to be neutral and observe the team. I still run it, and i involve the members who convinced and continue to work with others. As for the other points, they are valid points. Thanks for sharing this
Thanks. It's unfortunate you can't get them to own the meeting and run it themselves. That was easier to fix by just staying silent when we all did them in person. Doing them on video and staying silent doesn't work as well because people just tune out and start doing email or such. Good luck.
hi Mike. I'd add to that list "not coming up with impactful actions during sprint retrospectives". It is easy for the team to become disengaged when actions from retros are not followed up or have low impact. Enough emphasis and time should be put during retrospectives towards coming up with good actions. Sadly this is the the mistake I've made in the past.
That’s a great one. Too many retrospectives end up with nothing actionable selected. After a few of such retrospectives team members give up on retrospectives.
I would add 2 more mistakes: 1. focusing only on the team, without trying to tackle problems at the organisational level. A ‘can't do’ approach limits the effectiveness of the team. 2. focusing on getting the sprint goal done and achieving the set PBIs, without caring for the continuous improvement of the team members and breaking down the competence silos between them. Sometimes we are afraid of lowering the velocity, without looking at the fact that a long-term increase in Bus Factor is much more beneficial.
I think a common mistake is thinking that we are there to protect the team from stakeholders. I would argue that we are there to minimize distractions and protect the sprint goal. But isolating the team from the rest of the business is more harmful than beneficial.
I don't think a team should be isolated from the business just like I don't think that the team shouldn't talk to stakeholders. But there are times where the Scrum Master needs to stop stakeholders from getting direct access to the team. When stakeholders act as a distraction to the team and stop them from achieving the spring goal the Scrum Master should step in to protect the team (and ultimately the sprint goal) from stakeholders. The team achieves the sprint goal. If you want to protect the sprint goal you have to protect the team.
Love the new videos Mike!! Letting work roll forward is an interesting one, I regularly try not to do this but it always happens. There is no work remaining and there are 2 days left until the end of sprint. There's work at the top of the backlog but these won't be done in 2 days. What should happen? Bring a story into the sprint and expect it to roll over? Work on it outside of the sprint? Pick a small task further down the back log with lower business value? Would love to hear your thoughts
Thanks for kind words and the suggestion. Yes, letting work roll forward every sprint is one of worst habits a team can get in. But what I don't like is when teams grab 8 product backlog items and get 5 done with the other 3 partially done. And then again next sprint and then again the sprint after and... That's a bad habit. As I understand it you're describing something very different: The team does great, finishes everything and rather than goof off, they grab a thing or two to work on. And with the limited amount of time left, they can't possibly always finish the thing added at the end. I don't think that's a problem at all. A lot of people have claimed things like "unfinished work is the root of all evil." I don't believe that at all. The problem is letting unfinished work accumulate. That shows up as a team doesn't finish testing so the coders start on something new at the end of the sprint instead of helping test. When that occurs sprint after sprint we're letting unfinished work pile up in front of the testers. That's bad. Grabbing something at the end, getting partially through it, and finishing it in the new sprint isn't bad at all.
Thanks, Mike, for the nice video you made. Some of the mistakes I used to make were skipping daily scrum and retros. Initially used to practice the Scrum guide as gospel. Not anymore :)
The Scrum Guide should be viewed as ... a guide, not as gospel. I'm glad you changed. Check my channel on Thursday, I'll have more to say about that in a new video in a few days. It's going to be a good one!
Another two major mistake based on my observation and inspection is : 1. SM is ignoring team feedback. 2. SM is failed to shield the team from outside disruptions during the sprint.
I would add Cargo Cult scrum to the list, basically on paper you are doing scrum and it's "ceremonies" but ignoring the underlying ethos of Agility. For example, micromanagement using JIRA.
Good point. Yes, it's important for team members to understand why they do various agile practices in order to get the full benefit of those practices.
Number 7 is too damn common. And the funny thing is that it is usually advocated by the higher ups. There are places where goals don't matter because everything comes in directly from the customers (or customer contacts) w/o much though or design. Teams are conditioned to deal as much request as possible within the release cycle. People working there for 4,5,10+ years have a truly hard time to understand complex problem space, what RnD is supposed to be about, EBM, etc. No to mention that most of the time they just ignore you, especially if you are a young lad who just started work there or been there for a few years. I tried to help people understand these concepts, but if they are not open and/or ignore studies and data, then I can't do much.
It's very common. I actually have a video on how to stop a rollover habit. But you're right that sometimes it's not the team, it's the culture of the organization. Here's the video: ruclips.net/video/55JMFOhOIMg/видео.html
@@MountainGoatSoftware Yes, I've seen this one. :) Good advice if the organization allows the teams to pull items. When teams work on topics like a conveyor belt and Sprints are just check up deadlines, then it is a totally different story.
Our team tends not to invite the relevant stakeholders to the sprint review. I can tell them till I'm blue in the face that this an opportunity to get stakeholder feedback and to help us adapt for the next sprint. But now it just feels like I'm screaming in to the void. I often wonder if I should just request to leave the team since I cannot seem to sell the idea to them. We also have carryover every. Single. Sprint. No amount of explaining that we need to slow down goes particularly well. I'm fairly certain this all comes down to the cultural aspects within the organisation, and it's deeply frustrating when anything I say goes unheard.
That's a very challenging situation to be in. You might be able to shift your team's view on the Sprint Review by highlighting specific instances where stakeholder feedback led to important pivots or improvements in other projects. Carrying over work each and every sprint could stem from a lot of different things. Underestimating tasks, not fully understanding stakeholder needs, or just constantly overcommitting. It sounds like you've had conversations with your team encouraging them that they need to slow down a bit in order to ultimately speed up later on. It might be helpful to step in during Sprint Planning and encourage the team to commit to a very low number of stories. If they normally bring in 50 points worth of work, only bring in 25 points one sprint. If there's still carry-over drop that down to 10 points. The goal is to finish what we commit to so that we can build predictability and trust with our stakeholders.
@@MountainGoatSoftware thank you so much for your response. I had a look at a few more of your videos and managed to sell the team on committing to significantly less during our sprint planning today. Let's see how it goes 😁
@@hellglazer Great news. It's really good to break the habit of constant overcommitting. Please come back at the end of the sprint and let us all know how it went. Good luck and thanks!
@@MountainGoatSoftware well we eventually managed to deliver what was committed to😁 now we're needing to think about pulling extra work. But not quite yet. I want to make sure we're not purposely under committing now 🤣
I love that--I very much what product owners to attend the daily scrum. I'm not a big fan of special rules and if we say "you have to go to this daily meeting, but you don't" that really works against the idea of them all being a team.
Thanks for the movie. Another common mistake that fits into what you've shown is being open to making mistakes. We often assume the role of people who know the answer to everything or should know it. We also want to protect the team from making mistakes
Absolutely! I gave a keynote talk at a conference a handful of years ago that was all about being willing to admit mistakes or that you don't know the answer to everything. I had everyone in the audience practice saying out loud, "I might be wrong." :) If you're interested, you can watch it for free here: www.mountaingoatsoftware.com/training/courses/let-go-of-knowing
Another mistake I see scrum masters make is allowing themselves to becomes the team admin. Whether it be recording notes from meetings to updating Jira tickets for the team because they do not do it.
Great one! This is a very unfortunate mistake. When Scrum Masters become viewed as team admins the organization will eventually view them as not very valuable. Thanks for commenting.
Hi Mike, thank you for this video. I would like to add one more to the list. Scrum masters allow a sprint review to be skipped because “they have nothing to show to stakeholders”. Sometimes because they failed to finish anything but sometimes because they are struggling how to present something technical (eg a new API end point)
That's a great addition. Thanks!
1. Giving the team solutions
2. Telling the team what to do, rather than selling
3. Running the standup
4. Skipping daily scrum or retrospectives
5. Don't take the Scrum guide as gospel
6. Thinking everything is a user story
7. Letting work roll from one sprint to another.
Great video Mike.
I started working with a new senior team and am facing the 3rd point.
The team, based on its previous experience, believes that the daily scrum should be managed by the SM or TL.
I had a one-on-one conversation with team members to explain the philosophy why it is more convenient for the team to manage the daily scrum and not just by one person, but some of them are still not convinced.
For example, QA said it's up to the developers to run it, not us.
and it's true what you said, I feel like the team gives me the status and I'm there to inspect them.
so I lose the opportunity to be neutral and observe the team.
I still run it, and i involve the members who convinced and continue to work with others.
As for the other points, they are valid points.
Thanks for sharing this
Thanks. It's unfortunate you can't get them to own the meeting and run it themselves. That was easier to fix by just staying silent when we all did them in person. Doing them on video and staying silent doesn't work as well because people just tune out and start doing email or such. Good luck.
hi Mike. I'd add to that list "not coming up with impactful actions during sprint retrospectives". It is easy for the team to become disengaged when actions from retros are not followed up or have low impact. Enough emphasis and time should be put during retrospectives towards coming up with good actions. Sadly this is the the mistake I've made in the past.
That’s a great one. Too many retrospectives end up with nothing actionable selected. After a few of such retrospectives team members give up on retrospectives.
I would add 2 more mistakes:
1. focusing only on the team, without trying to tackle problems at the organisational level. A ‘can't do’ approach limits the effectiveness of the team.
2. focusing on getting the sprint goal done and achieving the set PBIs, without caring for the continuous improvement of the team members and breaking down the competence silos between them. Sometimes we are afraid of lowering the velocity, without looking at the fact that a long-term increase in Bus Factor is much more beneficial.
Excellent additions. Thanks!
I think a common mistake is thinking that we are there to protect the team from stakeholders. I would argue that we are there to minimize distractions and protect the sprint goal. But isolating the team from the rest of the business is more harmful than beneficial.
I don't think a team should be isolated from the business just like I don't think that the team shouldn't talk to stakeholders. But there are times where the Scrum Master needs to stop stakeholders from getting direct access to the team. When stakeholders act as a distraction to the team and stop them from achieving the spring goal the Scrum Master should step in to protect the team (and ultimately the sprint goal) from stakeholders. The team achieves the sprint goal. If you want to protect the sprint goal you have to protect the team.
@@MountainGoatSoftware I completely agree
Love the new videos Mike!! Letting work roll forward is an interesting one, I regularly try not to do this but it always happens. There is no work remaining and there are 2 days left until the end of sprint. There's work at the top of the backlog but these won't be done in 2 days. What should happen? Bring a story into the sprint and expect it to roll over? Work on it outside of the sprint? Pick a small task further down the back log with lower business value? Would love to hear your thoughts
Thanks for kind words and the suggestion. Yes, letting work roll forward every sprint is one of worst habits a team can get in. But what I don't like is when teams grab 8 product backlog items and get 5 done with the other 3 partially done. And then again next sprint and then again the sprint after and... That's a bad habit.
As I understand it you're describing something very different: The team does great, finishes everything and rather than goof off, they grab a thing or two to work on. And with the limited amount of time left, they can't possibly always finish the thing added at the end.
I don't think that's a problem at all. A lot of people have claimed things like "unfinished work is the root of all evil." I don't believe that at all. The problem is letting unfinished work accumulate. That shows up as a team doesn't finish testing so the coders start on something new at the end of the sprint instead of helping test. When that occurs sprint after sprint we're letting unfinished work pile up in front of the testers. That's bad. Grabbing something at the end, getting partially through it, and finishing it in the new sprint isn't bad at all.
Thanks, Mike, for the nice video you made. Some of the mistakes I used to make were skipping daily scrum and retros. Initially used to practice the Scrum guide as gospel. Not anymore :)
The Scrum Guide should be viewed as ... a guide, not as gospel. I'm glad you changed. Check my channel on Thursday, I'll have more to say about that in a new video in a few days. It's going to be a good one!
Another two major mistake based on my observation and inspection is :
1. SM is ignoring team feedback.
2. SM is failed to shield the team from outside disruptions during the sprint.
Yikes! They might need a bit of a refresher on their role.
I would add Cargo Cult scrum to the list, basically on paper you are doing scrum and it's "ceremonies" but ignoring the underlying ethos of Agility. For example, micromanagement using JIRA.
Good point. Yes, it's important for team members to understand why they do various agile practices in order to get the full benefit of those practices.
Number 7 is too damn common. And the funny thing is that it is usually advocated by the higher ups. There are places where goals don't matter because everything comes in directly from the customers (or customer contacts) w/o much though or design. Teams are conditioned to deal as much request as possible within the release cycle. People working there for 4,5,10+ years have a truly hard time to understand complex problem space, what RnD is supposed to be about, EBM, etc. No to mention that most of the time they just ignore you, especially if you are a young lad who just started work there or been there for a few years.
I tried to help people understand these concepts, but if they are not open and/or ignore studies and data, then I can't do much.
It's very common. I actually have a video on how to stop a rollover habit. But you're right that sometimes it's not the team, it's the culture of the organization.
Here's the video:
ruclips.net/video/55JMFOhOIMg/видео.html
@@MountainGoatSoftware Yes, I've seen this one. :) Good advice if the organization allows the teams to pull items. When teams work on topics like a conveyor belt and Sprints are just check up deadlines, then it is a totally different story.
Our team tends not to invite the relevant stakeholders to the sprint review. I can tell them till I'm blue in the face that this an opportunity to get stakeholder feedback and to help us adapt for the next sprint. But now it just feels like I'm screaming in to the void. I often wonder if I should just request to leave the team since I cannot seem to sell the idea to them. We also have carryover every. Single. Sprint. No amount of explaining that we need to slow down goes particularly well. I'm fairly certain this all comes down to the cultural aspects within the organisation, and it's deeply frustrating when anything I say goes unheard.
That's a very challenging situation to be in. You might be able to shift your team's view on the Sprint Review by highlighting specific instances where stakeholder feedback led to important pivots or improvements in other projects.
Carrying over work each and every sprint could stem from a lot of different things. Underestimating tasks, not fully understanding stakeholder needs, or just constantly overcommitting. It sounds like you've had conversations with your team encouraging them that they need to slow down a bit in order to ultimately speed up later on. It might be helpful to step in during Sprint Planning and encourage the team to commit to a very low number of stories. If they normally bring in 50 points worth of work, only bring in 25 points one sprint. If there's still carry-over drop that down to 10 points. The goal is to finish what we commit to so that we can build predictability and trust with our stakeholders.
@@MountainGoatSoftware thank you so much for your response. I had a look at a few more of your videos and managed to sell the team on committing to significantly less during our sprint planning today. Let's see how it goes 😁
@@hellglazer Great news. It's really good to break the habit of constant overcommitting. Please come back at the end of the sprint and let us all know how it went. Good luck and thanks!
@@MountainGoatSoftware well we eventually managed to deliver what was committed to😁 now we're needing to think about pulling extra work. But not quite yet. I want to make sure we're not purposely under committing now 🤣
@@hellglazer That's great. Thanks for coming back to let me know.
What do you think when the team Invites PO to attend daily Scrum? Is it a good thing to do?
I love that--I very much what product owners to attend the daily scrum. I'm not a big fan of special rules and if we say "you have to go to this daily meeting, but you don't" that really works against the idea of them all being a team.
Acting as a liaison for the team to any stakeholders instead of empowering and encouraging ownership by the tean
Good addition! Thanks.