“I’ve got my certification, but I can’t get a Scrum Master Role…”​ — here’s why…

I keep seeing posts on LinkedIn and elsewhere saying “ I can’t get a Scrum Master role, even though I’ve got a qualification, they always say I don’t have enough experience”. How can I get round this?…

I keep seeing posts on LinkedIn saying “ I can’t get a Scrum Master role, even though I’ve got a qualification, they always say I don’t have enough experience”. So I thought I’d throw my two pennorth into the debate…

First the good news, if a company turns you down saying “you don’t have enough experience”, they may well mean “we had loads of applicants and the one we took had more, or more relevant experience than you”. It’s a numbers game — we recently interviewed (well, assessed — that’s another post…) 24 applicants for 2 roles. They were all excellent, but obviously we had to turn down 22 of them how ever good they were. Don’t take it personally, there are always more applicants than roles.

Now, having “more or more relevant” experience does not mean someone has more Scrum Master qualifications (often the opposite, in fact!). They may well have relevant industry knowledge or they may have worked in an agile environment — as a PO or developer, say. They may also just have relevant Scrum Master experience. For instance, as a developer, they volunteered to run (facilitate, obv…) retros or story mapping sessions or organised lean coffee meetups. They may have great coaching and mentoring skills. They may have excellent domain knowledge. Most importantly, they just may well have a really agile mindset; they may have identified and eliminated waste in development cycles or found creative ways to measure customer value or shorten feedback cycles. All of these things will count either over, or in tandem with, qualifications.

Secondly, getting a Scrum Master role is no different to any other role, you need experience and it’s not easy to get it; when you first entered the job market, you were in exactly the same position — qualifications but no experience — but you overcame that problem. How? Well, you probably took a number of roles that moved you closer to where you work now — deliberately or otherwise. You need to do the same with Scrum Mastering. Get a role in an agile team, or at a really agile company — not necessarily Scrum Master — and learn and observe. Volunteer to step in when the Scrum Master’s on holiday and learn the ropes. See if any really agile companies will let you come in and shadow the Scrum Masters for a week and see what it’s really like at the coalface. Go to meet ups and chat to real Scrum Masters about their experience. (Yes, I’m happy to give you the benefit of my knowldge if you think it might be valuable…)

Thirdly, there are a lot of Scrum Masters out there with a lot of experience, which they have built up over the years, not got from a training course. At the bottom of this post, I’ve put a list of the kinds of things experienced Scrum Masters know (whether or not they use them…) which shapes how they react in every situation. These are the kinds of things you need in your toolbox that you can just bring out and use on the fly. That’s what experience is all about. I’m not saying you need all these, or that having them all makes a great Scrum Master, it’s just a list of things that are useful. (Indeed, often you need to know “bad” things in detail to reasonably argue against them. That’s why I know a lot about SAFe even though I am dead against it…)

You need to ask yourself what the Scrum Master role actually is, and how it adds value to a team/organisation. Many teams working in agile will know as much, or even more than can be picked up in a 2 day SM course — even developers are taught agile at Uni these days — so what can you bring to the team over and above that? If you can only bring encyclopaedic knowledge of the nuts and bolts of Scrum as a process, you won’t add much value and won’t get the respect of any teams you work with, indeed, you’ll probably do more damage than good! A toolbox containing things from the list is what you need, and an agile mindset so that in any given situation, you can react appropriately, and justify your decisions from the agile perspective.

Finally, you need to ask yourself — if I go into these companies that are rejecting me, could I hit the ground running on day one and handle everything this really difficult teams will throw at me? I’ve been Scrum Mastering for about 10 years and I learn something new every single day. That adds up to a lot of experience, and hardly any of it came from any courses/qualifications.

So, sounds pretty tough — why on earth would you want to become a Scrum Master if it’s that hard? Well, it rocks; one of the most varied and interesting roles I’ve had in my entire career and the one I’ve learned the most. Keep at it and good luck…

And, I’d recommend you all read this post by someone who joined giffgaff recently. This is what you need to do to get a job; like everything else, you have to work at it — a lot! There’s no magic certificate… Just Tell People What You’re Doing! (or trying to do)

Things an experienced Scrum Master may well know about. In no particular order, and by no means complete…

• 10+ different retro formats. But, how, why and when and what for! Facilitation!.
• Lean coffee
• A whole bunch of analogies/stories that illustrate agile thinking
• A whole bunch of games that illustrate agile thinking — usually involving lego… (Check out Agile Simulations for examples of online games)
• The Coin Game and the marshmallow challenge
• Techniques to get people engaged in meetings
• Techniques to stop people dominating meetings
• Psychoogical safety- what it means, how to recognise it, and how to acheive it in a team
• Greatness guild
• Retro warmups, e.g. improv games, truths and lies
• Modern Agile
• “Original” agile — manifesto and principles
• The Agile Onion
• Scrum values
• My reading list, obv. :-)
• Liberating structures
• Coaching skills
• Mentoring skills
• Empathy and EQ
• Negotiating and persuasion skills
• XP practices and why they work
• How to encourage/influence the wider organisation to be more agile
• A good knowledge of CI/CD
• What Technical Debt is, why it needs addressing, and when
• Testing strategies (move testing left, ice cream cone of tests, BDD, TDD etc.)
• New agile concepts such as #NoEstimates, #NoProjects, etc.
• Value stream mapping
• Story mapping
• Stakeholder mapping
• Eliminating waste — the 7 wastes of development and how to remove them
• Why velocity is a dangerous anti-pattern (IMHO…)
• Metrics and when and how they should be used
• Kanban and the concepts of flow, WIP limits, swarming, etc.
• Kaizen, and what that actually means in practice
• Lean, including Lean UX, etc.
• Outcomes over outputs
• The Spotify Health Check (online version)
• All the cool Spotify stuff — squads and guilds, BIDD bets, etc. (but don’t slavishly copy!)
• Who the thought leaders etc. are in the field, and what they’ve said/written/posted
• Corporate Rebels — what they do and the companies they research
• Standup anti-patterns
• Reasons why retros fail
• Handling difficult conversations
• Invigorating a non-engaged team
• All the agile frameworks, when to use them, and when to not use any of them but still be agile
• Gamestorming
• The Covey matrix
• The Stacey matrix
• Cynefin
• The fable of the roasted pigs (seriously!)
• Hand luggage, Xmas and other prioritisation techniques
• The role of a PO, anti-patterns and why they are not the same as PMs or BAs
• Reasoned arguments for things like why smaller iterations reduce risk
• Development best practices and what benefits they bring
• How to recognise a high performing team
• The stages of team formation, storming, norming, etc.
• The difference between pigs and chickens
• Estimation techniques, but also the reasoning behind #noestimates
• (I’m very loath to say it but) Jira, JQL, etc.
• Team mission/vision statements and why they are important
• The other 9,999 thing not on this list that aren’t covered on a 2 day SM course.

…and I’m sure you can all come up with others :-)