New Team Members with Mark Levison

Drew LeSueur: Hi and welcome to another episode of the Agile weekly podcast. I’m Drew LeSueur.

Roy van de Water: I’m Roy van de Water.

Drew: With us we have Mark Levison. Mark, tell us a little bit about yourself.

Mark Levison: I’m one of Canada’s two certified Scrum trainers. I’m based in a part of Canada called Ottawa where it’s already dark outside, even though the rest of you are still looking at sunlight. I have been in the Agile business one way or another for about 12 years now. I do a lot of writing on a blog, and these days I’m spending a lot of time writing about a Scrum Master named John, and all the problems I throw him as he and his team try to win their way through the Agile world.

Adding A New Person To The Team

Drew: The article that we read that caught our interest was “Scrum Master Tales ‑ New People on the Team” and you talk about John and he’s struggling with a new person who’s on a team. Can you talk a little bit about that?

Mark: Like any organization, John’s team grows and at the critical moment they decide they need a bit more senior technical help. They hire in a character named Kirby, and Kirby has over 20 years experience developing software. He thinks he’s seen and done it all.

It turns out that Kirby is very, very loosely modeled on me. Kirby strolls into the team and starts throwing his elbows around, he’s extremely knowledgeable and very skilled, but he’s not very human‑skilled.

He’s thinking a lot about what’s wrong with their code and very little about their personal needs and understanding how they came to that position.

Roy: I agree. One thing I liked about this article is we through around the concept of forming, norming, storming, and performing as phases of a team (Tuckman Stages Group Development). You mentioned that when some person gets added onto the team, that process starts all over again.

Roy: For the entire team, not just for that individual right?

Mark: Yes. The way I illustrate this when I’m running a CSM course, I have a group of people sitting at a table, and by the time we’ve talked about this in the course they’ve already formed a fairly tight team. They’re often sitting a lot closer together.

I simply walk over as the instructor, pull up an empty chair, and jam myself in the middle of the table and start pushing people to one side. Of course, what happens is ‑‑ I don’t do it too rudely ‑‑ but that ripples around the table. People start to realize, that even though they weren’t sitting next to me, when moved in next to one of their colleagues, their position on the team got affected.

My claim is that you’ll have the same outcome when you introduce a new person to a technical team. Even the people who hop away, wind up finding their role changed as the new person comes in.

Fastest Way To Onboard People

Roy: What’s the fastest way to on‑board somebody if you’ve got a new person coming in? How do you just rush through the forming, norming, and storming stages and get to performing as quickly as possible? Is there a quick path or is that something that needs to take its time?

Mark: I wish there was. It’s funny. It comes up in nearly every one of my courses and with nearly everybody. I have a little test at the end ‑‑ not the scrum lines test ‑‑ but my own personal test to make sure we understand what people have really understood.

In every course, I can guarantee you at least two people will answer the question about conflict ‑‑ to which the answer is conflict is natural and cannot be avoided. They will answer that conflict can be avoided with skillful scrum mastering.

Roy: Ooh…

Mark: Sadly, no. I’ve not found any skills yet which allow us to avoid conflict. There’s no better way to deal with it than to simply allow it to happen and to get through it.

Roy: I’ve been on a few teams that wanted to jump the idea of conflict through a form of hazing, where they wanted to have a gauntlet for new team members to run through. What kind of impact would something like that have on the team?

Mark: Wow! That does not sound like a great idea.

[laughter]

Hazing Rituals

Mark: My first thought is it puts the new person in position of weakness and possibly fear, depending upon how bad your hazing rituals are. I went to a university where the hazing rituals were fairly unpleasant. It puts the existing people in a position of power. If anybody really wants to think about just how dangerous that can be and how far it can go, they should read some of the original prisoner experiments from the mid ’60s.

I can’t remember the author’s name.

Roy: Were those ones in response to the Nuremberg Trials?

Mark: I’m thinking of one called “Prisons We Choose to Live In”, I think. It’s a series of psychological experiments where people were recruited. Some people were made guards and other people were made prisoners and very quickly, evil and not good behavior started to evolve.

The gist of is that sounds really quite dangerous. That sounds like it sets up power relationships which are not very good.

Roy: Sure.

Mark: I’ve not encountered that before. I’d have to go give that a lot more thought.

Roy: Luckily, the team that I was on, or one of the team members that were pushing for that, ended up rejecting it. We didn’t actually go through with it.

I agree with you, it would have been a dangerous idea. I think it stems from the idea that a team seems to form quickest when they have to rally together around some kind of crisis, right?

When there’s a need for the team to form or, even if there’s ‑‑ in lack of a crisis ‑‑ a strong vision. That might have been the driving force behind it.

A Crisis Forms A Team

Mark: A crisis is exactly what it takes for team formation. Luckily, in Scrum, we usually get the crisis fairly quickly. It’s one of the joys of Scrum, I might point out.

In my course, I simulate this. I actually use Scrum to run my course, so I have a burn‑down, I have a back‑log. The course is a product back‑log, there isn’t printed agenda.

We have our first crisis at the end of sprint one, when it becomes clear we cannot achieve all of the material that we’ve set out. Then, we have to do some radical reprioritization.

That usually has them desirable effect of throwing the team into crisis, in the sense of a real Scrum team ‑‑ maybe not on my CSM course. I don’t need to create artificial crises. They usually take care of themselves quite nicely.

Roy: That’s a good point.

