Clayton Lengel-Zigich, Roy van de Water, Jade Meskill, Derek Neighbors and Alan Dayley discuss:

• Roles
• Collective Ownership

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile whenever you feel like it podcast.

[laughter]

Clayton:  My name is Clayton Lengel‑Zigich.

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

Derek Neighbors:  I’m Derek Neighbors.

Jade Meskill:  Sometimes I’m Jade Meskill.

Alan Dayley:  I’m Alan Dayley.

Clayton:  Today, we have our special guest, Alan, and Alan wanted to talk about roles versus collective ownership.

Alan:  It’s been fascinating to me recently that I’ve had lots of discussions with people and have been seeing lots of discussions online and in real life about people trying to define roles. It’s your job to do this and your job to do that. The product owner should be the one grooming the backlog therefore the development team doesn’t have to do that.

So and so should be deciding who’s on the teams. This is a problem, it’s not mine to solve because that’s somebody else’s role, or somebody else’s power. It seems like we spend so much time defining roles and boundaries of authority that we could use that time to actually solve stuff.

I wanted to talk about the usefulness of roles and I think they are useful in certain situations but we’re also roles versus collective ownership. How do we come to the point where we all realize we’re on the same boat and we can all do whatever it takes to get that boat where it needs to go?

Jade:  I saw an interesting definition of what differentiates a group from a team and the definition was, “a group becomes a team when they accept responsibility for their actions.”

Roy:  Like collective responsibility?

Jade:  Yeah, as a whole unit, we accept the consequences of our actions. That’s a defining moment when a group becomes a team.

Roy:  If you were to overhear a team talking, you’d hear it in their language. Somebody would start saying, “Oh, we messed it up here.” Even if that person was not necessarily…

[crosstalk]

Jade:  Had nothing to do with actually doing the doing.

Alan:  In other words, you’re saying, in the retrospective, I could say, “Jade, you let us down,” but when I’m outside the retrospective, I’m going to say, “The team failed. We failed.”

Jade:  Yeah.

Derek:  I think go straight to these personalities because I like them.

[laughter]

Roy:  I don’t understand them.

Derek:  I know, you’ll get this one right and…

[laughter]

Derek:  Soccer is my favorite example of this and every team that’s won the world cup, probably, since the late ’70s has been influenced by a style of Dutch football.

It will be called “total football” here and it was something that was a radical transformation going from positional play where you had, “Hey, you’re a forward, you play forward, you attack. You’re a mid‑fielder, you possess the ball. You’re a defender, you defend.” to basically training children from a very young age all aspects of football, so that when they would step on a pitch there were no real positions.

You might start in one particular position, but throughout the game you just went wherever you needed to go. All of the people were interchangeable, short of the goalie, or the keeper. That that style was so successful that almost every program has adopted that mentality of, “You no longer just train for one thing, you have to be a complete player regardless of where the position is.”

We’re starting to see that mentality happen in software teams, where you no longer can have the database person, or the designer person, or the front‑end person, or the developer person. You really want people that are well‑rounded. You might have people that start in a certain position and have a strength towards that, or a role, and have a strength towards that role.

But teams that are like “I can’t do that because that’s not my…the scrum master left and I’m not the scrum master, so I can’t do it,” they’re doomed. The teams are like, “Hey, the scrum master is gone this week, somebody else will step in and we’ll just do it, and keep rolling.”

Those are the teams that are adaptable. I think that that starts to reinforce the “It’s everybody’s job to score a goal, it’s everybody’s job to stop a goal.” Same sort of thing. If our results are owned together, there is no “Well, it’s the defense’s fault that we lost.”

Clayton:  That’s a good point. I was going to say that the time that I hear people talking about roles the most are when blame is happening, when someone is trying to blame somebody…

Jade:  It’s when blame is important.

Clayton:  Huh?

Jade:  When blame is important.

Clayton:  Right, yeah. I don’t think I’ve ever really seen a team where they did something that was successful, and they singled people out in that regard. Everyone’s OK with sharing some of the credit, but when someone needs to be in trouble, or we need to blame somebody, that’s when the role stuff comes up.

A lot of like, dealing with conflict, like management type stuff comes up, especially the old hierarchies. Like having teams where they have been trying to be, maybe, a cross‑functional team. Maybe they’re trying to be, like, having collective ownership.

