Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors discuss:

• Team Culture
• Alpha Developers
• Retrospective Safety

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors:  I’m Derek Neighbors.

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

Clayton:  Today we wanted to start talking about cultural norms or generating the culture of the team. Roy, that’s something you’ve been experiencing lately, so tell us about it.

Roy:  I have been working with a team for the last few weeks. We really have started to generate more and more stress…a switch‑over to one‑day iterations. That has started bringing things that were always there to a head.

Now we have to start to deal with them because it’s no longer able…in the past, we get to say, “Hey, we’ll get to it on Friday when it’s an issue.” Now that we’re having this issue every single day, it’s becoming something we have to deal with…it’s pretty cool.

Clayton:  What’s it been like with the different personalities on the team? Do you feel like the team is catering to certain people ‑‑ maybe they have more seniority? How’s that shaking out?

Roy:  I don’t necessarily think that matters ‑‑ seniority ‑‑ in our case we have some personalities that are cruder and more vulgar, and, in some cases more childish. Myself included.

[laughter]

We have some people that are a little bit more straight‑laced, and that are bothered by some of our antics. In this particular issue, there are other issues that come up. It feels like we’re a team of a bunch of alpha‑people, so we argue a lot.

Clayton:  So, lots of alpha‑males or people that want to be alpha‑males that are trying to find their place in the pecking order?

Roy:  Mm‑hmm.

Clayton:  Derek, you’ve been dealing with a team that’s adopting scrum, or trying to get a little bit more serious about it, that has some of those personalities. What’s that been like?

Derek:  I think that one of the things that is difficult is often times people will say they’re in a team…in reality the team definition is simply a group of people that all have a reporting structure that is shared, or a group of people that all sit in the same area of the office. There is no real team happening. When work gets done it’s independently divvied out and there’s no collaboration happening.

I think that for this particular team there is an alpha personality. An example…this person does all the estimating for the team, all the counter‑views, this person is the only person that is allowed to deploy the software to the target production environment for the team.

As the team is starting to take a little bit more ownership for work, they want to improve. Part of their improvement is they want to talk about “Can we start to swarm on work instead of each one of us take a story for our self for the entire sprint. Can maybe three of us work on the same story and how do we break that up”?

The person that is normally in control of everything, this is a rage‑infilled behavior for them. This is just not acceptable on every single level that they don’t even know how to respond. So much so that they basically throw out all the work of the team and basically say “I’m going to tell you who’s going to do what work.”

What’s interesting to me is this is not a manager, this is just a developer on the team. This is somebody who says what they’re allowed to do and what other people are allowed to do.

It is a dynamic that I think some people are seeing some empowerment, and are able to fight against now, and getting some support from management and external co‑teams to say “No it’s OK for you to do this,” and the person is seeing their world be torn apart and is not happy about it at all.

Roy:  I think everyone listening has either worked on a team with someone like that or maybe has been that person themselves or has experience with that. We highlighted that it is a negative behavior, but what can you really do if you have someone like that on your team so that they can be more collaborative and they can be more part of the team and they are not the code police?

Derek:  Some of it is figuring out why they are the code police. It might be that for a long time that they were the only ones responsible or ever held accountable when something went wrong. So “If I’m the only one getting slapped when something goes wrong, I’m probably going to make sure that I am going to control everything possible to make something not go wrong.”

Or maybe, “I inherited really crappy architecture when I started this job and it took me two years to clean up the mess from whoever was before me and I’ll be damned if I am going to let a bunch of junior idiots come in and tear my code masterpiece to hell.”

It’s finding out what makes them tick and trying to show them how they have safety in a team and that they can actually do some of those things better without expending that amount of effort. I suspect most of them don’t want to work 70 hours and have to micro‑manage every line of code. They’re doing that because there’s some other thing involved that’s making them do that.

If you can say “Hey, you can get all of the things you currently want, but without having to command and control your teammates,” that’s a win‑win for everybody. I think it’s investigating what that is and trying to show them techniques or ways to basically move around that.

Clayton:  Roy, when you’ve ‑‑ in the other team you’re on ‑‑ been experiencing this generation of culture and the culture stuff, have you noticed any of the people that are more senior members on that team having a hard time making decisions or participating in a certain way?

They’re used to acting in a certain way and having veto power, but now that they are on this collaborative team where everyone’s input is supposed to be more equal, have you noticed anything like that that’s been difficult?

Roy:  Not really because on our team, everybody has the exact same veto power which is absolute veto power. We used the Core Protocol’s Decider, so all decisions must be unanimous.

There’s been a lot more argument than there probably would have been. In the past, seniors members could have said, “It will be this way. No argument.” They can’t really do that anymore.

