Roy van de Water, Derek Neighbors, Clayton Lengel-Zigich, and Jade Meskill discuss the benefits of smaller teams.

 

Transcript

Jade Meskill:  Hello, welcome to the Agile weekly podcast. I’m Jade Meskill.

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

Derek Neighbors:  I’m Derek Neighbors.

Clayton Lengal‑Zigich:  Clayton Lengal‑Zigich.

Jade:  [laughs] We’re a little eager. We want to talk about team size today. We don’t necessarily want to talk about what is the exact right size for a team, but what are the advantages and disadvantages of teams of certain sizes.

Derek:  I’ve seen a lot, in a group that I’m working with, where the teams aren’t obnoxiously large, you’re not talking of 30‑person team. There’s been a lot of change, the teams in a lot of ways would be acceptable team size, they might be between 8 and 12 people, which is not abnormally large, but not on the smaller side either.

And some of the things that people are asking are can we really improve more if we continue to have these size teams, or if we were to go to smaller teams, could we actually do things better than we’re currently doing now? Would that make a difference?

Would it make a difference if we…and some of this is because they have more products that they want to introduce and so they really can’t go hire more people. Product owner or product manager says we really need this other additional product, but we don’t have people to put on that team because they no longer do the project madness.

They actually line people up to products and they belong to a product and they stay with the product, and they really own it which is awesome, but now, hey we’ve got this new product that we want to start.

We’re not allowed to hire people right now. How do we staff that product? They’re talking about what if we had formed a new team, but that would mean some of the other teams would get smaller. Would we get a better result from that or do we get worse result from that and that’s kind of the discussion that’s been happening.

Clayton:  Yeah, I would say I think something akin with a small team, it’s amazing how much easier it is for them to make decisions and get alignment on things and have like a shared set of values and I’ve seen the same people work in larger teams that are probably close to the six, like six, seven, eight people and nine people, whatever.

Maybe more like a traditional scrum size and I’ve never really have seen those people or those teams of that size be able to make decisions as fast as this team of effectively four people as fast as they can make choices. They can move so fast on things. They can get information and decide to do something.

They don’t have that feeling of, “We need to have a meeting, because some people aren’t here. We need to involve everyone.”

Roy:  So does that ability to make quick decisions…how does that compare against a team’s ability to produce so much value? Does that mean that they can’t produce as much value, but they can produce more of the right value, or what? How does…

Clayton:  I would guess that most organizations are in the boat, where, if they took a team of 12 people and they got rid of 4 people, I don’t know that they would see a huge drop in “productivity.”

Roy:  Maybe even a gain.

Clayton:  Yeah. I think, you eliminate some of those extra communication paths and some of the extra overhead of having to deal with that many people trying to make choices, or, decide what to do and all that stuff.

Roy:  And you get rid of some of the assholes.

Clayton:  Exactly. A lot of times it might seem on the surface like, “If we have a team of 12 and they’re doing…” If they were trying to use the philosophy, like “We’re a team of 12 and they can do 20 points a week. If we give it to four people, they’re going to go down.” But I don’t know that that’s always the case.

Derek:  I think some of it is the communication pathways problem, or the decision trees problem. I heard an analogy today I really liked, about learning, and it was an analogy towards video games. It was “Try, die, try, die, try, die, level up. Try, die, try, die, try, die, level up again.”

One of the things that happens when you have a lot of people and decisions go slower, it means, “Decide what to do. Wait, wait, wait, wait, try, die. Wait, wait, wait, wait, wait, try, die. Wait, wait, wait, try, die, try die, level up.” Whereas if you’re able to do that much smarter and take out those “wait, wait, wait, wait, wait,” you actually “level up” much quicker.

I when I say “level up” that’s where the people and the team are “leveling up,” but the product is improving at a much greater rate, not because the decisions are better because there’s less people, but you’re able to fail on the decisions you make much quicker to get to the right decision, than if you sit around for hours trying to hash it out between eight people what the right decision is.

I can’t tell you how many meetings I’ve sat in where there was eight people, and seven of the people were like, “Yeah, let’s totally do this,” and you’ve got one person that drags it for three days to try to make a decision.

Jade:  That can happen in a small four person team too…

Derek:  Right, it just happens quicker. For the most part it tends to happen quicker.

Jade:  But, there’s something more to it than just size. It comes down to a lot of trust and alignment, and things like that, which are easier to attain when there’s 4 of us, versus when there’s 12 of us.

Clayton:  I think you get an overlap, because if you have a team of 10. The team is supposed to be doing some collaborative effort. I might only interact with one or two people a day, let’s say we’re all pairing. It would take me two to three weeks before I would pair with everybody.

We’d have to go out of our way to make that happen. But in a smaller team you have no choice. You have to do more stuff with the same people over and over and over again, so I think you speed that process up.

