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?
John Doerr on goal setting ( this made me see the value of OKRs)
Dylan Marron on the human side of online interactions
Jay Vogt on Facilitation
Brene Brown on being vulnerable. (It sounds like it’s not related to agile, but the key to being a trustworthy team member, coach and leader is vulnerability and honesty)
Dan Ariely on motivation. All this guys talks I’ve seen are interesting, check him out.
Wolter Smit on a healthy and happy workplace