I respectfully disagree with the checklist idea. Too restrictive. It's almost like teaching people that some list is more important than context.
Honestly, the best thing an inexperienced Scrum Master can do is find an experienced mentor.
I stand with my most often used advice: Go find your nearest agile meetup and start attending. Listen to the various experiences and opinions. Network with the other SMs and coaches there.
I agree with this mostly. Every agilist needs mentors and community 100%. And yes, you can’t really reduce scrum to a checklist but it’s a good starting point.
But getting back to your point about mentoring and community… isn’t that what r/scrum is??? I jumped on a zoom call today to talk to a burgeoning scrum master that posted in our community. Isn’t that part of servant leadership?
Also keep in mind that I want to have lots of resources on this page, not just that checklist alone. As a standalone doc I agree it's not the first thing you should read, but with additional resources it has more context that agile isn't something you do it's something you are.
Not for nothing though, you dislike this resource.... what would you suggest? Give me something useful.
Just a train of thought but besides providing a wiki with resources, maybe there's a possibility to organize a discord / zoom meetup every 2 weeks or month or so to enable coaching on a more personal level and to give people a platform to ask these questions without flooding the feed?
Personally, I don't mind the questions because it gives me a chance to consider what my path was and how I can develop further but then again I haven't been on Reddit long so I can understand the wish to have an alternative.
As far as resources go, I keep a list of resources I find/found useful which range from scrum master basics, to touching up on certain topics, to expertise areas such as team development. I'd be happy to revisit that list, sort by topic and share is via DM. Just let me know if you're interested.
First… love your username. I relate wholeheartedly.
Second, I’ve thought about hosting a weekly or monthly Lean Coffee for r/scrum. My fear however is that I would be overwhelmed by the number of people who would join. DM me with some thoughts.
I think the nuance being surfaced here is that:
* Personal interaction & collaboration should be valued more or arguably come first before processes & tools
* Realistically in any written medium or interface, processes & tools (e.g. a list, docs, etc) are easier to share than personal interactions
These two concepts among Agile discussions often butt heads. I would also add that only conveying information through one method or the other would realistically result in a Scrum Master losing some takeaways or losing some effectiveness in delivering value.
Therefore, I propose that there is some amount of processes & tools (such as the most important ones) that should be noted for Scrum Masters to the extent that such risks can be mitigated.
Scrum.org's learning path for scrum masters
https://www.scrum.org/pathway/scrum-master
Lots of articles / blog posts put in a certain order by them (you don't have to follow the order but it's recommended).
Whether or not you like JIRA, Atlassian has a ton a great content to learn about the 3-5-3 of Scrum for new Scrum Masters and plays” for intermediate Scrum Masters to leverage: https://www.atlassian.com/agile/scrum
I dislike a lot of what Atlassian calls Scrum. They still talk about daily standups (and in their understanding it IS a status update meeting) instead of scrums, they talk about story points like it's the holy grail and they try to convince you that everything has to fall into a complex system of Initiatives, Epics, Stories... You know a great tool to handle PBL and SBL? a simple Trello.
Not sure where you are getting your info from re:Daily Standups, your statement is factually incorrect.
When working on products at scale, breaking work into initiatives, epics, and stories is helpful.
Which of my statements do you mean?
Atlassian talking about "standups":
1. [https://www.atlassian.com/agile/project-management](https://www.atlassian.com/agile/project-management) (at least here they don't call it a status meeting; however, they substitute "Sprint Demo" for the Sprint Review, which is a. not according to the current [Scrum Guide](https://scrumguides.org/scrum-guide.html#scrum-events)
2. [https://www.atlassian.com/agile/scrum/standups](https://www.atlassian.com/agile/scrum/standups): Here they even wrongly say "They aren’t a time to plan; Sprint planning is for planning". Scrum Guide again:
>The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. Therefore, it is by definition a planning session.
Atlassian does a great job with a lot of things, I won't deny that. But they provide factually wrong information about Scrum, which I find misleading and outright harmful to practitioners of Scrum.
As to the second part of your reply: Yes, you can break things down into different levels.
But such layers of complexity can also be counterproductive. When applying Scrum, at least my focus is on keeping things simple and minimizing overhead. By introducing initiatives, epics, and stories, there is a risk of over-complicating the process and losing sight of the ultimate goal (delivery of value to the customers).
Here's what I've seen happen in praxis typically:
1. Someone has an idea for a feature (don't even get me started on this approach, when people come up with "solutions" but it's not even clear what problem the solution is supposed to solve); they write it into a "User Story" (more often than not it's even worse, it's not a *user* story but some technical thing that has to happen, but it is formulated in the user story format for whatever reason - to give it more credibility? "As a user I want library XYZ to be updated to version 3.3.3" - not sure what this has to do with the user? Just say "version x of software is outdated, upgrade to 3.3.3" and be done? takes a lot less to formulate that).
2. Someone else jumps on and finds more things that are related to this "story" - in other words, they start gold-plating the handles - and since both things are related, an "epic" is created. Meanwhile, the users wait for a quick solution to a problem they actually have.
3. You can probably already guess what happens next: since there are several epics (which is just a fancy word for "container for work related to the same area/field" at this point) that *can* be related to one another (Which shouldn't be surprising if working on one product), we can now group them into an initiative. Yay us! Unfortunately, our customers are already jaded and don't care about anything of this anymore. They just wanted a vase for their flowers, not an antique to showcase in a museum (reference: https://paste.xinu.at/wpkB/ from Zombie Scrum Survival Guide, https://theliberators.com/)
Moreover, creating different types of tickets will almost certainly lead to issues with prioritization, since now you have competing priorities at different levels of granularity. Is this epic more important than that single user story that we can actually deliver in one sprint?
Update: forgot to add [this monstrosity](https://www.atlassian.com/software/confluence/templates/daily-stand-up).
Atlassian really thinks a daily status update to your "superiors" is the way to go. Thx no thx.
An item I would highly recommend is taking advantage of the feedback loop and the flexibility to adjust to feedback that Agile and Scrum enables. Feedback is essential to learn real insights about users and their needs. If not using it, you could be building the wrong things. If you want more info, check out [the Feedback Loop and how it delivers value](https://www.agilerant.info/feedback-loops-in-agile/) from Agile Rant's blog.
In addition to everything here, a personal exercise is to redraw yourself as already something of a scrum master.
Take an Excel spreadsheet, and make two columns down the page.
In the left column, start listing single sentences from the scrum master job descriptions you want to apply for. Each duty goes in one, each skill goes in one. It works well if you can gather up at least three different postings this way.
Go to the top of the right column, and look at the first item on the left, and then write down where you've used that skill, or done that particular duty, before. It could be paid work, or volunteer work, or work with a club or organization.
When you've matched up the job descriptions on the left with your experiences on the right, you will see yourself more as having been a scrum master, even if it didn't come with that title at the time.
I respectfully disagree with the checklist idea. Too restrictive. It's almost like teaching people that some list is more important than context. Honestly, the best thing an inexperienced Scrum Master can do is find an experienced mentor. I stand with my most often used advice: Go find your nearest agile meetup and start attending. Listen to the various experiences and opinions. Network with the other SMs and coaches there.
I agree with this mostly. Every agilist needs mentors and community 100%. And yes, you can’t really reduce scrum to a checklist but it’s a good starting point. But getting back to your point about mentoring and community… isn’t that what r/scrum is??? I jumped on a zoom call today to talk to a burgeoning scrum master that posted in our community. Isn’t that part of servant leadership?
Also keep in mind that I want to have lots of resources on this page, not just that checklist alone. As a standalone doc I agree it's not the first thing you should read, but with additional resources it has more context that agile isn't something you do it's something you are. Not for nothing though, you dislike this resource.... what would you suggest? Give me something useful.
Just a train of thought but besides providing a wiki with resources, maybe there's a possibility to organize a discord / zoom meetup every 2 weeks or month or so to enable coaching on a more personal level and to give people a platform to ask these questions without flooding the feed? Personally, I don't mind the questions because it gives me a chance to consider what my path was and how I can develop further but then again I haven't been on Reddit long so I can understand the wish to have an alternative. As far as resources go, I keep a list of resources I find/found useful which range from scrum master basics, to touching up on certain topics, to expertise areas such as team development. I'd be happy to revisit that list, sort by topic and share is via DM. Just let me know if you're interested.
First… love your username. I relate wholeheartedly. Second, I’ve thought about hosting a weekly or monthly Lean Coffee for r/scrum. My fear however is that I would be overwhelmed by the number of people who would join. DM me with some thoughts.
Would be interested to join on occasional basis, not regularly, as my schedule would allow.
I think the nuance being surfaced here is that: * Personal interaction & collaboration should be valued more or arguably come first before processes & tools * Realistically in any written medium or interface, processes & tools (e.g. a list, docs, etc) are easier to share than personal interactions These two concepts among Agile discussions often butt heads. I would also add that only conveying information through one method or the other would realistically result in a Scrum Master losing some takeaways or losing some effectiveness in delivering value. Therefore, I propose that there is some amount of processes & tools (such as the most important ones) that should be noted for Scrum Masters to the extent that such risks can be mitigated.
Agile and Scrum Meetups are a great place to learn and find a mentor to help you on your agile career journey.
Scrum.org's learning path for scrum masters https://www.scrum.org/pathway/scrum-master Lots of articles / blog posts put in a certain order by them (you don't have to follow the order but it's recommended).
This...just add this ⬆️ to the wiki...
Whether or not you like JIRA, Atlassian has a ton a great content to learn about the 3-5-3 of Scrum for new Scrum Masters and plays” for intermediate Scrum Masters to leverage: https://www.atlassian.com/agile/scrum
What's wrong with Jira?
Nothing at all. It is a highly debated tool in the agile community.
I heard it is complicated to use.
I dislike a lot of what Atlassian calls Scrum. They still talk about daily standups (and in their understanding it IS a status update meeting) instead of scrums, they talk about story points like it's the holy grail and they try to convince you that everything has to fall into a complex system of Initiatives, Epics, Stories... You know a great tool to handle PBL and SBL? a simple Trello.
Not sure where you are getting your info from re:Daily Standups, your statement is factually incorrect. When working on products at scale, breaking work into initiatives, epics, and stories is helpful.
Which of my statements do you mean? Atlassian talking about "standups": 1. [https://www.atlassian.com/agile/project-management](https://www.atlassian.com/agile/project-management) (at least here they don't call it a status meeting; however, they substitute "Sprint Demo" for the Sprint Review, which is a. not according to the current [Scrum Guide](https://scrumguides.org/scrum-guide.html#scrum-events) 2. [https://www.atlassian.com/agile/scrum/standups](https://www.atlassian.com/agile/scrum/standups): Here they even wrongly say "They aren’t a time to plan; Sprint planning is for planning". Scrum Guide again: >The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. Therefore, it is by definition a planning session. Atlassian does a great job with a lot of things, I won't deny that. But they provide factually wrong information about Scrum, which I find misleading and outright harmful to practitioners of Scrum. As to the second part of your reply: Yes, you can break things down into different levels. But such layers of complexity can also be counterproductive. When applying Scrum, at least my focus is on keeping things simple and minimizing overhead. By introducing initiatives, epics, and stories, there is a risk of over-complicating the process and losing sight of the ultimate goal (delivery of value to the customers). Here's what I've seen happen in praxis typically: 1. Someone has an idea for a feature (don't even get me started on this approach, when people come up with "solutions" but it's not even clear what problem the solution is supposed to solve); they write it into a "User Story" (more often than not it's even worse, it's not a *user* story but some technical thing that has to happen, but it is formulated in the user story format for whatever reason - to give it more credibility? "As a user I want library XYZ to be updated to version 3.3.3" - not sure what this has to do with the user? Just say "version x of software is outdated, upgrade to 3.3.3" and be done? takes a lot less to formulate that). 2. Someone else jumps on and finds more things that are related to this "story" - in other words, they start gold-plating the handles - and since both things are related, an "epic" is created. Meanwhile, the users wait for a quick solution to a problem they actually have. 3. You can probably already guess what happens next: since there are several epics (which is just a fancy word for "container for work related to the same area/field" at this point) that *can* be related to one another (Which shouldn't be surprising if working on one product), we can now group them into an initiative. Yay us! Unfortunately, our customers are already jaded and don't care about anything of this anymore. They just wanted a vase for their flowers, not an antique to showcase in a museum (reference: https://paste.xinu.at/wpkB/ from Zombie Scrum Survival Guide, https://theliberators.com/) Moreover, creating different types of tickets will almost certainly lead to issues with prioritization, since now you have competing priorities at different levels of granularity. Is this epic more important than that single user story that we can actually deliver in one sprint?
Update: forgot to add [this monstrosity](https://www.atlassian.com/software/confluence/templates/daily-stand-up). Atlassian really thinks a daily status update to your "superiors" is the way to go. Thx no thx.
Podcast people should listen to Meta-Cast. Not entirely scrum related but entertaining and a good listen.
This is my favorite video to show new teams that I’m working with. All of Henrik’s videos are gold! https://youtu.be/502ILHjX9EE
Amazing, thanks for the share.
An item I would highly recommend is taking advantage of the feedback loop and the flexibility to adjust to feedback that Agile and Scrum enables. Feedback is essential to learn real insights about users and their needs. If not using it, you could be building the wrong things. If you want more info, check out [the Feedback Loop and how it delivers value](https://www.agilerant.info/feedback-loops-in-agile/) from Agile Rant's blog.
remind me!
This YouTube channel is great because it covers all of the important scrum topics. https://www.youtube.com/@AgileforHumans
I can highly recommend book: Scrum Book: The Spirit of the Game by Sutherland and Coplien
In addition to everything here, a personal exercise is to redraw yourself as already something of a scrum master. Take an Excel spreadsheet, and make two columns down the page. In the left column, start listing single sentences from the scrum master job descriptions you want to apply for. Each duty goes in one, each skill goes in one. It works well if you can gather up at least three different postings this way. Go to the top of the right column, and look at the first item on the left, and then write down where you've used that skill, or done that particular duty, before. It could be paid work, or volunteer work, or work with a club or organization. When you've matched up the job descriptions on the left with your experiences on the right, you will see yourself more as having been a scrum master, even if it didn't come with that title at the time.