But the second something bad happens or someone needs to assert power about how a situation should happen, they revert to the two‑year‑old way of doing things where it’s like, “I know that you’re part of this team and everything, but like, you are from the QA organization. Even though you haven’t done that for two years, but I’m a developer.”

That used to mean something two years ago. “But I’m still going to go all the way back to that issue, so that I can assert this thing over and say that we’re going to do it this way.” It’s always the negative stuff when the roles come up.

Alan:  So let me flip that around a little bit. I’ve been in environments where people defend their roles because that’s what has always made them valuable. So, “I am a valuable tester,” or “I am a valuable manager,” project manager, or just a dev manager. Just take the dev manager for example. I’m a valuable dev manager, I need to know what’s wrong in the team therefore I must attend the retrospectives.

That may be a positive thing, depending on the relationship of the manager. But to me, sometimes, it feels like people are trying to hang on to what they know from 20 years of working that way so that they can hang on to what they see as the way that they contribute value.

Clayton:  I think people that have got to a certain point in the organization or their career by specializing in being something to come in and say, “Hey, we’re pretending that’s not super important.” What really matters is that the whole team is responsible for the outcome and has to own whatever happens. That’s a hard pill to swallow, I think, for those people.

Derek:  I’m not going to hijack the conversation but this is largely because that’s how we do performance. We do individual performance reviews that say, “You’re good developers. We’re going to promote you to a developer leader.” “You’re a really good developer leader. We’re going to promote you to a developer manager.”

Their whole career, they’ve been trained that their individual results are what they get rewarded on. When we talk about sharing the outcome, why the whole should I share the outcome because how I get compensated isn’t shared. If how I get compensated isn’t shared, what benefit is there for me to share?

When you start to change the conversation away from individual performance and start to put it towards team results or product results, people get scared really quick because, now, the next thing that you’re going to say is that reward is based on results. Damn it, for 20 years, nobody’s ever made me get results. I don’t know how to do that.

I’m afraid that maybe Jade doesn’t know how to do that, Clayton doesn’t know how to do that. Now, all these accolades, benefits, and everything that I’ve gotten from effort are going away, I’m scared. That’s what they’re really saying is, “I’m afraid of losing the title because there’s something tied to that title that’s so much deeper.”

There’s authority tied into it. There’s reward tied into it. There’s so much tied into it that the unknown is just too scary to let go of.

Jade:  Why are roles important then? What’s good about them?

Alan:  I wanted to swing back around to that.

Roy:  In one case where, I think, roles are important is in the finding a clear path of authority. We’ve talked about the idea of a perfect manager who comes in, drops an end result on a team and then goes off into the background until the task is done.

You have to have somebody that define role and they can’t be a member of that team. That just doesn’t work.

Jade:  Why are scrum have roles then? Why are they defined that way?

Alan:  My answer to that would be to say that scrum, scrum using term as an example, XP has some similar roles but, I think, the roles that are defined in these frameworks so that you know there are certain areas to focus on.

There needs to be somebody defining what the product does. There needs to be somebody paying attention to how the process works. It’s not necessarily trying to say we need a role, a title, somebody to own this and nobody else can do it.

Roy:  In some cases, there are though.

Alan:  Yes because we twist that.

Roy:  Right, exactly. The product owner is often times called the “single ring of a neck.” Right?

Alan:  Right, which I don’t agree with.

Derek:  I think some of that is like a Dreyfus model type of problem. Like you said, most software development teams, especially 10 years ago, didn’t have the concept of a product person. Didn’t have the concept to someone hoping and deal with organization on impediments or impediments outside of the team.

Scrum was very prescriptive and said, “Hey, every high‑performing team we’ve seen has people that do these things.” We should probably say that every team should have this behavior happening in it. The easiest way to do that in introducing that the corporate America is say make a job title around it that you can fill the position then it will guaranteed that somebody will get it done.

Roy:  I think that’s an important part of why those exist too is that there’s a whole existing workforce of people that filled similar roles in the old organization that now need a new roles. Just provide an easy way to slide them over horizontally to like, “OK. You used to be a product manager, now you’re a product owner. You used to be a whatever, now you’re a scrum master.”

Derek:  And as you see teams evolve that adapt say strict scrum and have those roles, over time they start to realize that those roles don’t make a ton of sense. Some of this is their organization starts to evolve, developers become more in‑tuned to doing product work and it’s not just about development.

