New Team Members with Mark Levison

Episode 65

June 20, 2012

15:27

TBD

tbd

The Agile Weekly Crew and Mark Levison discuss team formation, conflict, working agreements and Scrum masters.

Episode Notes

Drew LeSueur, Roy van de Water and Mark Levison, a Certified Scrum Trainer in Canada discuss adding new members to scrum teams:

ScrumMaster Tales

Storming, Forming, Norming, Performing

Disrupting teams with new members

Team hazing rituals and on boarding new members

Dealing with crises in Scrum

Avoiding conflict in Scrum?

Working agreements

Part-time Scrum Master

Neutral Scrum Masters

Transcript

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.

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. 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.

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]

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.

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.

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.

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