Mark: Honestly, I’ve never seen a team that didn’t, after the first few sprints, quite naturally start trending into storming. My favorite analogy is, “If you interrupt me and I’m in the IDE, your interruption had better be damn good. Actually, it better be a serious reason.”

If on the other hand, I’m browsing cnn.com, “Hey, any old interruption is good”! That’s the beginnings of storming there. I’ll yell at you if it’s not ‑‑ I won’t really ‑‑ I might pretend to yell at you if it’s not a very good interruption and I’m in the IDE, and I’m doing something I think is valuable. I might be more open to it when it’s just cnn.com.

Trying To Prevent Conflict

Roy: Earlier, you mentioned about people entering that scope of Scrum Mastering that will allow them to avoid conflict. I’ve seen that in the past where there are individuals that are so against the idea of conflict that they’ll do anything to prevent it from happening, even when they wouldn’t even be involved.

For example, Scrum Master just hates conflict so much that they will try to prevent it. You had mentioned that it doesn’t really seem possible to avoid the conflict, but is it healthy to even try?

Mark: In fact it’s even worse. If you try you’ll probably set the team back. I try it all too often myself and what I find happening is…I can’t remember, I think, it’s Kirby and Markman…I’m pretty sure are in conflict.

Let’s say we go to Kirby, “Kirby, would you please stay clear of Markman’s tasks for, at least, the next two weeks”? “Mark, would you please stay clear of Kirby for the next two weeks”?

I haven’t really resolved the problem. All I’ve done is taken two warring parties and told them to back off. A much better solution to this problem requires getting them to talk. I might take them individually out for coffee just so you can hear each of their sides.

[jokingly] A great Scrum Master spends 20 to 30 bucks a month on coffee or tea, if that’s your preferred beverage.

Roy: I like that.

Mark: Take them out each individually for coffee, hear their respective sides and then, if this is an on‑going issue and it isn’t just the first time, maybe bring them together and see if they can create working agreements, but the point is you don’t ever actually do anything on their behalf.

You simply help them come to the conclusions that they need to come to.

Scrum Master Must Be Unbiased

Roy: In your article, you mention a lot about that ‑‑ where it’s very important for the Scrum Master not to take a side, to remain unbiased. That’s got to be hard for a lot of people. Can you elaborate a little more on that? How is that possible?

Mark: It’s hard for a number of reasons. A lot of organizations have part‑time Scrum Masters, who is usually a Developer. At the moment, we have Kirby come in. Kirby is going to see John as the Scrum Master/Developer in that case, and he’s going to assume John is primarily friends with all of the existing people.

Instead of seeing John as someone who is playing the role of neutrality and balance, he sees John as another friend of those developers who aren’t churning out very good code ‑‑ someone else to do battle with.

There is no great solution except that you have to win people over a little bit at a time, and you have to be seen as being neutral. You have to make it clear that there are no sides ‑‑ that your job is the care and feeding of the entire team, and not just any one individual. That can be really difficult.

Frankly, I suspect that will be just as much a problem in the Kanbanny world as it is in the Scrummy world.

Process Highlights Problems

Roy: We just published or are about to publish a podcast in which Derek talks about most of these problems that we’re seeing in teams having nothing to do with the process.

The process just seems to highlight them, and almost exacerbate them. The point of the process seems to be that we need to highlight these problems, so that we can attack them.

Scrums aren’t going to solve your problems anymore than Kanban, or any other processes. The important part is to cycle as often as possible, get some feedback and get better.

Mark: Exactly. I shock people in my course on a regular basis by making the rather bold statement, “Scrum has never solved a single problem.” Scrum merely helps you see what problems you have already.

People are shocked. They think they’d spend a lot of money to get their problems solved, and they’re very surprised when I explain that no problem will be solved.

Include The Team In The Hiring Process

Roy: I like also in your article, you talk about if the team had been more involved in the hiring process from the beginning, it would avoid some of these problems, or maybe avoid bringing a member on who wasn’t a great fit.

I’ve been in a setting where we did do that, and it was great. The whole team got to pair with the potential hire and they got to decide as a team, “Is this a good fit for us”? How about you? Can you share an experience?

Mark: I have seen a few examples of that, but sadly I never got the chance to do that when I was employed working for real companies before I moved into the consulting world.

My favorite example of that recently goes one further. The folk at Menlo Innovations in Detroit go one further ‑‑ they get the candidates to pair with each other, the thinking being, “If you can make the person you’re supposedly competing for job with look good, you will make every one of your peers look good.”

Roy: That is an awesome idea.

Mark: Yes, I’m looking for someone who’d like to have me run that as an experiment with them. [jokingly] By the way, please don’t take the forgoing as legal advice in the United States of America.

[laughter]

Roy: That sounds like a really neat idea to try. I can’t imagine as an interviewee though getting paired up with another interviewee that I’m competing with and trying to make them look good like that. That’s going to be tough, but I really like the idea of trying to see what comes out of that.

Mark: I suspect if I tell too many people about it, the secret will get out and maybe the secret sauce will be lost.

[laughter]

Roy: That’s true. Thanks a lot for joining us on the Agile Weekly podcast. For those of you listening, feel free to participate in the conversation at facebook.com/agileweekly. Mark, did you have any last words, anything to share with the listeners?

Mark: Don’t stress. When you see your team going through forming and storming, don’t stress over it. Let it happen ‑‑ it’s going to happen at the pace it happens. There’s nothing you can do except watch, and think of yourself as a sheepdog and not a leader.

Roy: If you get a chance, Mark’s blog can be found in the description of this podcast. All right, thank you very much. Thank you Mark.