Overall that’s a good thing and I think even the senior people would agree that this discussion is driving better ideas and is driving us to…now, a junior member comes up with a crazy idea, and we incorporate that and come up with something that’s way better than any individual could have come up with by themselves.

Clayton:  Derek, the example you mentioned where the guy came back in and redid everything and seems like he blew up a little bit, I think for a team or maybe an organization that’s trying to make a cultural shift, those are the cues where someone that is afraid of conflict or has more traditional mindsets is going to put the brakes on and want to hold off. That’s probably the wrong thing to do, right?

Derek:  Yeah. I think it was interesting because this team happens to be doing scrum, they believe they’re doing scrum. I would say they’re not really doing scrum, but they do have a scrum master.

Clayton:  So they’re doing scrum, right?

Derek:  Yeah, I believe that the scrum master knew this behavior was not kosher, was counterproductive, but they had nothing in their toolkit to say, “I’m going to prevent you from going off and doing this crazy thing and redoing the planning meeting all by yourself in the vacuum and delivering a PMP level schedule back for when things are going to be done and who’s going to do them and everything else.”

They knew that was totally wrong, but they didn’t know how to deal with the person. The best that they could do is say, “OK. Well, if you’re going to do that then I’m going to hold you ‑‑ hell or high water ‑‑ to that schedule, and if you’re one minute off from that schedule, this is going to be how I’m going to say, ‘That’s why we don’t do it that way,'” which is not necessarily a good response.

It was nice that they didn’t just dig their feet in and say, “We’re not going to try to improve because somebody on the team has got a problem with it.” At the same time, one of the things that’s difficult about change is if you do not have people around that know how to deal with change and with personalities, you just say, “Hey, yeah we still want to change, but I don’t know how do we tell him no.”

Roy:  How can you tell a change is good change or bad change?

Derek:  The upper management team, when they heard this was happening, I think their initial thing was, “Do we need to fire the person?” I was like, “Whoa, whoa, whoa.”

That sets all sorts of bad precedents ‑‑ you go against what somebody wants, and that means you get fired. That’s not the culture you want either. At the team level, it’s, “Nobody has ever told this guy no before, so how do we do that?”

Clayton:  Do you think that if you were a scrum team that was doing more traditional scrum, and you’re having your retrospectives…I would assume that that’s the kind of thing that would come out in the retrospective about that behavior. What do you think led to this going on for so long?

Roy:  Not knowing much about the situation other than what we’ve briefly talked about in this podcast, my guess would be that the retrospectives don’t feel like a very safe environment to bring this type of stuff up.

Either retrospectives aren’t frequent or not happening, or when the retrospectives are happening, nobody feels like they are in a safe environment where they can bring up anything like this without getting totally shot down.

Derek:  I suspect that more than anything the retrospectives are probably a little bit shallow. I’ve only seen half of the retrospectives that this team has done, so I can’t really speak to it. But it definitely seemed like a fairly shallow, [sounding bored and disinterested] “Hey, does anybody have anything we want to improve? OK. Do you have anything you want to change? OK.”

Not a whole lot of techniques used to provide safety to people…I don’t think there was necessarily any kind of hostile environment during that, but I don’t think that there were the typical tools that a good facilitator would use to try to deal with some of these problems.

One of the other things is it’s just the way that they work. People don’t think, “Hey, maybe we would change this” or “Hey, this could be different.”

Roy:  Instead of abiding and perceiving that there’s a problem.

Derek:  A great example is during their planning meeting, this particular individual was not there. They were tasking some stuff out, and it came down to “We can’t task this out because so‑and‑so is not here.” It was great because their manager said, “What do we do?” I said, “Why can only one person do this?”

Ultimately, their manager really pushed them and said, “So you’re not capable, Clayton, of doing a database change?” Clayton said, “No, I am.” He said, “Then why can’t you task it out?” “Well, because Roy says that we’re not allowed to do that. Only he’s allowed to do that.”

Roy:  This is true by the way. [laughs]

Derek:  The manager says, “Well, I don’t care. If you’re capable of doing that, I trust you to do it. Task it out.” The look on that developer’s face is, [shocked] “Oh, wow! I’m allowed to do that.”

They wouldn’t even think to question it. I think we forget how programmed people get where it’s, “Well, that’s not my job. That’s someone else’s job.” When it comes to retrospective, I’m not thinking, “How can I get Roy’s job so that I can do database work.”

Clayton:  Let’s just say that’s the culture. The men go out and hunt, and it’s, “Could a woman go along and hunt too?” Probably, but that’s not what they do. That’s not how the culture works, so that’s crazy to even promote…suggest that idea.

Roy:  We see this all the time with QA people. “Man, that QA person touches code like ‘Ooh!'” They might fully know how to do some automation. They might already be doing some code like bud.

