Aurynn’s article talks about how Dev culture has been (and still is to a degree and in some spaces) afflicted by elitism. She explains wonderfully well why this is not in anyone’s best interests. I strongly recommend the article.
Scrum Masters Love Scrum, Right?
I may have mentioned on this blog before that I have interviewed A LOT of scrum masters in the last couple of years particularly.
One of the key things I look for when interviewing is a deeper understanding of what it means to be agile. We make a point of saying “we are hiring for a Scrum Master, but we don’t do Scrum.”
We hope the candidate follows our statement up with questions about how we do work. It’s not a deal-breaker of a response though. We have plenty of questions ourselves, and it is our job to try and find out who this candidate really is under the nerves and pressure of the interview. We try hard to be kind and welcoming. We genuinely want to know who they are.
You see, at NewVoiceMedia we want to hire someone who knows the answer to every problem is not to ‘do scrum harder’. Nor is it to ‘switch to Kanban’. Both these statements imply that they alone have the only ‘right’ answer to our problem – whatever it is. We are looking for someone who knows this just isn’t the case.
Just to be clear: I love Kanban. I love Scrum™. In fact I like most frameworks and methodologies to be honest.
(That’s a somewhat controversial statement to find on an agile blog isn’t it!)
I truly believe being agile takes only 2 things.
Also, I personally don’t care whether you are certified Scrum Master or not.
(I do know it helps recruiters do keyword searches on C.V.s. It also provides trainers (who also have to be certified in training) to earn an excellent living. This is whole other
rant discussion for another day though!)
What I do want to know from an interviewee though, is if you can spot problems early.
I want to know that when you do, you can come up with several different ways to potentially solve that problem.
I want to know that you can reasonably assess the risk versus reward of each of those approaches you’ve identified. Also that you will be able to set about experimenting to see if your preferred choice works at all.
I want to know that you would find a way to take a benchmark for that experiment and why that is important that you do.
I want to feel that you could (and would) re-assess your original ideas in the light of whatever you learn from your first experiment.
I want to know if you understand the ‘why’ of the rules. The rules are only the rules until they’re not. But you need to understand them before you discard them.
You don’t even need to have heard of Agile to do any of the above successfully.
Conversely, here is what I really don’t want, and the point of this post.
I don’t want to hear why Scrum is the one true path to agility.
I don’t want to hear that Kanban is the only right way to be agile.
I don’t want to see even the hint of a sneer when you talk about waterfall, or any other framework or methodology that is not your favourite. (Don’t feel bad, we’ve all done it – let’s just not do it again :))
I don’t want to hear how you have been leading all the ceremonies at your current company either. Of course you have….unless you haven’t. I’m very interested if you haven’t. That sounds like you might have an interesting story there.
Tell me instead how you changed something and why.
Tell me about your team’s victories over adversity.
Tell me how you made planning work better for your team when the Product Owner was unobtainable.
Tell me where you or your team failed abysmally – and what you learned from that.
By all means, tell me why Scrumban was great for your team, or why SAFe was the perfect choice for your company.
But then ask ME what problems my team or company face right now. Because our problems are different.
Not just ours though, everyone’s problems are different.
To Sum Up
You might have noticed that my very short list of how to be agile contained no ‘rules’. Interestingly, it’s very hard to do something wrong if there are no rules.
As Aurynn’s article beautifully expressed, we are all on a journey to be better tomorrow than we were today. We all start in different places, and need different things at different times.
If you mock a fellow traveller struggling on a path you’ve already trodden, you can’t truly feel that makes you better than them, surely?
To paraphrase Aurynn, we don’t become any better if we exclude people who are earlier on in that journey, or taking a different path.
As scrum masters (whether you do Scrum™ or not) we are used to being almost invisible to the business, whilst helping our team achieve great things. Why would we not behave in the same way towards the wider team of Agile practitioners to which we also belong?
I wrote here about how mentoring another person can be an amazing learning experience for you as well as the person you mentor.
None of us can go further in our journey without those with experience helping us navigate the tricky bits.
Drop me a line if you think you’d like to work with me in the future. I promise I am really quite nice 🙂 (twitter: @helenlisowski, linkedin, email: firstname.lastname@example.org)