Approaches to Building Agile Teams

Derek Neighbors: Welcome to another episode of the Scrumcast, I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.

Jade Meskill: I’m Jade Meskill.

Dealing With Someone Who Is a Bad Team Fit

Derek: Today I think we’ve got a number of topics. The first one I want to talk about is what you do as a team member and as a management team or a manager when you’ve got somebody on your team that clearly does not seem to be fitting in with the team?

Jade: Kick them off

[laughter]

Clayton: Kick them off the island or [inaudible 00:00:40] .

Jade: Right, or make them VP or special projects or something.

Roy: Yeah [laughs] . There you go.

Clayton: Let’s see. Is this a self organizing mature team or any old average team?

Derek: I would say let’s go from both angles. Let’s go from a mature team but maybe not fully self‑organized, meaning the participants are not necessarily juvenile in behavior. They are adult in behavior but maybe not fully self‑actualized. And then let’s go from a more mature approach. Like how would a mature team approach it?

Roy: So, I think what I have often seen with less mature teams is they’ll notice the person not fitting in and not saying anything for a while until it becomes more that they can bear. And then they’ll go around the person directly to whoever is in charge of them and complain to that person.

So like, if Derek is being a jerk all the time, then I’ll go to Derek’s manager and I’ll be like, “Hey, Derek’s being a jerk all the time. Can you do something about it?” And then the expectation is that to protect me. Derek’s manager is going to tell him to shut up or whatever.

And I think that in a more mature situation, I would approach Derek directly and have a conversation rather than just telling him that he’s being annoying or a jerk or whatever. And then that type of environment, Derek might realize that he didn’t even know he was coming off that way. And I might not realize that to sensitive to some of the ways that he was saying something or something like that.

And I think that’s how a mature would solve the problem is directly and head on and not try to…they might get a third party involved simply as a mediator to prevent from emotions becoming too heavy, but they wouldn’t get a third party involved as an intermediary.

Five Dysfunctions of Team

Clayton: Yeah, I think on the kind of immature thing, you could talk about the five dysfunctions of a team. So maybe they’re kind of lacking in trust, and they have some sense of false harmony, so in that case, it would be the kind of thing where everything’s kosher and it’s all great, but when this other person’s not around then I’ll complain about them.

I don’t ever do anything about them because people revert back to, “If you want it done right, do it yourself.” I’m not going to totally kill myself to save the project. I can pretty much do all the work that I need to get done without involving this person. The two of us will be the heroes on this thing. We’ll figure it out. I think that’s a common pattern.

I think also, when you don’t feel like a team. When you don’t feel like you are working with each other, for each other, then that’s when it’s easier to get management involved and say, “That’s above my pay grade. That’s not something I have to worry about. I’m just here to write code.” I’m going to go tell who ever I think is responsible for that. I’m going to go shove this problem off on them and hope they figure that out.

Roy: I also think that an on a mature team, diversity breeds innovation. That person who is dissenting, is the least like everybody else, and might be the awkward person, is somebody who’s got a different view point and different experiences, can bring different things to the team that the other team members just aren’t capable of doing. Casting them off, writing them off, or not involving them in the team work, I think, could be a huge mistake.

I have definitely seen cases in which somebody is absolutely poisonous to a team. I don’t know if it has always been irreversibly so. That is definitely a huge danger. I do think that every effort should be made to try to incorporate their dissenting view points. They’re just not fitting into the team. Make it an asset rather than something that hurts the team.

Stages Of Team Development

Jade: I think it’s a very enlightened team that could start to recognize and tackle this challenge. Usually it’s a team that is still in the Tuckman model, in the forming stage. They’re dipping their toe into the storming and getting scared, backing away from that. It’s a hard thing to overcome. It’s against most of our human nature to deal with that.

Clayton: One thing I think that’s interesting though is that as the team starts developing some common practices, base lines for expectations, or a working agreement, it makes it a lot easier to have those conflicting moments when you can say, “We talked about how quality was important to us. You don’t seem very concerned about the build breaking” for instance. “We all agree that quality is important. What can we do about that?”

I think that really takes the edge off the conflict versus if you don’t have that kind of precedence then you’re talking about “Hey jerk, why did you break the build, like you break the build all the time.” Maybe we haven’t even talked about why that’s important, or why we care about that.

But if you kind of establish those things that makes it easier to say, “Hey, I’m not trying to beat you up personally, I’m just saying I thought we all agreed to this and it seems you’re violating that, like, why is that?”

Roy: It also seems to be less about me versus you too because it’s not “Hey i don’t like that you’re not breaking the build,” it’s more like “We agreed as a team to not break the build,” right?

Simple Rules

Jade: Right. There’s a lot of studies that show in complex adaptive systems or in human interactions that you need those simple rules to help just kind of maintain civility, right? Then you can talk about violating those shared rules like you’re saying and not about an individual person and their personality.

