The role of Scrum Master is a debate that has been been raging for over a decade. It is hugely misunderstood term and abused all over the world.
I am grateful that this term crossed my life. If it wasn’t for this term “Scrum Master” I would never have truly learned what being a coach means, and how much difference it can make to a team.
Think back to the best manager you ever had. What did they do differently to your other managers? Mostly, when I ask this question, the answers are about listening, understanding, caring and helping. So very few managers take the time to do this. And very few have the time to do this with all their other responsibilities.
Think about a school sports team (maybe soccer or football). They usually have a part-time coach that they work with a few times a week. And they improve slowly. Now think of a national soccer or football team. They usually have a team of coaches working with them on every tiny aspect of what they are doing and how they work together. The coach doesn’t run onto the field to help the team win a match. Instead they observe, make notes, adjust training plans – all to make the next match more successful and to help that team become the best they can be.
The same goes for a team coach. If they are part time whilst having another job, then you are at the school level and you will see small improvements. If they have a few years coaching experience and they are full time, your team will flourish.
Over the last 10 years we have run this following experiment at many companies, large and small.
We explain the Scrum Master role, and ask for a volunteer who would like to try the role for 6 weeks (3 sprints). For those 6 weeks, being a Scrum Master is their full time job, they need to give up their previous job responsibilities (whatever it was) for this 6 week period. It doesn’t mean they can’t share knowledge and pair with others, but their primary responsibility becomes being the team’s coach.
Over that 6 weeks, we work closely with these Scrum Masters, mentoring and coaching them. Often we use the pattern where we take lead for the first sprint, and they observe, For the second sprint we pair with them and work together, and in the third sprint they lead and we observe. We have created a range of training material for new Scrum Masters to help them on this journey. A big part of their role for the 6 weeks is their own learning through following this material, and being coached by us. This material is a good starting point, but having someone experienced to learn from is an accelerated learning experience.
Every time we have done this experiment, within 6 weeks, the team is delivering more in 2 weeks than they even thought possible. In one case we had a team complete all the work they had scheduled for the next 6 months within 6 weeks! Everyone in the team can see the value of a full time Scrum Master, and understands the value of the role. Sometimes the person who volunteered for the role, decides it’s not for them, but whenever that has happened there has been someone else in the team who is eager to try the role, and ends up being their Scrum Master. The increase in productivity and morale of the whole team from a full time Scrum Master, more than covers the salary of an extra person being a Scrum Master.
Consider the following. Assume you have a Team of 5 people all earning $100 per sprint. The total team cost is $500, and their productivity (assuming you could measure it accurately) is X. Remove one person from that team to be a full time Scrum Master. The team still costs $500, but only 4 people are “doing the work”. The other person is focused on helping those 4 people become more productive. Each team member only has to be 25% more productive for the output of 4 people to be equivalent to the output of 5 people.
Now imagine you had someone who’s sole job was improving productivity, and removing things that slow you own. How much do you think they could improve your productivity? What if all your meetings started on time, and were well facilitated? What if information was freely available? What if external dependencies were removed? What is access to customers exactly when you needed them was available? What if every time you had a questions about if you should do x or y, you could get an answer within 5 minutes? What if whenever you were stuck there was someone to talk to to get you unstuck? How much more productive would you be? 25%? 50%? More?
Now, someone new to a coaching/Scrum Master role might not be able to do all these things in 6 weeks, because they are learning and don’t have the experience. But, in 2 years time, this will be the level they are at.
So when I hear that people can’t afford a full time Scrum Master I think to myself, you can’t afford to increase in productivity? If you don’t want to try the experiment above, you can do it another way. Hire an experienced coach or Scrum Master for a short trial. Take the same team that costs $500 per sprint. Add a Scrum Master that costs $100 per sprint. Your costs just went up 20%. It should be simple to tell if the team delivers 20% more value over a short period like 3 months. (Big caveat about being careful to measure value not some proxy of value that can be easily gamed like velocity! But then any decent Scrum Master can show you how to do that.)
What do have to lose? 20% of your team cost for 3 months? What’s the potential upside? A massive productivity and improvement in value delivered? Is this something you can afford NOT to try?
P.S. If you want more details on a team doing the experiment of having 1 team member become a Full Time Scrum Master, be sure to read our Guest Blog Series by Jamie Sands.
P.S.S If you would like to find out more about being a Scrum Master, use our Scrum Master workbook – it will take you on a 15 week journey to understand the role.
Here I was, full time scrum mastering! There was time to plan mindful retrospectives targeted on what the team needed, it was total bliss. I’d been learning so much and this was an obvious way to put my learnings into practice and experiment with some new things.
Here’s a couple of case studies of retrospectives I facilitated and why I targeted them the way I did.
How to say no:
I was reading and learning about team impediments. It was tough to bubble something up because my team works well together, there’s a high level of trust. Then something occurred to me… Were we very polite? Too polite to say anything? What if they didn’t feel safe about disagreeing with each other? Or weren’t comfortable speaking up if they didn’t like what our product owner was saying?
In my last job before I joined the tech industry, I was a librarian. I did preschool story times, primary school class visits and outreach to kindergartens. I remembered a book I loved reading to the kids: A picture book called Don’t Let the Pigeon Drive the Bus by Mo Willems.
It’s a book where a bus driver asks the reader to look after his bus while he goes on break. You have to make sure the pigeon doesn’t drive the bus. The pigeon immediately appears and asks to drive the bus. The reader has to say no to him. There’s no response printed in the book, only the pigeon’s arguments. It’s a great book for little kids because they all get to shout ‘no!’ at the book.
I used this book as an ice breaker at a retro with my squad. I got them to gather up in front of me so they could all see the pictures. I told them that this wasn’t an ordinary picture book. They’d need to interact with it, out loud.
It went down beautifully.
After shouting no at a pigeon the team felt energised, laughing. We went into a ‘what’s holding us back, what’s powering us forward?’ exercise and lots of stickies went up on the poster. People raised issues, complaints, but positive things as well. It was a very productive session.
At the end of the retro I read the book again. This time I asked the team to think of the pigeon as some imagined higher up. Someone getting in our way or pushing us to do things we didn’t want to do. The feedback was even better that time.
It was a release, they all got practice saying no and had a laugh in the process. I never underestimate the power of laughter. It brings a team together, it releases good, bonding chemicals in your brain and lets go of tension.
Teambuilding and Trust:
Everything I’ve been learning has been telling me that having a team who delivers fast and works well together, the team has to trust each other. Everything I’ve learned about how to build trust is that people have to know each other, have common ground. With this in mind I ran a retro on getting to know each other better. Shawn Achor’s talk on the Happy Secret to Better Work is a great reference point for this.
This retro was a two squad one, so bigger than normal. It included people who don’t work with each other, day to day. So to get to know each other better we’d want to go quite deep. I went searching for an article I’d read when it first came out in the New York times. It’s about the 36 questions which make people fall in love.
The idea is if you sit down with someone and ask them all 36 questions, by the end you will love them. That was a good place to start, right? I wrote some of these questions onto index cards, although not the intimate ones. I found some other, more generic get to know you questions as well and added those to cards.
Everyone in the team paired up and took some index cards. We spent about ten minutes asking each other questions and talking about the answers. Then each of us shared something we’d learned about our partner. It was exciting to see people finding common ground, and we learnt new things about each other.
My partner is a primary school teacher. When I mentioned to her that I wanted to do something to encourage more trust in the team. She suggested Bucket Filling. This is another idea from a picture book, Have you filled a bucket today? by Carol McCloud. I didn’t read the book for this one, instead I got everyone to draw a bucket on an A4 piece of paper and explained the idea. Everyone carries an invisible bucket with them, and it’s to hold their happy thoughts and good feelings. You can fill someone else’s bucket by giving them a compliment, or acting kindly, or doing a favour for them, or by thanking them. You also fill your own bucket by doing this, because making someone else happy makes you happy too. You empty a bucket by being mean, ignoring someone or generally acting unkindly.
We filled each other’s bucket with compliments written on sticky notes. I gave the team five minutes to fill buckets and read what people had put in their own one. It was smiles all round, and my team made sure that everyone had buckets which were at least three quarters full.
I handed out small plastic bowls and plain white stickers. They selected a bowl they liked the colour of, and labelled them with their names. This was the bucket for their desk. I set up a vase filled with pom poms (or warm fuzzies, if you’re feeling cheesy) in the middle of our squad room. If the team are feeling grateful for someone, happy with something they did, or want to express your appreciation you can pick up a pom pom and deposit it into their bowl. You don’t have to explain why, but you can. You don’t even have to do it while they’re there.
My team love their buckets.
Here’s some examples of when people have given pom poms:
I missed you while you were away
You had a hard day, I appreciate your efforts
I’m grateful for the talk we just had
You made me laugh
You did something really frustrating and I sympathise
“Let’s all fill her bowl, because she’s had a horrible week”
It’s a small thing, but seeing your bowl fill up because other people are grateful for you is a wonderful feeling.
We started it as a one week trial, and at the end of the week there was a unanimous vote to keep the pom poms and the bowls. It’s been almost two months and we’re still going. At some point the bowls need to be reset, and everyone puts their pom poms back into the central vase, but no one wants to. I even had one team member clutch their bowl and exclaim “No! I need my bucket to be full!”
I know that this whole exercise sounds very touchy feely and a little over the top. I don’t think you could do it in a team where there’d been internal conflict. But then again, maybe it’d be most valuable in a team like that, as a way to start some supportive behaviours. I’d love to try it out with a brand new team and see how it goes.
I did have someone outside of work question if ‘the men’ were putting up with this bucket filling exercise. After rolling my eyes I related how the guys in my team are just as into it as the women. The fact that you don’t have to explain why is possibly a factor, but honestly? Shouldn’t we be giving everyone in the team a place to express gratitude and appreciation regardless of gender? I think so. We all need reassurance, and appreciation in the workplace is a wonderful thing.
Write postcards of appreciation to each other, deliver them to the person’s desk after the meeting.
Our own custom ‘cards against humanity’ game (you can find print your own and blank cards here.
The board game “Codewords” (great for highlighting communication styles, problem solving, negative testing)
The 16 Personalities quiz and discussion of different personality strengths, weaknesses and traits
Thinking carefully about the desired outcome of a retro isn’t exactly a new idea. But having time to think deeply and consider the purpose of what you do in retros has benefits. My reading a picture book in a retro gave our team an outside the box moment which allowed us to talk about challenging things.
Fun things are important for team building, but they also loosen people up a little. It sparks the neurons and allows easier communication. If the team is speaking freely then it’s easier to get to the heart of things and find meaningful ways to improve.
Having the time and freedom to experiment has also sparked my brain, and I have two pages of ideas which I’d like to try out with my team. If they don’t work, that’s okay, because I still will have learned something. If they do work, I might just find something magical happens in the retro.
One of the biggest questions about this experiment has been ‘who’s doing the testing?’ I, as a full time tester, quit that to be the scrum master, right? And we only had the one tester on our squad. I don’t recommend dropping your tester in favour of a scrum master, a tester is a vital part of the team and they have experience, training and knowledge that you can’t just spread over the team. In this case, it just happened to be a tester who wanted to try out being a scrum master, and after the experiment we’re hoping to have a full time tester again to ensure testing is valued, executed to a high quality and to write and maintain automation.
The quality and speed of our testing wasn’t going to suffer over the experiment, this was a mission I gave myself. Since the testing would be spread between our designer and our developers it was up to me to ensure they knew what they were doing.
I ran a couple of ‘test 101’ sessions with the squad. I covered basics which would get them testing quickly:
Context driven testing
Basics of how to write a test plan
Happy path testing
Keeping scope small ( linked to CDT)
Recording what you’ve done
I ran the sessions informally, just two people and me. We had some paper to draw things on, such as happy path flow charts or mind maps. I brought my laptop to show previous test plans to refer to, or show off our tools and processes. It was interactive, in all sessions there were lots of questions and answers. Often the questions would bring up an opportunity for insight into another facet of testing I hadn’t considered. We covered whatever came up, and kept it under an hour.
Here are the benefits of minimal, up-front coaching:
Fast start, can pick up test cases right away
They can find gaps themselves
They come to me with random questions as they come up
New learning as it’s relevant
You learn better from doing
Less pressure to be perfect right away
When cases came up to be tested, I paired with whoever was doing the testing. Letting them ‘drive’ the mouse and the computer, and offering tips as they went through it. I buddied people through deploys. The highlight was buddying a developer leading a group deploy and three other members of the team were watching the process. It was great for increasing interaction and teamwork! The whole team got involved in deploying a change, it made it quite exciting.
The team dove into testing with me reviewing their test plans and giving advice. I paired up with them when they needed it, made myself available to answer questions and share blog posts and information as it came up.
We ran into some issues initially:
Access to various aspects of the database and test tools was restricted by the business. It wasn’t too much of a problem for our developers but our designer was locked out of some of the processes. We had to raise issues with our IT helpdesk and then wait for the request to get to the top of the queue.
Our designer was excited to learn how to test and also didn’t happen to have too much else on, so she dived into it. There was a temptation from the developers then to keep on developing and give the testing to the designer. This was the opposite of what I wanted, because it took our designer away from her design work and it put a lot of pressure on her.
We got around this by reminding everyone to test things in daily stand up, and by introducing a Work In Progress limit to our ‘doing’ column. That way if someone wanted to start something new into the sprint, they had to first test something that was already developed and ready for test.
As a follow up to the test 101 sessions I’d run, I assigned ‘homework’. I pulled stories from our backlog which had good acceptance criteria and gave them to people to write test plans for. They had no time pressure because these were stories which weren’t immediately going to be brought into the sprints. I encouraged them to team up to write the test plans, and to ask any questions they had. Then when they were happy with them, they flicked them back to me to ‘mark’. It was a lot of fun!
The first thing I had to do to prepare for this full time scrum master role was learn the crap out of it.
Let’s be clear on something: I love to learn. I studied English literature, psychology and women’s studies in university. I love to learn about the way humans think, what motivates us, and if I learn something about myself along the way, that’s even better. This part of the process was a joy to me, which is great because when something’s a joy you work harder and get more out of it.
I had a couple of questions:
What is agile?
Why do we use it?
What is the purpose of a scrum master?
What should I be doing every day?
I went through the training courses here on Growing Agile. Starting with the exploration of Agile’s foundation tenets, and why it’s useful. Then I started the Advanced Scrum Master training courses. (Which are amazing by the way *not sponsored content). I especially loved the ‘becoming a servant leader’ one. Start with Basics of Scrum
I read the executive summary of a book called The First 90 Days by Michael D. Watkins. It had insight into ways to be effective in my new role.
My main takeaways were:
Learn as much as possible
Consider my vulnerabilities
Look for the unexploited opportunities for growth
Find early wins
I also checked in with a few people. I had a one on one with the head of agile for our office. I asked him: If you had all the time in the world to do scrum master tasks, what would your priorities be?
His suggestions were:
Velocity reporting: to show that having a full time scrum master is worthwhile
Work on facilitation skills
Reporting back on the experiment happens at many levels: to the company, to the squad, to the agile guild
Ensure retros are productive
Record cycle times: this way you can streamline your grooming process. The ideal being all the stories are the same size.
His ultimate message to me though was to fix things from the bottom, then work up.
I chatted with scrum masters throughout the office (people working the role part time alongside their regular jobs). I talked through some challenges they were seeing. I sat in on other teams’ daily stand ups, groomings and sprint plannings, making notes to myself on what worked and what didn’t. Where it felt like people were empowered to speak and when it felt stilted.
I also agreed to a lot of things. Someone came to me at 12.10pm, as I was thinking of having lunch and asked me to run a retro for his guild. The retro was at 1pm. I said sure and I facilitated a retro for a guild I wasn’t involved in, bubbling up a lot of problems and some possible solutions.
I ran a meeting for brainstorming ideas and solutions for the sales and operations side of my business unit. Drilling into the many personas that they use for marketing and thinking up new ways of using them. I agreed to be observed during this session and had an in depth one on one afterwards about how it went.
I co-facilitated a squad kick off and an agile clinic, and I did a talk to the test guild about the whole experiment.
In short, I took any opportunity I could to learn, and to get feedback on how to improve. I had to work at this, it’s hard to be vulnerable and take criticism. It’s hard to put yourself out there. But I needed to it, so that I could grow and improve.
Then, of course, there were blog posts and Ted talks, which I made copious notes on. Those all led me to other blog posts, other Ted talks and more learnings. I’ll link a few of my favourites below, but first I’ll wrap up. In some ways it felt like I was getting away with something, to spend work time learning. Especially when I was watching Ted talks. But the fact is, it’s very effective way to learn and I got some real insights. The great thing was when I noticed the same messages and conclusions coming up over and over again. I can recognise that something failed in a meeting I facilitated because I’ve read about meetings so much. I can see when people need help because I’ve watched talks about vulnerabilities or uninspired workers. Knowing that I have those skills is invaluable.
My learning all this stuff about processes means I can apply it to my team. They don’t have to study for hours, because I’ve done it for them. They can get on with their jobs and I can work on making the things around them more efficient, and encourage better team dynamics.
Learning is awesome, do it more!
Here’s some of the highlights. I’m sure there’s a bunch of great ones I’ve missed as well, share your favourites in the comments maybe?
I’m a tester in a small delivery squad at Trade Me. Karen joined our team four months ago as a Product Delivery Manager and in this role she’s the person I report to. She was confused about Trade Me’s lack of dedicated scrum masters. Together we started an experiment to change things. This is the first in a series of blogs documenting one person’s deep dive into an agile experiment.
What was the challenge ?
I’d expressed interest in leadership and agile practises before. But as a tester in a busy squad, I was usually bogged down with the day to day testing work and ended up being a tester who sometimes ran meetings.
One day at our regular one on one catch up, Karen suggested I trial being a full time scrum master for six weeks.
This was confusing, because it wasn’t something I’d ever heard of anyone doing at Trade Me before. The idea was intriguing, but I didn’t know if she’d be allowed to try it. That I’d be allowed to try it. I didn’t understand how or if it would work. Karen, of course, has done this before, and knew that it was generally beneficial.
I was into the idea, but to make it happen we needed a few key things:
Support from the delivery team
Make sure test practices as established at Trade Me aren’t ignored
Support from the wider test guild
Courage to take it seriously
Support from the delivery team
I’m a senior tester, and the only tester on the team. If I switch roles the rest of the team had to be willing to take over the testing.
To find out if this was something they’d be keen on we floated the idea at a team retro. I’m lucky that this team is a high trust one. They’re supportive of people following their passions and trying new things.
We agreed that everyone would do a little testing. I’d be around to coach, guide and give support but that I wouldn’t do any testing on my own.
Make sure test practices as established at Trade Me aren’t ignored
In the past test practices at Trade Me has been locked down. Only testers were allowed to deploy things, for example. But in the last few years things have relaxed. I checked in with the Head of Test Practices to ensure that we wouldn’t be stepping on any toes. He was fine with it. “As long as someone is there for deploys, it doesn’t matter who.”
I made it a mission to ensure that the team understood the wider context of Trade Me testing. With particular focus on security, risk and quality of the code we were delivering.
Support from the wider test guild
Trade Me has a ‘two weeks in testing’ meeting. A representative from test in each business unit is present. The agenda is open anyone can add anything new or interesting and spend a couple of minutes talking about it. One my first day as a full time scrum master I went to this meeting and told everyone about the experiment.
“So you’ll all understand if you see some unfamiliar names in deploy chats or in test environments,” I said.
“What names should we be looking for?” A tester in another office asked. “In case they need help and we can give them some extra support.”
You know that bit in the Grinch Who Stole Christmas where the Grinch’s heart grows three sizes? That’s how I felt. Not only were the wider test team okay with the idea that my team would be testing, they wanted to support them. It was a huge vote of confidence.
My main guideline was to stop testing. To resist the urge to take a case here or there, and to step back and let the team work.
I would learn as much as I could about processes, scrum, team building and how to make a team successful.
I also wanted to make my progress visible by highlighting new processes and ideas to the team.
Courage to take it seriously
This was a personal challenge for me. I’d been a scrum master before, but only alongside also being a tester. It was hard to find time to explore what I could do as a scrum master, and I’d end up being a tester who sometimes ran some meetings.
To get the most out of the experiment, I had to take it seriously. Learn all I could and throw myself into the role.
To start with, I decided to journal the process. Every day I’d write some reflections on how the day had gone, what I’d learned and how I was feeling. This was a commitment to myself to do my best. It would also be useful when reporting back to the team, my boss and the company on how the experiment had gone.
Adding a scrum master swim lane to our team board helped me be accountable with what I was doing. It helped my clarify my to do list, and it let the team know what I was busy with.
I also tried to say yes more.
When asked to do a retro for another guild with less than an hour’s notice, I said yes. When the opportunity to facilitate a squad kick off for a team in another business unit came up, I said yes. I took the opportunity to be observed running a meeting so I could learn where my weaknesses were.
With my various ducks lined up, I dived into the experiment and became a full time scrum master.
I’ve got a series of blog posts about the challenges, learnings and surprises I encountered, so stay tuned!
We all know the benefits of teams. A bunch of people who work together over long periods of time and are fairly stable. They grow together and learn together and the team is worth more than the sum of the individuals. IF you’ve worked in one of these teams – you will know what I’m speaking about. It feels amazing.
However in most companies this idea of stable teams seems like an impossibility. People (often referred to as resources) are shifted all over like chess pieces not allowing time for the goodness of teams to grow. There is much that we as agile coaches can do here. I believe teams are possible in just about any environment – but it does require a very different mindset. We could also argue the point that if the word resources is used, is that company truly agile?
Ok… I hear you. For the sake of this blog post I’m going to put on a different lens.
I once worked with a tiny company, around 20 people. They worked for various clients on an hourly billing case. Every project the people were mixed and mashed into new teams, depending on what the client/project needed doing and who was available. The big thing for me here was that it WORKED. Sure they had problems. But when it came to team work – they were solid. This is what is called teaming. Forming haphazard teams and working together well and then disbanding.
So what did this little company do differently? Well they really focused on building trust between everyone. They played games in the office (board games) and regularly went out to lunch together – think once a week at least. They often went for drinks and coffee. Most weekends – they would hangout. Not everyone together, but in little groups. They all became friends. When they shifted teams, they were sad to leave their team buddies but also excited to work with other friends. They wouldn’t stick to their team for code reviews – everyone and anyone in the office could do this. Once a week they had a “formal” get together to show what they were busy with.
I also recently worked with an even smaller company of 10. Of this 8 were developers. We were running Scrum, but a fairly lose interpretation. The team would plan together and understand the work together. And then as they were committing they would form smaller teams for each story, 2 to 3 people. We called this a micro-team. The micro-team could work in any way they wanted, and in the daily stand-up they would explain their progress to the other micro-teams. If a team needed help they could ask anyone. This allowed them to partner with developers with the right skills for that problem and to also have someone working closely with them. One thing we watched out for and called out was favorites. You could only micro-team with the same people twice in a row – then you had to mix it up.
You might see flavors of pairing and mobbing in the above two stories. Now I have a new term “TEAMING”.
So with this new lens on, look around, to your left and your right. How can you figure out your team mates best skills and use them and your skills in the best way possible?
Bob has just completed a task. His task was to create the test case for a successful credit card transaction. He moves the task into ShowMe and finds someone on his team. In 5 minutes Bob has showed Julia (a developer on his team) his test case and made a few modifications based on feedback from Julia. The task can now move to done.
The ShowMe column promotes understanding and cross-skilling in a team. The ShowMe is for the person who completed the task. It is based on the rubber duck theory, that explaining what you have done out loud to someone (or thing) else will highlight most of the problems immediately.
We find more and more people today are working remotely as companies become global and people are prioritising flexibility. So we thought we’d find out a bit more about this. We’ve had remote meetings which were painful, and we’ve also had ones that were hugely successful, enjoyable and engaging! We were interested to hear what others are doing: how and why they work remotely. So we ran a survey to get a better understanding of how people were doing agile remotely across the world. If you haven’t yet filled it in, please do so, we might update the report in the future if we get more data.
If you’ve never experienced a remote meeting that works feel free to join our Virtual Lean Coffee meetup to see how we run Lean Coffee with people from around the world. Or get in touch via and we will facilitate a remote workshop with your team for free.
We use ‘remote’ and ‘distributed’ to mean at least one member of your team is not sitting within 6 m of all other members. Here is an infographic of the survey results, or you can access it here: https://infogram.com/remote_team_survey_results.