Sessions is temporarily moving to YouTube, check out all our new videos here.

Does Size Matter?

Rob White speaking at Sheffield Ruby User Group in May, 2017
36Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

The advantages and disadvantages of working in a small team vs a bigger one, and the overheads imposed on day-to-day development.


Transcript


My name is Rob White. I work for Sky, and this is my presentation on Does Size Matter? Apologies in advance if it seems somewhat lacking, it was slightly rushed. So, I'll start off with the usual disclaimers. This is all based on personal experience on going from small teams to large teams. I offer no warranty if you try to follow my tips, and it all goes wrong. So, in the past I've worked in small teams, including Epigenesis, and everything seems naturally easy in small teams. Communication, for one thing, is easy. Everyone just talks at each other and that's that, but I've also worked in large teams, and it's not that bad. Sometimes it's hard and sometimes it's interesting, but overall, I'd say it's not that much different from working in a small team. So if you Google what's the optimal team size you can find a lot of quotes. For example, the CTO of Amazon saying "If a project team can eat more than "two pizzas, it's too large." Which means, I am a team in myself. So that, kind of, crosses that one out. Then if you look at The Scrum Guide, apparently the recommended ideal team is between seven +/- two, and then if you look at a year later, it says the recommended team size is six +/- three. It doesn't seem a very well-defined thing, the optimal team size. For me, I would just say it depends. I guess that's kind of the cop-out answer as well. Typically, how does a team get so big? Based on personal experience, the management excuse is always we have a fixed deadline. Typically, if you're working against competitors, they'll be releasing at a date and you have to release before them or at least on par with them. If you're working in a new problem domain, then estimating will be hard, which seems to be every developer's excuse for everything anyway. If the project starts to lag behind your really bad estimations, then the higher-ups will add resource to your project. Resource being the term for developer, two developers because we're all just people on a spreadsheet. As you add people to the project, either it works, in which case it was the right choice, and it's a good thing so we'll add more people anyway. If not, then it just adds to the panic, and you end up adding more people anyway. It's like ah, panic, let's add more. I'm going to walk through a small hypothetical today, which is Winnie the Pooh, Inc. We're going to start with a small team. We're going to start with a team of two, and going to pretend with this business, working along, producing good content or whichever you imagine Winnie the Pooh to be doing. We'll start with, I think it's smallest team possible unless you're schizophrenic. We'll start with a team of two. Communication is easy. Everyone's talking to each other anyway, either in person or online. Regardless of the communication channel, it's always between everyone within the team. If anything, you might record things for prosperity in case you've got a bad memory like I do. Otherwise, it all just works. If you have a disagreement on something, that's when a recorded thing would be good. But apart from that, you can progress nicely. You don't feel like you're restricting yourself or you're slower than you could be because of lacking processes. If we're imagining with this team, we're a team of two, we feel like everything is going nicely, but we could probably ship a bit more, a bit more product, a bit more whatever. If we add an extra person to the team, or extra n people being a small number. Then, again, it's all relatively easy. It's implicit we all grow. You have a little bit of overhead. If you've got three people, then not everyone's not all in the conversation at all times, but for the most part, it still works. You have a little bit of conscious effort. For example, if you come to a decision, either two of you or some majority comes to a decision, then it's always best to put in your public channel or wherever the majority of description should happen. And you find that typically you work towards a single source of truth because if everything's in one place, you just have one place to go to. Again, it's very little overhead. If you've got a question, you just go there. If for whatever reason something isn't in the single source of truth, if Alice asks Bob, and Bob asks Charlie, and then Alice asks Charlie again, it's three routes instead of two, and everything is relatively straightforward still. You find going forward that is still waste, and you should probably write down as much as possible to prevent it. You try to document all the things. And in thinking going forward, if we're going to grow the team anymore, we brought a few people on board, we've established that a single source of truth's a good thing whenever someone has a disagreement or forgets, they just go there and it all proves useful. Whenever we onboarded an individual, it was always easier when we had everything recorded because if they had any questions before they came to us, they could double check with that. So we decided single source of truth is a good thing, let's document absolutely everything, and then our regular conversations that we have between each other, they became an official process. We adopted the whole daily standup in the morning and decided it was just the natural flow of progression from conversations to a single conversation in the morning about what we're working on. The other reason why we'd have the standup in the morning is that obviously everyone's different, everyone does different things better, and by everyone knowing what everyone's working on, you can reduce the duplication of effort and also pick the right people for the task. You don't end up having someone struggling on the front end because they're primarily a back ender or vise versa. We've thought hard, we established these three truths, and we're going to bring in some more guys. Unfortunately, this is where the math is not in our favour. If you have three people, that is three lines of communication, which is relatively straightforward. If you have four people, it goes to six, five to 10, six to 15, little formula's over there. You can see quite quickly, from three to five, it triples nearly. From five to seven it doubles again, and it quite quickly gets overwhelming. We decide, so the single source of truth, which was magical and wonderful and the solution to all of our problems, starts to be a problem in itself. We end up with information overload, which introduces two important questions. One being, how do we categorise the important content? How do we filter, if we're documenting everything, how do we decide which information is relevant to us or which information is relevant going forward at all? We have to think a bit harder. We decided, okay, when adding things to our run book or wherever we're storing this information, we have to decide is this worth keeping and is this useful to myself and/or others going forward, which is a hard decision because how do you know what is relevant in the future, how do you know if you're wasting time, if it will be useful? It adds mental overhead, and mental overhead's the one thing we don't want because we're supposed to be thinking about solving the problem not how we solve the problem. Another difficult thing is, we can make as many decisions about whether we should add something to our run book or single source going forward, but how to we know when to go and reflect on whether it's still useful in a week's time, in a month's time, six month's time. Because it's okay having useful information at the point of adding it, but three months down the line it could be useless, it could even be negative if it's documenting a process in the wrong way, for example. The second aspect of it is, with all this information coming in, how do we suppress the unimportant content? For example, if everyone's communicating in a single channel, and someone posts a notification going, hey I've got a pull request, can somebody take a look, and everybody is randomly talking about what their favourite episode of Winnie the Pooh is, then it's quite easy to lose that communication. You end up expanding out and deciding how do you decide which is the useful information on a daily basis. I, for example, have a bunch of mail filters. I don't know if I should say it, but I think I've got 14,000 unread mails, which I never actually see, and they go straight to the bin. Because it's, again, this thing of everyone needs to have all of the information just in case. So I've switched three teams, I think, since my time at Sky, and I still get everything from my first team, which I was on for three weeks out of eight months. That's, again, a just in case. Anytime there's a change management request for absolutely everything, it piles in. Mail filters, I say, are the best frenemy because they're great in that we can get rid of all of this useless toff, but it's quite easy to accidentally remove something that is actually important to us. For example, if one of our dependencies are getting changed, and we aren't explicitly made aware of it, if they assume because we're on these mailing lists we'll be tracking this information, and suddenly our up goes down, and we go "What have you done?" and they go, "We told you." It's not useful. We also decide, a team of 10, the daily standup is starting to get a bit painful. For example, in my current team, we have this process that if ever you decide the current conversation that's going on the standup is irrelevant, you simply put up your hand, and it's the end of the assumption that, as other people start to put up their hands, that people are talking will notice and realise that it's probably not relevant to everybody else. And then you end up with this phrase of, "Let's take this offline," which makes no sense. You're not on the internet, but whatever. With a team size of 10, all of these numbers are based around the develop account, not necessarily scrum masters, product owners, MBAs. And the largest team again that I was in, I think it was approaching 30, of which 22 were devs. That's what this is based on. Then, you also have the issue of, with everybody talking about all of these different things, and if everyone's working on so many different problems in parallel, are what they talking about really relevant to me? And you start to zone out and not pay attention, and that's the whole point of a standup, is to know what other people are working on and if it is relevant to you, which renders the entire meeting moot. There's lots of fun little things to try around standups. For example, if standing up isn't a hassle enough, you can do the plank standup where everyone fails within 30 seconds and then gives up and goes back to work. Then, just because it's fun adding more people to a team or the people that are analysing the progress or the velocity aren't actually within the team itself, you get more and more resource added, and you rapidly approach this team of 20, which consists your original team, and then 10 other guys that you don't know what they do, you don't know who they are, they just sit there and draw weird unicorns. A Deadpool reference in case you haven't seen it. When you get to the team size of 20, it starts to rapidly fall apart. You end up naturally fragmenting into smaller teams. Again, of hopefully less than 10 but that's not guaranteed. The way that it works is each smaller team has their own separate standup, which again sort of defeats the purpose of a standup. If everyone's working on approximately the same code base or at leas the same problem domain, you kind of need to know what the other teams are doing, otherwise you're wasting your time, you're wasting their time. If everyone's doing the same thing or solving the same problem, comes up with three different ways to solve it, and then nobody agrees because everybody's got an ego and decides "My way is the best," then irreparably falls apart. At this point, miscommunication gets really expensive. So in my previous example, we had Alice, Bob, and Charlie, and three people talking isn't much harder than two. You're only wasting a little bit of work. If, I'm not going to say the names from A to 20, but if everyone's asking everyone the same question, it rapidly gets to the point where people get annoyed that they're answering the same question. The amount of time wasted is exponential almost. It leads to bad moods, bad working environments. You want to try and avoid that, if possible. Next, because you're working on so many different things in parallel on the same code base, it's quite easy to end up with information silos. You get the one guy who always goes and does this work because he knows how to do it, and whilst you can pair on things and try and share the knowledge, if you've got a team size of 20 and you've got two people that know it, it's still a silo compared to having it spread as much as possible across the team. Next thing, you have duplication of effort just because you don't know what the others are working on. So you have really tight information silos that could be useless if, again, if you're working on the same problem in two different ways, you get two different domain experts that are arguing over practically nothing. Then the other issue is, typically if you're adding more people in blindly, the team fragmentation is always reactive. You don't decide that you're going to split the team up, you end up having to split the team up. If the reason is they're adding these team members because you're not performing, then you'll end up with the situation where the team has to split up, but we have to keep churning out this work at the same rate we're currently doing, otherwise what's the point in explaining it? The hope is that it does it magically by splitting the team, it solves the problem. But that's false logic. The other thing that happens when you end up with obscenely large teams is that you're forced to invent new roles and new processes to manage the initial overhead. I don't know, I'm going to ask, what's the largest team size that anyone's committed to a single repo simultaneously? Get some numbers. Five? 25. So you probably will have experienced the merge master role. When you have, even if everyone's strictly pairing and you've got 12 sets of pairs all committing to the same repo simultaneously, it's quite quick to go from, "Hey look, we've cleared all the pull requests, it's fine." And then suddenly you've got 20 more on your backlog, and there's merge conflicts, there's priorities because the business is trying to release things, so I've got to get mine in first because that's what the business wants even though it's a small one relative to one in ... it's not the efficient use of everybody's time. What's everybody else's team sizes, by the way? Should probably have asked this at the start. When you have smaller team sizes, you don't actually ever think, it really is almost a first world problem when you're committing too often and you're doing too much work that it's not actually accomplishing anything. It's one of the reasons why it's so hard to be proactive in your fragmentation because there's so many problems that you didn't think, "This could possible be a problem." The idea of that if you have a pipeline, and you're spending up all of these different processes, and you've got a build process that when you manage to master, it then re-runs another 19 builds simultaneously, and it never seems to cease or speed up. That's when you find your tests sweep times start to come into it if you've got five-minute tests and every five minutes a new PR's being added, you're not actually getting anything done. Even if you're perfect, and there's no conflicts, and everything goes nicely, you're still not ever actually catching up. What we found was in, again, this is in Winnie the Pooh land, yes, not real, team, we found that we had to have this dedicated merge master/merge princess they called me. So, so, yes. It's quite quick to wear on you. It starts off funny, but the sixth time you're the merge princess and you're given a tiara, it starts to grind on you. All of those roles, you try and keep them volunteer roles because no one should be forced to do anything they absolutely abhor. That's one of the good things about it is that it really brings people together as a team because if people are sharing the burden and have got a common thing to complain about, then you're strengthening your bonds, and it's a common enemy, which is always a good thing. The other other thing that you find is because you have the information silos earlier on, you end up having to have people volunteer to become ambassadors or SMEs. If you have a team of 20 and you break it down to two teams of 10, then typically you want to have within each team an SME where they can communicate across teams just to try and reduce the duplication of effort. But that, again, adds overhead to their daily tasks, and you end up having standup between two teams and standups between the different SMEs, and it all adds up. Subject matter expert. For example, if you've got monitoring and logging, and you want to have a cohesive way across it, you'd hope that it was established long ago, but everything changes, right? So what can we do differently if we find ourselves in a team that's far too big? In the team, you try and have a ways of working via your runbook or your weekly, if you're doing sprint, if you're doing combine, you try and do reflective sessions so you can actually address the problem. It's always good to reflect on the pain points. And not only that, you should probably document how you're trying to address them because there's no point having the same complaint every retro, and not actually being fixed. Then again, sometimes there's these problems that simply won't get fixed because that's the nature of the beast. You complain it as you want until you're blue in the face, but that's not the priority. To the same extent you should encourage open communications within your team, but try and limit it to physical abuse. No fistfights unless it's during our retro. Be conscious of the costs of communications. It's quite easily to get lost in being productive while doing work that you feel your work is important. It's important to try and be selfless in your analysis. If you have new team members coming on board then it's difficult to, if they come into the team and there is no official onboarding process, then it's quite easy to get left at the wayside, and then you're just adding more dead weight to the team because they need to be there, they get assigned tasks, but if they don't understand how something should be built or what the common methods are, then all of their efforts are going to be wasted and re-written by somebody else. But also, it's not good for team morale because you end up in an us and them mentality. Imagine if you bring on five or 10 new team members, and the onboarding process isn't there, it's quite easy to be resentful of the team that you've joined or resentful of the new team members. If one feels that the other's not being productive or the other feels that they don't know how to be productive, there's nothing worse in your daily life than to go to work and feel like you can't do something. But whilst open communication is important and everyone should complain, it's important to keep your complaints to a productive or constructive manner. It's great to say that there is a problem, but if there isn't going to be a solution to that problem there's no point complaining about it repeatedly. Because if it's not going to get solved, then it's just going to bring you down, leave you feeling angry, resentful, and generally disliking your job. And if you dislike your job, you're not going to be productive. So it's important to both yourself for the fact that you like life, and the higher-ups because they want stuff getting done. In that vein, I would regularly suggest going along with the fun retrospectives. It's always great to do the stop, start, continue on your retros. How many people here have done that exercise? Most people? Which is useful, except when every time you have a retro it's the same points being brought up on the stop, the same points brought up into start, and then no one says anything in continue because everyone's miserable. It's nice to try and break it up. Fun retro has retrospectives that involve team building exercises. And everyone loves sweets as well, so any of the ones that involve sweets, I recommend those. Yeah, yeah. It's a fine balance, you have to try and encourage people to be open about what they dislike whilst understanding is it useful to complain about it or to be the devil in the shoulder, you have to, or to have the cop-out, and so you have to be very conscious of your decisions be it, "Hey we're all going to go have "fun even if everyone's miserable. "We're not going to address why," then it's not useful. And then the other thing is, if you're aware that your team size is changing, be conscious of how you can influence the changes. It's always great to experiment if you think that you can do something better. There is no real cost to trying it out and failing. In the scope of months, what's a week or day? In the scope of years, what's even a month? You should always be willing to try out people's suggestions, and you'll find that encourages the open communication at the same time. If people don't feel like their ideas are dismissed or mocked, and people are actively going to try them out, people are going to be more willing to come up with out-of-the-box solutions, which they might not do otherwise. And then again, within a changing team, recognise that people are going to change roles. For example, if you do have people that are more aligned with fixing the builds of the pipeline or managing those processes, don't harass them about the fact that they've not done tickets. Because they are still being productive, and the majority of team members aren't going to just sit back and do nothing. People, I've found, like to contribute and like to feel like they're being productive, even if it's not in the way that you're expecting at the time. To go back to the original question of does size matter, it really depends. If you find yourself in a growing team then you can't necessarily push back. If you can, then you're in a magical candy land, and management respects your decisions absolutely, but that's not the majority of these cases. You're going to find that you have to work with the situation that you have. Whilst it can be horrible, and it sometimes is, it's not the be all and end all. The majority of times you grow your team for a specific deadline or a specific reason, you make the best of a bad situation work to it or you find that your team has adapted in the time that you've been working towards that deadline, and it all works out. That was the majority of my talk. It might have been rather quickly. But if you have any questions, I'm more than happy to answer them.