If I could go back in time and give my younger scrum master self only 10 tips, it would be this:
- Questions over statements. Use questions as a tool to enforce process, make a point, or to gain understanding of another point of view. It also makes for a less confrontational situation:
- Frank, instead of starting a new task, have you thought about helping Mary with that code review?
- Since our stand ups are only 15 minutes, should we talk about ways to get us all here on time?
- Progress should be defined by the amount of work finished, not the amount of work started. Task switching comes at a cost. This cost is often overlooked, especially in a world where multi-tasking is the norm. Teams often feel theyâre most efficient when they have a large number of tasks open so they can toggle between them. Theyâre mistaken.
- Knowledge creation over task completion. Even at the cost of efficiency, itâs better to spread knowledge throughout the team than to focus simply on completing all committed work. Encourage specialists to step outside their comfort zone and learn a skill from one of their team members.
- Ask stupid questions. If someone says something, and you donât understand, ask. I bet at least two other people in the room have the same question, but donât want to feel like a dummy.
- Know your team. Can you name the spouse, hobbies, strengths, and weaknesses of each of your team members? If so, great. If not, learn, but only do so if youâre sincere in your effort to know more about your team members.
- Know your teamâs dynamic. Itâs not enough to know each team member. Learn how their personalities mesh. Who feels safe sharing their thoughts? Whoâs more contemplative? What has occurred in the past to draw the entire team into a fruitful and honest discussion?
- The last 10% of any story is chock-full of unicorns and dodo birds. Never let a team convince you that something is 90% done. Itâs either all done or not done at all.
- Paint all things in terms of black or white. When your team uses terms like âmayâ or âmight,â ask them to commit to something firm (even if itâs less than their previous âmightâ). In a similar vein, ensure all action items have a clear and single owner. Use questions to get them through the shades of gray.
- Good enough never is. Never let a team feel that they have nothing more to learn. Never let a team become complacent. Always find ways to gently knock them off balance in the spirt of keeping things fresh and interesting.
- It never gets easier. The job requires a great deal of patience. Many days youâll question if youâre really doing enough for your teams. Thatâs normal. Youâre in a role where the value you provide a team is often intangible, yet always invaluable.
What would you tell your younger self? Iâd love to hear your tips for new scrum masters.
Update: A number of you enjoyed these tips so much that I put together another ten in my blog post Scrum Master Tips To Help Your Teams Succeed. I hope you check them out.
Do you want to get notified when new posts are published? Leave your email below.
Way cool! Some very valid points! I appreciate you penning this article and the
rest of the website is extremely good.
Thanks so much, Jona. Although I’ve written blogs internally, this is my first attempt of doing so for the rest of the world to see. If you have any tips yourself, I’d love to hear them.
These are great tips. I’m excited that you decided to start blogging. If you are looking for topics I’d love tips about getting better results from retrospectives. I struggle with just getting a lot of kudos and not getting the team to really dig into tough discussions that help them improve as often as I like.
Hey, Heather. Long time! Coincidentally, I was thinking about just this topic this morning on my way to work. It’s on my list of topics to cover. I have my own struggles with teams that have a great discussion at the retro, but then forget the areas they wanted to improve come next sprint. However, maybe the right angle for a blog around the retro is to focus on how to get teams to offer critical feedback. A future blog would cover tips for how to hold teams accountable to that feedback.
Learn to coach upwards and remember a dead ScrumMaster is a useless ScrumMaster.
Great tips! And one of my favorite Ken Schwaber quotes as well.
Yes that is how old I am I received my CSM via Ken S:) and I don’t think new CSMs are prepared for some of the battles and challenges they will have in organizations both adopting scrum and those who believe they have adopted scrum. You do have to be careful that your employer does not view you as the impediment and remove you.
Nice tips. In particular I like the emphasis on asking questions. When I first began as a ScrumMaster I had to get over my background as a tech lead and my natural style to be very directive and a cut-to-the-chase type of person. So in meetings, I would promise myself I’d ask more questions than I’d make statements.
On whatever piece of paper I had handy I would just note IIII then a slash through those for 5, etc. on the left side for questions and on the right for statements. I didn’t have to do it often. But it helped me stay focused on, as you say, “questions over statements.”
Nice job!
Mike, that’s an excellent way to keep yourself accountable. As a scrum master, I feel I’m good at practicing my own advice. As a manager, I’m often horrible at it. I’ll use this in my next one on one.
These are great tips. One topic that would be great to cover is how to slices stories and size them. That’s a struggle for almost every Development Team.
That’s a topic for a number of blogs. I’ll think through how to dissect such a heavy subject. Thanks for the idea!
Great tips that in retrospect would have been useful in my early days as a CSM. Most of these I now realize I learned over time, and could be very useful tools to get a new ScrumMaster started on the correct path. I am a firm believer in finding one’s way, and learning what works for the individual, however having proper stepping stones such as these tips will only help to seed new CSM’s more efficiently. Thank you for sharing.
Thanks for the wonderful feedback, Rante.
Cool stuff. I had felt the real essence of the words described in this blog. Thanks for carrying these thoughts and sharing it for the betterment of Agile Scrum group of audience.
My pleasure. And thanks so much for the kind words.
Thanks for sharing.
There is just one thing I disagree with and that is the examples of Questions over Statements. The ones you used are no real questions intended to receive an answer but rather rethorical ones, statements disguised as questions.
While it may be tempting to avoid conflict by wrapping requests in questions, this may undermine your and the team’s ability to communicate clearly and to learn to deal with differing opinions.
For me being a good scrum master is all about authenticity. And that means, making a statement when having something to state and asking questions only if I’m really insterested in the answer.
I don’t disagree, Thomas. I borrowed a play from the Agile Manifesto playbook:
“That is, while there is value in the items on the right, we value the items on the left more.”
There’s a place for statements, and I make them every day when I speak to the teams I work with. Over the years, I’ve found I’ve placed my foot firmly in my mouth usually when I feel I know the whole story. Usually I don’t. Questions ensure I approach the situation as if I don’t have all the details. In other words, I’m genuinely interested in their replies, and they’re not at all rhetorical.
Using my two examples, maybe Frank already did help out Mary with a code review. Or maybe something occurred to adjust the priority of our sprint backlog requiring Frank to start the new task earlier than anticipated. Arguably, I could have used a better example for my 2nd question. When I wrote it, I had in mind Silicon Valley commuter train delays and the horrid rush hour traffic as a likely reason for their tardiness. I hope you live somewhere where it’s not nearly as maddening. đ
Respect the Scrum events, donât miss any of them, Respect the scrum artifacts donât drop any of them, and push your team to optimize the process and their performance little by little sprint after sprint.
Inspire a team to never accepts good enough as good enough. Agreed.
11. Use judgment as a team. Perfect is the enemy of Done.
Great tip!
Pingback: Focussed Agile / Hans Samios Wiki
Hey,
Great pointers but pointers 2 & 7 stand out for me. Also I believe it’s more about the attitude rather than just the role of a scrum master which drives the project.
Thanks
Agreed. Attitude and perspective are sometimes our best tools.
Nice tips… especially i like “Knowledge creation over the task completion” … i have observed this delimma in many teams where they put less emphasis on knowledge share/creation and fall into the trap of giving tasks to experts for estimation and completion to gain some velocity… I put special attention on scrum artificats and events such as “backlog refinement” and rotate team members to prepare and give a “demo” to the stakeholders…
Most team members like to stay in their comfort zone. The most common argument is that they do so in order to best serve the team by doing what they’re best at. They argue that they’re being efficient by doing so. After all, why do something that someone else is better at? Don’t we want to get as much done as possible? They’re not wrong, but they’re not right either. Over time, I’ve come to believe that “efficient” is the longest four letter word I know.
Pingback: Hosk's Dynamic CRM Blog
Pingback: Hosk's Dynamic CRM Blog
Canât believe I havenât found you until now. I just landed on this when I was looking up a way to articulate my job to someone who isnât really privy to the idea of a Product Owner and a technical Project Manager being different roles.
Learning how people tick is a HUGE undertaking â Golden Rule is 100% relevant here. Spending time with each person talking about non-work directly related things is a part of the job. Spending time observing how they react to specific tasks being assigned and how they act when they feel stuck etc. are just a part of the observations that you will need to get familiar with.
Another biggie: Your job is making sure that others do their BEST job and that isnât always quantifiable directly. This makes it hard to talk about raises & bonusâ etc. but remember that your job is VERY important and if people are happy with progress and they donât think to thank you, thatâs their bad, not yours. Check in with your developers to see if there is anything that you could be doing that would make their lives easier & then immediately make that happen. They will be your biggest warriors. I make my devs feel like they are doing a favor when I ask them to do something, there is no better feeling then having them say âoh yeah totally, I got youâ it means youâve developed trust & that is not an easy feat.
đ
Thanks, Jamie. I’m glad you enjoyed it, and I completely agree with you. Those in the trenches–not the offices–are the heroes. We should always find ways to remind them how valued they are.