Blog

Welcome To The Matrix! Organizational Structures to Support Agile [Video]

By Doc List | Aug 17, 2016 |  Agile Transformation,  Article,  Video

An Agile transformation is more than a process change. The organizational structure is affected as well. In a presentation for Keep Austin Agile 2016, Doc List explained how traditional hierarchies are challenged during a transformation and how Agile teams can make it through storming to become high performing.

**Not a transcript word for word. We removed instructions and cleaned up some text. We also apologize for the abrupt ending. We forgot to borrow Hermione’s time turner necklace so we could  be in two places at once.

Get together with someone you don’t work with and talk about organizational challenges you’ve faced with regard to the structure of the organization itself. Who people report to, how the teams are organized, whatever it is, get with a partner. Spend a few minutes, and talk about what the challenges are you’ve faced in your organization.

I would love to hear a little bit of sharing. Does anybody want to share a little bit?

“So we’re going into the end of our second year from an IT agile transformation, and similar to what I have seen at some other companies, is the culture, leadership buy-in, and then how do you structure the teams.” Do you have a centralized group of ScrumMaster or decentral?

“We’ve had a centralized group of ScrumMasters, but I think we are starting to decentralize- probably a little early but that’s something we’re going through.”

Anyone else?

“We work for Match. We’re going through our agile transformation. We are going over the hurdles of senior leadership sponsorship, what does the organization look like now that it is an Agile organization. It’s very top down, we are trying to do grass roots, very deep and narrow with it so that we can go broad.”

Ok, so some big organizational issues there. I want to talk about a particular kind of challenge that I’m trying to address when I work with organizations.

So I’ve been thinking about this stuff for a long time, and in the last 7-8 years, I’ve focused on the enterprise level, working with leaders and so forth, and I’ve discovered some challenges that seem to be fairly common.

Meet Elwood, say Hi Elwood. Elwood reports to Ella, and then Ella reports to Norman. Elwood is a software developer, and here is the challenge that Elwood has: He likes writing code, he doesn’t want to deal with the organizational issues, he doesn’t want to deal with political stuff, he wants to write code. That’s what he loves.

The problem is that Elwood is on a team that’s supposedly an Agile team. There’s a mix of people on the team. There’s developers, and QA/testers, designers, database developers. It’s a typical cross-functional Agile team in an organization.

Developers like Elwood report to a development manager, a technical manager. The testers, the QA people report to a QA manager, which in this case happens to be named Ashish. The designer on the team reports to the design manager named Flo. And finally, the database developer reports to the database manager.

They’re very silo-based, management and leadership. Now, of course, each of these people reports to somebody else. I mentioned that Ella reports to Norman, and so does Ashish. Flo reports to Ernie, and Armand reports to Rebecca. So it looks like a typical organization, but the thing is we have these so called Agile teams. They’re cross-functional, working together, and committed to the same goals.

CARGO

I talk about shared CARGO, and CARGO stands for shared Commitment, shared Accountability, shared Responsibility, shared Goals, and shared Ownership.

So we’ve got these teams, and we said to them “we expect you to be committed to the goal. The goal of the sprint, the goal of the project, and work together to become high performing.”

You guys all know the Bruce Tuckman model- forming, storming, norming and performing. He studied a lot of groups and what he found is that all groups go through those four stages, and every time you change them up they’ll go through at least the first three.

There’s forming- coming together, storming- arguing, sharing opinions, sharing difference, norming- learning how to work together, and then performing–which is what most of us call high performing.

So the goal in creating these teams is to enable them to become high performing because you don’t become high performing overnight. We don’t want to mess with the teams. We’ve got the database developers that are reporting to Armand, the designers are reporting to Flo, the testers are reporting to Ashish, and the developers are reporting to Ella. But they’re all on one team together with shared CARGO. So what typically happens?

Here’s what I’d like you to do, thinking about being on, or being involved in an Agile team. What are some of the challenges that occur? What you might call dysfunctions or organizational glitches.

I don’t know about you guys but I have referred to frAgile, which is, of course, the easily broken version. Then there is quAgile, which is the quasi Agile in which we adopt a little of this, and a little of that, and then we say it’s Agile. I recently came up with squAgile, which is short for squamous Agile which it’s actually destructive and keeps growing.

So here is what I run into. Elwood reports to Ella. Ella says you know, “I need you to do something,” so sort of related to what some of you talked about. “I need you to come help me with this. I know you’re on a team over here but you report to me, and I need some work done and you’re the only one that can do it for me.” Now, what is Elwood going to say? She’s his boss. He doesn’t feel like he can say no. He doesn’t feel good about saying yes.

