Look around you. How many of you are out there living in the world of ‘big’? I mean, how many of you are boasting about the size of the budget for the project you’re running? How about the size of the team you’re heading up, or your department? If we were to look at your CV how many boasts about ‘big’ would there be? (It’s okay, there are plenty on mine, I’m just as bad.)
Everything out there is telling us that bigger is better. Supersize me? Sure.
In the first part of what will be a mini-series on the problems created by ‘Big’, I intend to address the aspects relating to big teams.
First, What Is A Big Team?
So what’s a big team? Well, let’s assume that a team can’t consist of one person, so the smallest a team could be is two. Jon Katzenbach a respected author on Teams, comments on the sampling he did in research for his book The Discipline Of Teams:
Virtually all effective teams we have met, read or heard about, or been members of, have ranged between two and 25 people.
Okay that’s workable. Theoretically then we can assume that the sweet spot is somewhere in the middle; the agile communities have long proffered 7 +/- 2 as the ideal number, from my research this could either come from an overly complicated suggestion in the Scrum guide, or perhaps Dunbar’s number.
Big Teams In The Big Wide World
What happens when we assemble a big team? Firstly, let’s get one thing clear – we don’t get a steady increase in the team’s productivity for every person we add. Managers the world over would love to think that adding more ‘resource’ (because we humans are all just automatons really, aren’t we?) to a team is just like adding more servers to a cluster – that there’s no appreciable drop in performance.
Wrong. “That’s because problems with coordination (caused by dependency) and motivation typically chip away at the benefits of collaboration.” as Hackman this time, steps in to explain in his Harvard Business Review article Why Teams Don’t Work.
The team that I am in at the moment provides a great example of how dynamics within a team change as it increases in size. We’re working on a great new product that we believe will be of real significance (it’s all right everybody – we’re not blindly following our beliefs – we’re testing our hypotheses as we go too – that’s for another blog though). The team started out as three people and existed that way for about six months. During that time, like the good agile people we are, we’ve been dog fooding our own processes – but, and this will shock some – until recently we’ve not used a kanban board nor have we had a daily or even weekly stand up.
We simply felt there was no need for them; there was so much tacit knowledge within the team and such a clear sense of purpose that they were deemed unnecessary. In fact when we did flirt with using them we found that they added nothing, and that instead they actually caused an overhead.
What changed? Well we recently introduced another four people to the team. The amount of things being worked on at one time increased. Those two factors along with some others meant that it became impossible to rely on just knowing what somebody else was working on.
I think we can all agree that the coordination aspects are self explanatory – as we add more people to a team, it opens up more lines of communication. Anyone who’s worked in a typical large organisation in their time will know the answer to this – an endless stream of meetings, meetings that involve a large number of people themselves which of course compounds the problem (I’m not anti-meetings for the record, just anti the ‘big’ soul-sucking drawn-out ones in which, even with everyone’s best efforts, your own included, a conclusion isn’t arrived at and instead another meeting planned).
All right, if the endless procession of meetings hasn’t already thwarted your motivation the thing that will definitely start to affect it is this: as people become less directly attached to the purpose of an endeavour, their motivation dwindles. And that’s simply because they’re getting less feedback that what they’re doing is making a difference. We as humans are social beings – we want to be recognised by our peers and when we’re not getting that recognition the fact is that over time no matter how much we try we’ll loose interest and our motivation will lower.
I myself have sadly seen all too many of these types of projects – you know the ones – projects that start off as somebody’s little baby, might have some value tucked away in one corner of the business case, but otherwise have no real purpose other than to satisfy that person’s political agenda; the ones that no matter how hard you try to get them killed off or expose the actual value within, limp on. Anyway, in my experience its these projects that then to grow in to multi-million dollar exercises in destroying people’s will to live.
Okay, so we get coordination and motivation problems, but wait, there’s more: as the size of the team expands, the boundaries become more blurred meaning that who’s in and who’s out becomes less clear. The bounding of a team is really important, without it Nobel Prize-winner Ilya Prigogine argues that only with a clear boundary can any team truly start to organise itself. If you’ve ever come across Tuckman’s model before you’ll know that he says that a team passes through four stages over and over: Forming, Storming, Norming and Performing – without a clear boundary it’s unlikely that a team will ever really get off the starting blocks.
Although I’ve seen more than my fair share of rotten projects, I’ve also been fortunate enough to see the flipside on a number of occasions. I can think of at least four teams that I’ve worked with, that have set themselves apart from all the others and here’s the difference: they remained stable in size, they worked hard on understanding their purpose, they’ve been courageous enough to challenge each other – they weren’t worried about being harmonious; they were worried about getting the job done to the best of their ability. Moreover, they constantly strove to identify the actual value in solving the problem they were faced with and weren’t afraid to tackle that in little chunks pushing aside all of the other ‘absolutely necessary requirements’ they were given – doing this allowed the team to stay small and even with a hint of chaos on the inside, to those on the outside i.e. their customers they appeared to be incredibly smooth and efficient.
But I Need A Big Team
And why’s that? Because you’ve got a ‘big’ problem? Well here’s the thing, ‘big’ problems tend to lead to other ‘big’ problems – have you considered that instead you could break the problem down in to much smaller chunks. Yep, I bet you’ve considered that, but I bet you’ve also dismissed doing so as hard.
The good news? In the following parts of this series we’ll look at the sources of ‘big’ problems in the I.T. departments of most organisations and start to offer some small solutions.