Scrum Requires Gray Hair
Skill equals Knowledge times Experience
When I started my career as a Scrum Master, I knew absolutely nothing about anything related to project work, and I knew that I knew nothing. It was perfect. It only got dangerous after I thought I knew anything.
After my former position at a tourism firm got cut along with the entire IT department, in the early days of the pandemic, I started a new position as Agile Coach in an awesome project in the education sector. The conditions were amazing, a fertile ground for an Agile way of working. So I joined and when I found chaos, I immediately started what we at Serious Scrum call “inflicting help.” I tried to do everything at once because I perceived there to be a problem everywhere. After all, if there were no problems, then I wouldn’t have a job.
EBM, Theory of Constraints, Focus, Stop and Fix, User Focus, LeSS, Scrum… I brought my entire arsenal of knowledge to bear, pointed out mistakes, and asked what the heck we are going to about them.
First I suggested, then I asked for, then I demanded. And lo and behold, I achieved nothing and people hated it. In fact, I spent more time fighting about the “right” way to do Scrum than actually improving the way our teams and organization worked. I felt as though I wanted to go in the direction of “Serious” Scrum, and my colleagues forced their way of working onto the teams through a wash of processes and best practices, some of which came from SAFe! SAFe! Naturally, I was filled with righteous anger and suitably aloof contempt! Surely, they all must just want Waterfall in disguise.
First I suggested, then I asked for, then I demanded. And lo and behold, I achieved nothing and people hated it.
Things started improving when I gave up. If they wanted to command and control their teams, or so I believed, I’d simply let them do whatever they wanted, and I’d focus on my team. But now I felt like I wasn’t doing what I was hired to do. And I wasn’t. All of us Scrum Masters worked individually, going in several directions. We desperately needed overall focus, which no one provided. Even in my team, without the security of a common direction, there was only so much I could do. Half-consciously knowing I had achieved almost nothing in my first six weeks, I could no longer sustain that air of arrogance that had slithered into my way of thinking. I felt like I had failed my job, and like I could not provide what my colleagues needed, but I didn’t know why. I was in over my head, and I was forced to ask for help.
Turns out, I didn’t even have to ask. People wanted to help me. All it took was me accepting that help. But that’s a different story for a different time.
Through asking for help, I got to know the individual strengths of my colleagues. Conversely, I also regained humility, the mindset that says “I don’t know everything, I have weaknesses”. Together, these insights combined into a singular realization. I don’t have to know everything as long as there are colleagues whom I can trust. That’s okay. I write “I realized” and not “I learned”, because realization is different from learning or even knowing. I read Turn the Ship Around, same as many other Scrum Masters I know, but just having read it doesn’t mean anything. You have to realize it.
I write “I realized” and not “I learned”, because realization is different from learning or even knowing.
I will not delve too deep into the effects trust in your colleagues has on your work. Just know it’s one hell of a drug. I was riding the lift one day with one of the first colleagues to offer their help, and I told him that I wanted to do another LeSS course because surely, there was something that I was missing. He asked me if that was really what I needed. In his experience, he said, Skill equals Knowledge times Experience. I had the knowledge, he said, and now it was time to get the experience.
“Skill equals Knowledge times Experience”
A few short weeks later, my firm hired another Agile Coach to take control of what they call the “Product Factory” (a term I probably will never get to grips with), the unit of product development that exists in clear distinction from the bureaucratic reality outside of it. (Yes, I know how that sounds.)
He suggested the exact same things I had been suggesting/asking for/demanding for three months. Clear performance indicators, focus on a small individual area of improvement, and a rigorous commitment to quality.
Everyone loved it, and I was stumped.
I’m truly happy to say I never felt resentment towards our agile coach, but I did feel resentment towards myself for not being “good enough”. How was it that this person could just come in and do everything right? What was I doing wrong?
At the time, I had begun to hang out with my colleagues in virtual coffee breaks. (The effects of Covid-19 on this whole story deserve a book in and of itself). One day we got around to this very topic, and we both shared our frustration that we had been unable to achieve something that seemed so easy for our new coach. We also chuckled our way through a conversation where we realized we had wanted the same thing all along, we just hadn’t been able to communicate our needs and vision.
And then they said something that I believe is true not just in Scrum, but in every career.
“Well of course everyone listens to him, he has gray hair and a beard.”
Now, I don’t necessarily believe you have to have a beard to be a successful Agile Coach. Let’s keep in mind the person who brought Agile and Coaching together, Lyssa Adkins, notably does not have one. But if we see gray hair as more of a metaphor, as a symbol for experience, then I say that if you want to be truly great at Scrum, you need gray hair.
If you want to be truly great at Scrum, you need gray hair.
Experience builds not only knowledge, it builds confidence in that knowledge.
As a Scrum Master, you need to have gone through an Agile Transformation, the Tuckman stages, and a Sprint Review that invites real stakeholders to be able to say with confidence that the way you suggest to do these things is the best way to do them.
As a Developer you need to experience the sheer joy of working on a customer-focused story instead of ticking off tickets that begin with “I as a server…” in order to truly stand behind the concept.
Even if you know there is a torch behind you casting shadows, you need to fumble your goshdarn way out of your cave if you want to lead anybody else towards the “light”. And yes, sometimes even self-organizing Scrum teams need to be led. Just telling people the way they are working is bad (through metrics), or even just vaguely hinting that there’s a better way of working and then not providing it is straight-up cruel. Sometimes you need to roll up your sleeves and invite your team to try something new, especially if an agile way of working requires it. Sometimes, especially in the beginning before there is an abundance of trust, that will suck. A lot. People might reject your invitation. But you still need to do it, because if you at least strongly suspect that the new way of working will make things easier for everyone, you owe it to everyone to try to improve it. It’s basic ethics. But even if you know there is a better way, you need the experience to have the confidence of going through the storm.
Usually, only time will grant you that experience. Time will also grant you gray hair, but that’s just a bonus.
Even as I am writing this I am aware of the irony of claiming I had improved. As the great Wayne Jude famously muttered in Darkest Dungeon, I must remind myself that Overconfidence is a slow and insidious killer.* There’s still a strong possibility that I will fall back into old patterns now that I think I “get it.”, but that’s alright. It’s normal. Experience isn’t a straight line, and having experience in dealing with failure is just as valuable as having experience in being successful. In fact, I’d argue they are mutually inclusive.
Do you want to write for Serious Scrum or seriously discuss Scrum?
* (You didn’t honestly believe I would write a Scrum article without a video game reference, right?)