What’s he going to say to his team who depend on him to do his job, to meet their velocity, to meet their commitments, their forecasts? So he says, “but it’s not on our sprint backlog” because we’ve taught him. He’s taken all the classes. We’ve educated him. We got a ScrumMaster, and we’ve got a product owner and we’ve said all your work comes to you through the sprint backlog, and you’re not supposed to work on anything else. Now Ella comes along, “Elwood, I need you to do this for me. Reviews are coming up soon.. You can say no if you want Elwood… ” What is Elwood going to do?

This is a dilemma we see over, and over, and over again because on the team there is no one manager. We have a ScrumMaster but the ScrumMaster doesn’t really have the authority, although we would like them to. They’re the sheepdog, they protect the team. When a manager comes along and says “I need this” the ScrumMaster is sometimes at their mercy. I’ve seen this just way, way, way too many times.

So we have Ella, and she is not the only one. Some of you work in organizations where the people from sales or marketing are used to calling the developers and saying “I’ve got a client, and if you can just get this feature done in the next week we can make a sale.” Because of the way the organization used to be, they are used to being responsive.

This creates confusion and ambiguity in the minds of the people who are doing the work. We’ve said we’re doing Agile, and Agile is really about disambiguating this. Because the goal is to be on this cross-functional team and have clear goals that we share, that the organization is behind.

Criss-Cross Chaos

Sara said, “they’re having a problem trying to do it from the grassroots up because they’re not clear that they have the right support from up here.”

Even organizations that have the support from up here run into this stuff. This is what I’ve been calling criss-cross chaos. I ran into this in another organization, it was the database manager who said all those other people report to the VP of development, except the database developers, and they’re mine. I get to set their priorities, and I get to set their work, and I get to tell them when I want them to do something different. And I get to tell them how to work even though they’re on an Agile team and we’re embracing Agile, except for me and I get to do things the way I want.

So this is the challenge I see. If I am that developer, database developer, or that designer and I keep getting pulled off, I start to feel like I’m not having a good time here. I can’t ever contribute significantly to the success of my team if this keeps happening. It becomes a pattern of behavior. If one does it, then another one can do it, and now they’re all doing it. And that’s what I see happen in these organizations, if he can get away with it then I can get away with it. It’s the stars that get pulled off and they run to the rescue of everyone else. In my facilitation patterns that’s the super hero. I swoop in and I save the day. They start to believe that about themselves.

I tend to talk in utopian terms and then live in the real world. What I mean by that is I say, an Agile team succeeds or fails together. I think you understand that but to be clear, what I mean is I would go radical and say when you do reviews, then a significant chunk of every individual’s review should be based on how well their team did.

I don’t care if they were the star or the villain. You can have a star on the team that sucks, and you can have a villain on a team that is hugely successful. I don’t care because for the team to succeed they have to have made their contribution to the team succeeding as a team. In an Agile organization that is what I would like to see, that people are evaluated based on how the team does.

As many of you have pointed out, now I’ve got someone who the manager is going to say, “Boy this is the guy I can count on, this is the woman I know that if I need something done, I’ll call on them and they’ll get it done,” to the detriment of the rest of the members on the team.

The Matrix

Here’s the way I think of it. I’ve got an Agile team and on the Agile team I’ve got these different specialties, roles, functions, call them whatever you’d like it’s a cross functional team and they all have this thing that I’m referring to as shared CARGO. The ownership is really important to me because once I hand them the goal- I have these what I call mantras about Agile.

One of them is given a reasonable group of intelligent people reasonably clear goals and the authority, responsibility, and ownership to get it done and they’ll figure it out. Do this with six-year-olds, say make up a game and they will. Do it with a group of volunteers, say here you guys are responsible for this, and they’ll figure it out. So why not an Agile team?

We’ve got an Agile team, they’re learning how to work together effectively to be this cross-functional, self-organizing, wonderful team. I propose that instead of having technical managers, managers who are an expert in a particular role, development, QA, UX design, whatever it is. That the teams as a whole report to a manager, whose job is what some would call an HR manager. Their responsibility is all the administration, operation, logistics, PTO approvals, training approvals, and whatever is organizational stuff. They don’t have to be experts in the technical domain. They don’t even have to be experts in the product domain. I’m not saying it hurts, I’m not saying you should avoid someone because they understand what you build. What I am saying is that they should be good managers. They should be focused on the skill, the talent, the joy of management.

Now I was a technical guy, I looked at management and said:” I want to do that.” As a result, I studied it and worked at it. A lot of us get told the next step up for you – what’s your name? Oliver. Are you a developer? Ahh, how lucky was that?