Derek:  Yeah, you have more trust quickly because you’re more connected, because you’re doing stuff more often. The other thing is, if I’m on a team of eight people, there might be large parts of the code base that I’m not even really that familiar with, even if I’m pairing all the time, just because, by circumstance we’ve been through a few sprints and a lot of code has been created, and I’ve not been pairing a lot.

Now if somebody wants to make some decision, the two or three people, or four people, that have paired on that and are really familiar with it, are like, “Come on, let’s make the decision,” and the four people that are like, “Um, I’m not really sure.” It’s really hard to keep that sense of ownership, and that sense of collective being.

Where if you’ve only got four people, or five people tops, it’s really easy to be in a much more shared state of trust because you’re never very far removed from whatever it is you’re talking about. It’s very rare that you’re like, “Oh, man, people have been talking about what we’re going to do about this for days, and I haven’t been included in it.”

If you’re in a team of for people, it’s hard to not be part of almost every conversation on [inaudible 06:37]

Roy:  Unless you choose to be…

Derek:  The other thing that I have been talking a lot about, and I think this is a big part of mediocrity for a lot of teams, is, if you’ve got 10‑12 people, even 9 people sometimes, on a team, and you have one or two really strong people and one really weak person on the team, that weak person can really hide.

Because what happens is that the strong people can just pull harder, or work harder, or put more effort…

Roy:  Or shuffle the weak person around a lot.

Derek:  Shuffle the weak person around, whatever. What happens is if you ask them, “Why aren’t you doing something about it”? Their answer becomes, “It’s more effort for me to deal with trying to make the person that is hiding be exposed, than it is just for the…”

If there’s the four of us, and there’s five other people on the team, and one of them is really weak, we just say, “Hey, the four of us will cover what the other person’s not doing.”

That’s easier than having all of the emotional stress of dealing with somebody who’s not performing. But you get on a four‑person team, it’s no longer OK, “I’m sorry, the two of us are not going to pull the slow guy.” It’s just not happening, because now it’s a Herculean effort instead of, “Eh, it’s kind of painful, but…”

So two things happen. Either the guy that’s hiding figures out really quick, “I can’t hide,” and decides to go somewhere else, transfer somewhere else in the company, go to another team, leave the company. Or they have to fess up and say, “Look, I don’t know, I’m lost. I don’t know how to do this kind of stuff, I need help.”

Usually what will happen is the team will embrace that, and say, “OK, if you want help I’ll help you, but I’m not going to carry you anymore. When we were in a 10‑person team, we all carried you around, but now that there’s only one or two of us to carry you around, we’re not going to carry you anymore. But if you want help, we’ll help you walk.”

That that is something that exposes very quickly when you get small teams. It is so hard to hide when you’re on a team of five people.

Clayton:  Yeah, with the 10‑person team, that 1 person, their negative impact, I think, relatively speaking, is the drop in the ocean. But when you’re half the team…when you’re one‑fourth of the team and you have a negative impact, you could do half a day’s work that is bad, and that really impacts everybody. You can’t avoid that anymore.

Derek:  And we tell lies to ourselves. If we’ve got 10 people, and we’ve got some work to do, and it’s like, “Technically, Clayton really can’t do anything [inaudible 08:56] .” But we’ve got this stuff that none of us really want to do, so we can dump it on…maybe we’ve got some manual tasks we need to do, or maybe we need to do whatever.

“So we’ll keep you around even though, push comes to shove, we don’t even count your capacity in what we’re doing, but we know we can give you some stuff we don’t want to do.” When it’s four people and its, “You have to do four people’s worth of work,” you can’t go, “But, Clayton doesn’t count. It’s only the three of us.”

Roy:  That’s part of the problem though, is if you have a team that isn’t lazy enough. Because I’ve worked on a team where, I think there were four or five people on there, and we did it…that exact thing happened a lot because the team wasn’t lazy enough to automate all of that stuff.

They never got around to it because they could just always give it…it was actually easier for them not to automate it, because it gave the fifth team member something to do. That cycle just kept going over, there was no reason to ever automate, there was no reason to ever [inaudible 09:51] this guy up.

Clayton:  Pro‑tip, if your team’s slack is the same number as your capacity…

[laughter]

Clayton:  …there might be a problem.

Derek:  I think there was probably other issues going on there. My point is that it becomes a lot harder to hide that. If you’re doing your capacity‑based planning, and you’ve got 400 hours, and you’re only hiding 20 hours, you could explain away that slack pretty easily.

If you’ve only got 80 hours, and you’ve got 20 hours of slack in the way, I think pretty quick the product owners will go “Man, that seems like an awful lot of time for the amount of people here.” It becomes much more difficult to explain that away.

Jade:  We’re saying that 10‑person teams are a little large for us. I think that’s a radically small team size for a lot of people, to say 10 people, and we’re saying “That’s too big.” How do people deal with this if they’re in large organizations with pretty large teams, what do they do to start changing the way that their teams operate to get more lean and mean, to get more exposure, to get all these things that we’re talking about.