Derek: Yes, I’m kind of hearing there’s a few stages to this in the sense it looks like the first team is just not aware that the person doesn’t fit. The second one is that they’re aware that the person doesn’t fit but they probably bad mouth the person behind their back or they just feel like they have the trust probably in management even to deal with it.

Then the third which is where most of the team’s I see somewhere fit into… or maybe they have some trust in management to the point where they are highlighting to management their concern. “I’m concerned about so and so”, “I’m concerned about performance” et cetera.

Then I think the next one is the team that start to directly approach each other. And I think the last kind of model is the team that not only directly approaches but actively solves the problem, right? So it’s one thing to say, “Hey, you’re really pissing me off in ABC,” it’s another things to say “Hey, how do we get to the point where we’re including you in the team better.”

So with that I am sticking with the team concept. I’ve seen a lot of organizations that are undergoing change and wanting to go to self organizing, where they’ve got a team that maybe isn’t performing up to par. They’ve done command‑and‑control and so they try to go to something that’s like a hybrid command‑control. Maybe it’s self organizing, with all sort of reporting structures back or status reporting mechanisms.

They tend to flip flop back and forth between giving the team full reins or enough rope to hang themselves to completely command‑and‑control and ultimately they’re just afraid that products are not going to be shipped on time or they’re not going to be successful.

What are some key triggers you see in that and if you’re a manager in that situation how do you get to the point where you let the team be self organizing and still mitigate whatever risk you’re kind of concerned with?

Jade: I think again it goes back to some simple rules of engagement. If I were to look at that situation that you’re talking about, I’d say there’s probably some lack of trust happening there, probably for various different reasons. Either people aren’t doing what they say they’re going to do and so the command‑and‑control sneaks back in.

There’s a lot of reasons that you can see that kind of flip flopping around. Kind of trying to sort of self organize. I think the trick with self organization is kind of an all in mentality. You have to give them the container to self organize within, or else they’re really not self organized. Your job as a manager is to figure out what that can look like and at the same time, help you team to not drive off a cliff. It’s a tough balance to find.

Shock Therapy

Derek: So I really like a blog post that was on Jeff Sutherland’s blog called “The Scrum Shock Treatment.” It was describing a way to jump a team into the idea of doing Scrum. It was very command‑and‑control, which is the part I didn’t like, but it kind of made sense in this context which is “I’m going to tell you how Scrum is going to work, and we’re going to do strict Scrum and you guys don’t get a say in the matter until these criteria are met.”

He had some arbitrary criteria which, I think, you should probably negotiate for specific cases like, whenever you have more than 240 percent of your current velocity, or things like that.

Then as soon as those criteria are met, then we’re going to slowly start to allow you to make more decisions because I think that’s one thing that I’ve seen a lot where a team starts doing Scrum but then starts making their own exceptions to the rules before they understand why the rules are there in the first place. And before they can understand why the rules are there in the first place, they have to see those rules in action and see how effective they can be.

I think, Jade, you pointed out earlier that you’re coaching a Scrum team, and you saw them doing the almost traditional like, “Let’s start cutting ceremonies because they produce too much overhead.”

Jade: Yeah, the wand of Scrum.

Derek: Right. Then it’s the inevitable, “Let’s start replacing all of our physical tools with digital ones because that would just make things so much better.” I think that those are the types of things that we really need to get them to try doing the things the right way first, and then let them change things up and make their own decisions.

Team Self-Organizing Through Impediments

Clayton: I think all the Lean, Kanban people just collectively face palms at the “Scrum Shock” article. But with that said, I think an important thing if you’re a manager dealing with self‑organizing teams is to really make that clear distinction about self‑directing versus self‑organizing. You should never say self‑organizing without mentioning self‑directing as well.

But assuming you can get that in place where you have some constraints, I think then you can switch into the role of, rather than being either the taskmaster or the tweaker or nitpicker person who’s just constantly looking for “whose shoulder can I look over?” that kind of thing, to be more of the enabler person who’s saying, “What’s my team missing, and how can I enable them to be successful?” I think that’s an important distinction to make.

There’s probably some argument to be made for letting the team self organize and maybe a certain regard to get going. Then as they become more comfortable in that space, they expand in that. I think over the life of the team, that box probably gets bigger and bigger and bigger until it gets to a point where the box is no longer important. But starting out, I think you could probably let them self organize on smaller things first.

I think with that said though, there’s probably never a good time to just say, “Now, we’re a self‑organizing team.” There’s always some impending release or something that’s coming up that’s going to, “Oh, we can’t do it now. If we waited six months, then it would be a perfect time.” And that time never comes. So you really just have to take the leap of faith, I think.

Hiring Quality People

Derek: Continuing with the team theme, there was an article that I think we were discussing earlier today about, “Don’t try to hire a Rubyist.” I think Bob Martin ranted a little bit is, “Don’t hire a Rubyist. Just hire a good programmer, and they’ll come.” Then we had some fun memories of, “Hire somebody who is not a Rubyist. Throw him in the pool, and then say, ‘Stop drowning. Swim faster. Stop drowning. Swim faster.’”