And an organization has less impediments, because they are learning how to organize in ways that have less road blocks. So you start to see those maybe dissolve its roles and just become traits of teams.

The teams have a trait that they know how to do a product, and the teams have trait that they know how to get rid of impediments. It’s not a one person’s job to do these things.

Alan:  I think it’s fabulous. The concept of a cross‑functional team is what helps to dissolve those boundaries. Even if we have a traditionally siloed organization and traditionally “I am always a tester and will never be anything else.”

Once you tell me, and require me, to work a year with people with other skills, if I truly am working with them every day, and we’re doing stories that are focused on the user instead of focused on technical tasks. Now, suddenly by the end of that year, I am familiar with other skills, I am familiar with how other things work and I begin to break down those barriers.

Roy:  It’s interesting though, because people at first have very much difficulty with the concept of being cross‑functional in a technical sense, so the same person touches a database, touches the front‑end, touches the back‑end, touches the UI that the user sees…

Jade:  It’s with the customers…

Roy:  …and does testing. But doesn’t meet with the customers.

[laughter]

Roy:  People are OK with that first jump and even that’s a big jump for them, but then to make the jump from “OK, now I’m cross‑functional technically, but I’m going to jump out of my technical comfort zone and into the murky area of dealing with customers and thinking about product.”

People are not ready for that, most people are not very willing to make that jump, by themselves.

Clayton:  One thing I think it’s interesting is with teams that have been doing Scrum for a while maybe they would have started with of prescriptive approach of “We have this one person and they are the Scrum Master, they do the Scrum Master things.”

Over time they usually ‑‑ not for the right reasons ‑‑ but they will start blending those roles and be “Well, let the Scrum Master allowed to go do some other thing and we didn’t really want to hire someone else because it’s hard to justify that job now, the lead developer, they’re kind of the Scrum Master too and they just do both things”.

Under the guise of “Oh, the roles aren’t really important” they just blend all that stuff together and you end up with a bad experience, where you don’t get great outcomes because you don’t have somebody that is dedicated to doing certain things.

Usually those teams are mature enough to make that choice, and that’s immature teams usually don’t make that choice, but that’s something that I’ve seen on some teams that maybe would consider themselves a little bit more mature from an Agile perspectives is that they’re blending all that stuff together, as if roles don’t mean anything.

Alan:  If you blend too soon you become…It’s Scrum Master the role that gets blended the most, right?

Clayton:  Yeah.

Alan:  I certainly can agree that certain mature teams, high‑performing teams, can get to a point where they don’t need a Scrum Master because all of them are so good, are looking for improvements, and they just do it as a team.

That’s great, but so often teams go four months, five months and they say, “We’re under pressure now, so the Scrum Master used to be a developer, he’ll just start writing code.” In that focus, and I like to talk about it as focus as opposed to saying “This is your role at the team you have to do,” that focus on improvement, it gets diluted and…

[crosstalk]

Roy:  “We don’t have time to get better, we got to deliver now.”

Alan:  One of the things that I’ve seen done with teams, and I haven’t done it yet, I’m very anxious to do it again with another team, is where…I’m a big fan of teamwork agreements but I’ve seen it done where you get down to a team member agreements.

In other words the product owner has a priority of the things that he can do, the things that he agrees to do, and so when something outside of the product owner role and a product owner thing compete with each other, he has a priority of how to choose which action he should take. That keeps him in focus in that role.

Roy:  I like the idea of a team being properly aligned in a direction and anybody stepping up into that product role, so there isn’t one guy whose number one priority is product. There may be a guy who has the most experience in it, he might be the guy to go to for help first, but you pull a task off the board and you go and do it.

You don’t save it for the product guy because he happens to be better at it.

Jade:  If you’re putting together a brand new team and you had your choice of how to organize it, how to assemble it, how would you do this? How would you lay out the roles and responsibilities?

Alan:  It would be something that the team builds together themselves. Each of the team members, even when they’re starting out anew, each one knows where the strengths are and where there are not. They’ll have to build it together, the same way they would build a teamwork agreement together, where we expect a user acceptance testing.

These people will attend that and there’s different things to do that they could help to find each other and figure out where the roles are, so they don’t neglect one or another of the focuses that they should have. Focus on product, focus on improvement.

Clayton:  All right, on that note I think we are all out of time. Thanks.

Alan:  Thank you.

[music]

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

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.

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.

Need help with you Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline, it’s free. Call 866‑244‑8656.