So Oliver is a developer and his boss says the next step up for you, to move in your career here is to become a technical manager. Oliver may never have thought about being a manager, may not want to be a manager but now he is placed in the position of if I want to get ahead I got to be a manager. There are way too many people who are in that position, and some of them turn into outstanding managers and some of them will never be good managers. They just don’t want to, they don’t care. They just got pushed into that position. I propose that we have people who care about management and they’re professional managers. They may have a technical background, they may not, I don’t care as long as they are good managers.

Come up with ten characteristics/ responsibilities of what I’ve defined as a functional manager. The way you do this is stand up, call it out and sit down. We have one minute. Let me set my timer. Ready? Go.

“Good communicator, trustworthy, loyal, unbiased, empathetic, passionate, smart, administratively competent, and decisive.”

I’ve got them all. We’ve got good communicator, decisive, loyal, trustworthy- they are boy scouts/ cub scouts.That’s what we want in a manager.

Granted I set the context for you that they’re not a deep technical manager. Realistically, I can get technical expertise elsewhere. It may not be common but I can find it, I can hire somebody who is technically competent. What’s harder is trying to find somebody who is technically competent and a good manager, so let’s stop trying.

Let’s get these really good functional managers and have most people on the team report to them. Now, there is no conflict because when it comes to my commitment on a day to day basis I report to one person, and only one person. Everybody on the team, except for one, reports to that person.

And I say everybody but one because I like to still see product owners report to a product focused organization. It gives us the checks and balances we need to make sure we don’t start navel gazing. We don’t start building cool technical things because they’re cool technical things. Rather we maintain that focus on delivering value to our customers, users, organization. Now I’ve got everybody except the product owners reporting to a product organization.

I’ve seen it work as well where the ScrumMasters all report to the equivalent of a PMO, we’ll call it an SMO, ScrumMaster Organization.That works, my only concern is if there is any conflict there. What we really want, in both cases, is the communication across the teams and between the people in each role. To do that I propose that we take this concept of Communities of Practice, which I’m sure many of you have heard of, and we implement it as an organizational part of our structure.

Community of Practice

What is a community of practice? What’s the purpose of it? What’s the value of it? Why would I suggest this in this organization? Let’s take a few minutes. Talk to anybody you’d like, except for me. I’m gonna make it three minutes. Go ahead and have a conversation. What are your thoughts about Communities of Practice?  Fresh outs, good I like that term. If you could hear Ted, he said he partnered up with a guy and they started doing coding dojos for fresh outs to teach them stuff that they didn’t learn in school.

Let’s have a Community of Practice of ScrumMasters. In which it is not just a scrum of scrums where they come together once in awhile. Whether it’s everyday or every week to say here’s what’s going on in our projects, instead talk about being scrummasters, talk about what’s the learning that’s going on in scrummaster community, what’s evolving in the Agile community, how do we bring more as the guides, mentors, and coaches of our teams. The people in the organization who are expected to know a bunch about Agile and help the organization develop it.

How about if we have groups of developers, testers, and so forth be inclusive. If you want to know more about testing, go to whatever it is that the testing Community of Practice does. If you want to know what the heck is UX, go to the UX Community of Practice. Don’t just take their wireframes and their designs, go learn what they do. Go learn about personas in depth, or how they come up with what colors to use.

The goal here is to separate the functional stuff. We’re an organization, we have management things we have to do, we have administrative stuff we have to do. There is all of this overhead. Let’s have somebody who loves that, do that. Then let’s have people who love this, lead, guide, or be the custodian for the Community of Practice. Somebody has to be responsible for what are our standards? How do we as an organization choose to do things? If we’re writing Java, do we have particular patterns we want to use? Particular ways of putting the code together? If we’re doing database, do we have standards around stored procedures and what indexes we create?

Whatever it is should come out of this organization not somebody sitting up here, separate from the organization. We are also talking about what’s happening across the organization. I don’t think they have to be on the same project, no. This is across the organization. Now we’re creating that expertise that we used to force into a technical manager, senior architect, or the cloud technology person.

 

We’re taking that and putting it in the hands of the people who do the work, just like we do on the Agile teams. We’re creating this cross-cutting structure that eliminates the duality. Now nobody gets to come to Elwood and say “Elwood, I need you to do something for me” because Elwood’s only manager is the same as the manager of the designer, the database developer, the UX designer, the testers, and the QA people. They all have one manager. And now if somebody else comes along that manager says “no, it’s not the way we work.” This is one of the dysfunctions that I’ve seen over, and over, and over again that i’m trying to see if we can make go away.

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back