Roy:  I think it has to start with modeling view on in yourself. Start off by saying “I’m going to go do X over here, whoever is interested is welcome to join me.” If all 30, 40, whatever people in your team join you, that’s great, then you can immediately say “Now I’m going to go B,” whatever, and keep doing that until enough people drop off that you have a reasonable‑sized team.

Derek:  One thing that happens a lot is that people do everything by project. Everything is matrixed, everybody is a resource, everybody sliced 10,000 ways from Sunday and you’ve got 6,000 projects that you’re doing.

One of the things that you can do is start to say, from a from functional perspective, “What products do we really offer”? Or “What services do we really offer”? And get those narrowed down as probably not to 6,000 projects that you have. You probably have a much more finite number of actual projects.

Then you can start to say “OK, we’ve got 30 projects and we’ve got 100 people, how do we start to break that down”? You can even start to say, if the teams are still a little too big, if you divide that number and it’s still 20 people per product, you’re going to start to say “Can we slice that product even smaller”?

Amazon probably did this pass. You’ve got this nice commerce shop going on, at some point it gets too big and they say “How can we split it? What if we had all the server provisioning and management, what if that was a different team”? That became a new product called the EC2.

What if your provisioning managing team starts to get too big? We’re going to take the storage part of that and that’s going to be a new product called S3.

Can you take a product and can you look at it, can you slice it in a different way? Maybe you can’t do it as a full‑on product that’s consumable by somebody else, but maybe you’re able to do it as a component of a product.

Maybe you’re ebaying and you say “Our search bar is kind of like its own little product.” So that’s going to be a component that’s got its own team. All they do is continue to optimize and refine, make the search component really awesome and provide API to iPhone clients and other things to make searching really well.

If you can start to do that, then it becomes easier and easier, and you can start by saying “Maybe we go from 30‑person teams, or 50‑person teams, to 10‑person teams” and then maybe go from 10‑person teams to 8. You don’t have to make that jump all at once, you can make it in chunks.

Jade:  What I hear you saying is really Conway’s Law is going to kick in here and the products that you develop are going to be a reflection of those communication paths. You’re going to get smaller simpler tools and products and things like that, that will build on each other to build a more complex organization and a more complex set of products.

Derek:  It makes you much more adaptable. What starts to happen is, if you have smaller products, you have the UNIX mentality where you start to say “We’re going to do everything via APIs, we’re going to do everything where the products [inaudible 13:42] to something really, really good and then it will take inputs from other places and it will provide outputs to other places.

Once all of your products start to line up and start to do that, it becomes easier and easier to fracture projects, or a product.

If you’ve got a product and you split it in two and everything is an API, it becomes really easy, once it’s split it can still talk to other products, no problem. When it’s a monolithic code base, you say “Let’s split this thing,” that’s panic for everybody, because how do you even pull it out of the source control? It’s so intertwined with everything else. I think it’s a whole mindset that then makes everything way more nimble.

Some third party comes off and does it better than you do it? Awesome, throw that product away and adopt their product. Or you need some new product that’s out there to bolt on to your thing, it’s easy to bolt on. It gives you all these other advantages, other than just team size as well.

Jade:  What about an non‑software world, non‑software contacts, how does this apply?

Clayton:  As far as breaking the teams down or…?

Jade:  I mean, having small teams, keeping things simple, how does that work when you’re not talking about software?

Derek:  Give me an example of a non‑software?

Jade:  I’m a marketing team.

Derek:  I think you can do the same thing. Think of it as products. Your products might be services or maybe there’s the logo team from the marketing group and maybe there’s the brand standard team, maybe there’s the marketing collateral group, maybe there’s the social media. Maybe you think of your service offerings as products. We offer this service as a product, it doesn’t have to be a digital thing.

I can’t remember the gentleman’s name, he’s a publisher…I’ll try to put it in the show notes, that’s really good talking about “everything you do should be a product.” Whether you’re an author or a speaker…If you’re a speaker, you should have pre‑canned talks that you’re able to give that people are going to buy as a product.

They can dial you up and say “Jade, I want your talk on small teams. What does that cost? Can I buy it, can I click a button, can I book you”? Just because you’re not doing software, it doesn’t mean you can’t do products. We buy non‑software products all the time.

If somebody comes to clean my house, that is a service that they’re providing me, but I can call up and say “I’ve got a 2,000 square foot house, how much is it going to cost to come have it cleaned”? And I buy that product. They probably are able to upsell me and add value add‑ons and everything else. You should do the same thing with your teams, even if they’re not software.

Jade:  Great. Thanks for listening, we’ll catch you next time.

[music]

Announcer:  If there’s something you’d like to hear in a future episode, get over to integrumtech.com/podcasts 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 advance 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 in iTunes.

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.