WikiCommons
“Compile error?!?” I mashed my hands down on my keyboard in frustration, to which the computer helpfully replied, “invalid command”. “You ungrateful hunk of ones and zeros I’ll give you a compactor error, garbage compactor style.”
I leaned back in my chair, for the first time noticing my home office was shrouded in darkness save the light coming from my dual monitors. How did it get so dark, it’s the middle of summer. Looking out my window I was dismayed to find the darkness was not caused by one of the Pacific Northwest’s famous summer rain storms. That meant I’d been trying to get this program to compile for?..
“Ten hours, give or take a bathroom break,” rumbled a voice. Being primarily a black gorilla, I’d missed Hogarth lying on the daybed.
“Ten hours? For the love of Peet, how did I spend ten hours on this?” I looked back at my screens. The compile error was still visible in the terminal window. The rest of the screen was filled with various websites and eBooks on C Sharp programming. Ten hours and I had nothing to show for my attempts to learn to code.
I turned to Hogarth, “Where’s my family?”
He waved at the door, “your wife came in about four hours ago. You handed her your check card and mumbled something about taking the kids to dinner.” He waved back at the computer screens, “I suggest you do something useful with that computer and order your wife some flowers.”
I nodded, “You’re right, that would be usefu… Hey, wait a minute. I was doing something useful.”
Hogarth grunted, “You were? “
“Sure I was, I was learning to code so that I could better communicate with the engineers I coach.”
Hogarth nodded his head, “Uh huh… So you’ve been at this what, two months? What have you learned so far?”
I glared at him. He knew very well the answer to that. I’d made only small progress in understanding the intricacies of C Sharp. Pretty much anything I had learned was in the first couple weeks of reading. The implementation of the reading is where I was stymied.
“Right,” Hogarth said. “And when was the last time you wrote a blog, went to a meet-up, coached one of your mentees?”
I stopped glaring now and turned to stare at my monitor again. It was preferable to be mocked by the compile error than to be schooled by my gorilla.
To Technical or Not to Technical, is that even the right question?
This is not a new argument. Before Scrum Master became a mainstream job title we were having the exact same conversation with project managers (see my 2010 blog, Project Gorillas are Subject Matter Experts). As an agile coach, today, I see the same argument for coaches and I also see it applying for any kind of consultant, who is going to work with development teams.
Do you have to have a technical background in order to work with technical people?
No, you don’t.
Does it help to have a technical background, in order to work with technical people?
Well, sure it does. That’s like asking “will I experience more, on my trip to France, if I can speak French?”.
However, you can be the best C++ coder in the world and if you were hired to coach a team on how to implement Scrum then you better know Scrum really darn well. My 2010 blog looked at this through the lens of project management and yet those principles apply the same to Scrum Masters and Agile Coaches. In fact, I think it applies even more in the agile context.
In 2015 there was a great article and subsequent conversation on LinkedIn about scrum masters and technical background. The main arguments, that a scrum master needs to have a technical background were “How will they remove technical impediments?” and “How do you know if the dev is lying or inflating the issue?” All right, let’s break it down then.
- Resolving Technical Impediments:Yes, the Scrum Guide lists one of the scrum master’s duties as “Removing impediments to the Development Team’s progress”. Cut and dried, right? It’s the Scrum Master’s job to do it.Only the scrum master is also a “Servant Leader”. One of the things this means is to be a leader. If your general was always the first to storm the hill, not only would he be too busy to direct the overall attack, he could well be dead. A Servant Leader is about creating the environment where the team can succeed.
Then we need to look at the development team themselves. The Scrum Guide says “Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment.” The development team is responsible for creating the product and they have all the skills needed to resolve this. If they don’t, they are going to be the ones with the technical understanding to work with others to get it resolved.
The scrum master doesn’t make the faulty database go away. The scrum master helps to ensure the outside database team is available and responsive to the development team.
- How to spot lying or exaggeration:
First off, you go back to what are the skills of a good agile coach or scrum master? Facilitation, conflict resolution, negotiation, and communication are just a few of the more notable. What they all have in common is people and the ability to work with them. After 20+ years of working as a project manager, scrum master and coach, I can pretty much tell if my leg is being pulled.
More importantly, though, is it’s again not the scrum master’s job to know if someone is lying or exaggerating. “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” This Scrum Guide quote applies not just how you will build it, it applies to figuring out what it will take. The product owner and the scrum master are supposed to trust the team and in turn, the team needs to be accountable to earn that trust. It’s not the scrum master’s job to call out a bogus estimate. Instead, it’s their job to create the space where the team feels safe enough to call out each other.
Technical skills are helpful, there is no question. However, the most important skills are those specific to being a scrum master, agile coach or consultant. If you don’t know your expertise, then having knowledge of the technology just means you can talk shop with them. You can’t fix their problem. So it’s not a question of “To be technical, or not to be technical?”. Instead the proper question is, “Do you have the skills to be right for the job you are doing?” Don’t assume you need something, just because you don’t have it.