Derek:  It’s funny when you talk to some people that are in that QA or tester space. There’s a lot of them that on their own or at some other job have some experience with the code.

Whenever they talk about it, you can tell how bad the culture is by how much they diminish their own skills. “Well, I’m a QA person. Yeah, I’ve done some Java stuff. I’m really bad. I really don’t know what I’m doing.”

That speaks to the culture that they’ve got going on, wherever that is. Roy even hinted at people not feeling safe in the retrospective ‑‑ a place where you can feel safe and share your feelings and talk about things.

Roy:  Right.

Derek:  Are you talking more about people on the team? I might say something in retrospective and some of my team would be upset? Or is it something management would hear about and use it against me?

Roy:  I assume that in Derek’s case it would be more of a team‑related thing where I would be the alpha person, and you’d bring something up. Then I would shoot you down and be, [angrily] “Well, that’s because I know more than you, and I have more experience. Can you just shut up and don’t bring that up again”?

The other option you’ve mentioned, I’ve seen happen as well, where something’s been brought up in a retrospective, and a manager finds out about it and one by one interrogates every member on the team to try to figure out who said it, so they can do who knows what.

Clayton:  They feel or I guess there was something that they didn’t know.

Roy:  If you don’t feel safe inside a retrospective, you’re not going to get anything accomplished. That’s the type of area where everybody should bring up the things that are really bothering them, so you can move forward as quickly as possible. If the team doesn’t feel safe, it’s not going to get brought up, and then you’re not going to make the changes that you need to.

Clayton:  Derek, you’ve mentioned these people having “teams” where it’s just a collection of individuals that are loosely grouped together. I think anyone in that situation is going to feel very vulnerable to express some problem they have.

Roy:  They don’t even know each other. I talked to a team last week where there were some members of the team that didn’t even know other members of their own team’s names.

Clayton:  The “team” right?

Roy:  I have seen that quite a bit actually [laughs] .

Derek:  It’s really difficult. As a coach, one of the things I really try to do is mimic the things that I’m saying that other people should do. I’m real big on that managers should be highly transparent and open. So one of the things that I do is I tend to keep coaching journals.

In my coaching journals, I’m really wide open ‑‑ I criticize things probably overly a lot of times. I really struggle ‑‑ do I give access to those journals to the management teams that I’m working with? My biggest reason not to, often is I don’t believe they can express the maturity to be able to handle what’s in those in healthy ways.

I think it would be vitally important for them to see what’s happening within their teams and in these ceremonies if they were taking that information and saying, “Hey, can I do some things infrastructure‑wise or organizationally to help deal with that?”

But what they tend to do is look at the personal things and say either, “I’m going to go fix the personal thing” or “Ooh, that really pissed me off. How dare somebody say that about my organization?” and be punitive about it which is just non‑helpful.

Retrospectives to me are the same way ‑‑ do you give that data to people outside of the team? Part of the answer is, “Absolutely! Somebody should be able to, outside of the team, see that data.”

But the problem is we’re human beings, and we act stupid all the time, and if you do that, you lose a lot of the safety involved. I think some managers demand, “I want to see what’s coming out of the retrospective because I want to make sure,” in the guise of, “I want to be able to help the team,” in reality, “I want to see what the team’s talking about, so I can go flip my lid.”

Roy:  Ultimately it should be up to the team themselves because a team that is first storming is going to be extremely protective of their opinions and want to keep that to themselves.

As they mature, they will start to grow trust amongst each other. When they say something, even if the rest of the team disagrees with it, they know that the rest of the team will have their back. That’s when they start being more OK with having that type of stuff be open.

If a manager goes out and goes, “What the heck were you doing saying that about me?” the rest of the team is going to back him up and be, “Hey, this is a retrospective. They have the right to say that opinion. Back off of our team member.”

Derek:  Yeah, I definitely think it should be up to the team.

In the current engagement I’m on, I’m lucky enough to be doing some pair coaching, so it’s nice I’m able to open that up to my pair coach and be able to get some of that organizational feedback, and have the safety that that person is in the same boat. They’re putting their notes up as well, so we’re able to help each other out, which is really nice.

Clayton:  Great. Well, I think we’re about out of time. So thanks guys.

[music]

Clayton:  If there’s something you’d like to hear in the future episode, head over to Integrumtech.com/podcast where you can suggest a topic or a guest.

Announcer 1:  Looking for an easy way to stay up to date with the latest news, techniques, and events in the agile community? Sign up today at Agileweekly.com. It’s the best agile content delivered weekly for free.

Announcer 2:  The agile weekly podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out Integrumtech.com or subscribe on iTunes.

Announcer 3:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the agile hotline. It’s free. Call (866) 244‑8656