So when building a team, what are your viewpoints on just hiring quality people as opposed to hiring people that are qualified for the job? And how would you integrate them into the team if you don’t go either direction?

Jade: I think I get asked this question a lot by managers or executives who are looking to build their teams. I fall back on the Agile Manifesto that you need to find motivated individuals, and some baseline skill set is of course part of hiring someone. They have to have some basic skills that would allow them to be a contributing member of the team.

Does that mean that they have to have the exact skill set that you’re looking for? No. You want to hire motivated, smart people that will adapt to whatever tools or whatever situation that they’re in and do a quality job.

I tell them to look for attitude and aptitude. Those are the foundational things that if you’re looking for a Scrum master, don’t just hire someone because they say they are a Scrum master, but find the person who has that right personality to perform the duties and the hard role of being a servant leader versus somebody who just wants to tell everyone what to do, but they happen to be a certified Scrum master.

Derek: I think Porsche has a great…I think their hiring motto is, “Hire attitude. Train skill.” I like the approach of doing that because I think we find a lot that people who are experts in their field tend to almost have a primadonna‑type nature to them.

The Ruby community especially is famous for this, which is what Bob Martin is ranting about, but I’m sure that the same carries over to the Java world, into the .NET world, and to every other world as well, where if you get a guy who’s an expert, he’s going to demand special privileges above and beyond the rest of the team.

He needs to have a lead in front of his title. He needs to get a higher paycheck and all of that stuff. Really, what that builds is a guy who doesn’t want to work in front of the team because he’s above the team.

Fixed Mindsets

Jade: Usually for me, the warning sign on that is when someone defines themselves as “I am a bloody blah. I am a Ruby programmer. I am a .NET developer.” That, to me, shows a very fixed mindset of that person.

Derek: I think you meant to say “Ruby Ninja,” Jade.

Jade: Yeah, I’m so sorry.

Roy: I solved that by saying, “I am a god.”

[laughter]

Putting Technology Over People In Hiring Is a Mistake

Clayton: I think it’s interesting though that if you’re a hiring manager and you’re saying, “We need more people on this team, and we need more qualified people,” they always want the people that are experts. “We’re trying to find people that know this technology like the back of their hand.” I think it’s a trick question.

At that point, you’re elevating the tools and the technology over the people that you’re actually hiring. I think if you were to ask those people, “Hey, look back in your career, and think of all the great people that you’ve worked with.” I doubt they would say, “I worked with this guy, and he was so awesome because he could recite any Java method, and he knew all the classes” or like some nitty‑gritty technical detail.

It’s never anything like that. It’s people that they enjoyed working with, and they collaborated well with, and they were able to produce great things. They were a friend basically. So I think it’s the wrong question to be asking. You don’t want to be hiring the perfect technical person. You want to be hiring people that for the long term would be good people to work with even though maybe they don’t have the exact skill set right now.

Derek: The only problem I see with hiring good people rather than experts is that it makes it very difficult from an HR standpoint, where you have an HR department, and they are responsible for looking for your candidate.

They need a checklist of stuff to check off before they can get the right person, and if your baseline, like you had mentioned Jade, is too low, then you’re going to get an influx of way too many candidates to go through, which makes it very difficult to single out the really good ones that you want.

I don’t think I really have a good solution for that where you can narrow the stack down because I think a resume is such a really poor way to see what somebody is like that I almost don’t want to see this part of the hiring process. But how do you go through a hundred candidates and find the one guy who’s really going to make your team shine?

Attitude, Aptitude, Ability

Roy: I think that this is a big push right now. I am going back to what you’re talking about, Clayton, is the world is changing so fast. Ruby might be hot and popular now, but in three years, Ruby might not even be a viable language. I don’t know too many people that are looking for Studley COBOL programmers. That loop has gone from a 10 or 15 year arch to a five year arch in technology.

If you go with that attitude aptitude ability, to me attitude certainly is important, but aptitude is the thing that HR department should be looking at. Which is how do we figure out whether somebody is capable of learning new things? The world is going to change significantly during their employment here. How do we make sure that they continue to grow?

Jade: That requires a very different way of hiring. To talk to Roy’s point is, yes this is a problem for HR, but the problem is because of the pre‑existing practices that we have. The way that we are doing things currently are not adaptable for the new world that we’re entering.

This causes systemic change throughout the organization. If you want to hire the best people, you have to find the way to identify the best people and doing it through resume is not going to work.

Derek: With that we’re out of time. I want to add that if you are an HR person or an organization that is currently undergoing an agile transformation and has an HR department that are dealing with some of these issues, we’d love to have you on a future episode of the Scrumcast.

You can get a hold us at facebook.com/agileweekly, and we’d love to hear from you. Until next time, we’ll thank you for joining us. Thanks!

Jade: Thank you.