As part of the on-going Scrum Myths series at Scrum.org, here are three myths related to people skills.  When I say people skills, I mean topics like emotional intelligence, emotional IQ, and person-to-person interactions.

Myth #1: Scrum must be "huggy / feely"

Word on the street is that Scrum has to be "huggy / feely".  Basically that Scrum has to be all emotional or it's not going to work.  It's part of that classic misconception that Scrum is just a bunch hippie-dippy, Birkenstock-wearing, Jeff Lebowski wannabes who just want to talk about their feelings and never actually get anything done.  Ok.  Sure.  There's some of that out there but -- well, it doesn't have to be that way.  There's no need to be all emotional and "huggy / feely" if you're doing Scrum.  You can do Scrum, be successful at it, and be completely emotion-free.  If you're getting the results that you want out of your team and you're excluding all the emotional stuff entirely, that's fantastic.

But what if you're NOT getting the results that you want?

On a scrum team or in an Agile organization, there's almost always room for improvement.  Sure, you can probably do  ok just by following the rules of scrum from the Scrum Guide -- but at some point, you'll be looking for ways to improve.  This is where addressing the human, emotional, "huggy / feely" stuff can be important.

Software development would be wonderful if it weren't for all the people.  Back in the olden days of software, you could have one or two developers and they could crank out what everyone thought was amazing.  Fast-forward to today and the software that's expected is a lot harder to deliver (in any reasonable amount of time) with just one or two people.  This might mean that your organization is working with a small team of 5 to 10 developers or maybe you're working with multiple teams with hundreds of developers.  That's a lot of people.  That's a lot of human interaction.  Seems pretty unlikely that they're all just going to get along perfectly.

Scrum doesn't *require* emotional intelligence and emotionally aware leadership -- but it sure does help.

Myth #2: Anyone Can Be the Scrum Master

Here's the myth: anyone can be the Scrum Master and it doesn't matter who that person is.  This comes up all the time -- especially in organizations that are new to Scrum.  Here's how it starts.  Either there's no obvious choice for who should be Scrum Master or nobody actually wants to be Scrum Master.  So they either randomly pick someone or they decide that they'll trade off the Scrum Master role from Sprint to Sprint.  "Steve'll be Scrum Master for Sprint 1.  Anisha will be Sprint 2.  Tarun in Sprint 3."

Yah…that's pretty unlikely to work.  Not everyone is meant to be the Scrum Master.  Not everyone is going to be good at being the Scrum Master.  The idea that "anyone can be Scrum Master" is kind of like saying "I can type therefore I think I'd make a good software developer."  It just doesn't work that way.

If you know the rules of Scrum, you can be a passable, functional Scrum Master.  But there's a pretty huge difference between a passable Scrum Master and a really good one.  Emotional intelligence is a *huge* part of being a great Scrum Master.  Your goal is to help your team to be productive and to self-organize towards delivering fantastic, done, working software.  If your Scrum Master is seriously lacking in emotional IQ, you're going to have trouble.  If your Scrum Master is a control freak who can't stop giving orders and has a "my way or the highway" attitude, chances are slim that that team is going to do well at self-organization.

So while Scrum doesn't require "huggy / feely"-ness and good people skills, the Scrum Master role probably does.  Helping all those people to get along and be productive and creative is no small task.  Merely following the rules of Scrum is probably not going to be enough.

Myth #3: The Scrum Master has to be "techie"

Ok.  So not everyone can be Scrum Master.  But surely the Scrum Master should be a technical rockstar or at least have a technology background, right?  Usually the thinking goes, "well, if my Scrum Master can't understand all the technology discussions then how are they going to tell the team when they're wrong?"

Well, that's not really the Scrum Master's job.

Sure, it can be helpful sometimes to have that expertise but the Scrum Master isn't necessarily the technical leader of the team.  The Scrum Master's job is to help everyone remain focused and productive on the mission of delivering that done, working software.  That's a whole lot more about reminding the team about their Definition of Done and on human-oriented team facilitation than actually saying anything about the code or software architecture.

In fact, I think that having a coder or a former coder as a Scrum Master can sometimes be a liability.  Usually, this code-centric Scrum Master gets stuck in the weeds of the technology solutions rather than being focused on the ultimate goal of delivering software.  This isn't because they're being malicious -- it's because the code is where they're most comfortable.  Coders think that software is about code when what you really want is for the team to think about delivering finished, usable functionality. There's a huge difference between code that's written and features that are delivered.  Helping the team to efficiently get from written code to done, working, delivered software is most of what the Scrum Master worries about.

You really want to have someone in that Scrum Master role with fantastic interpersonal skills and a big picture view of software delivery.  It's important for Scrum Masters to be able to get some distance from the tech and hang back so they can see the big picture.

Summary

One of the biggest problems in the software development industry is the name -- "software development industry".  We're way too focused on code.  The more that your team can think "Software Delivery Industry" versus "Software Development Industry" the more successful that you'll be.  And so much of this has to do with helping all the humans to work together and get along.  Remember: play nice!

-Ben

-- Need some help with your Scrum process?  Want some Scrum training for your team?  Looking for someone to coach your Scrum Masters?  We can help.  Drop us a line at info@benday.com.