I’ve talked before about what I perceive are 3 important mindset shifts for an agile coach and something that they should help their clients (teams and organizations) with that thinking as well. And one of them is the dangers of seeing people as resources.
In this blog post I’ll expand on that and show you why you should stop adding more resources to your project or teams and how it’s actually hurting your performance. And if you are a coach in this scenario, I hope this post gives you not only insights, but also language as sometimes the trouble is on how we convey the message to our clients.
Let’s get straight into it.
It’s a culture problem
Whether you are the coach in this situation, or the manager, you should know believing you can add more resources to your team is a very mechanistic approach to solving problems of schedule and performance. It’s not wrong or right, it is mechanistic. So, it should apply to highly mechanistic situations.
Is your team very mechanic, in the mission, in their way of working and in the technology they use?
My guess is that they are not.
Your average agile team is a group of software developers, or researchers, or creative people and what they do on a daily basis is rather dynamic. Not just the nature of the work is dynamic, but also the nature of their interactions with one another.
The hope is that when you add more people into the team the project will finish faster; or worse, you are late and hope adding people will make you finish on time.
The main problem in this culture is that you will hear managers on meetings saying that a resource is not working as expected, or that we need a new resource, and you can’t stop but wonder if they are talking about computer parts. It’s rather dehumanizing.
What is even more surprising is that despite this ingrained practice in organizations you won’t find any respectable studies done by the MIT, HBR, or PMI with anything corroborating “resource allocation” as a valid practice for project success.
In fact, their list of key components for projects success clearly state that you should be focusing somewhere else.
Now let’s see what are the misconceptions and issues behind this idea of adding more “resources” to the project or the team when things are not going at the best performance and how damaging they can be.
My best hopes are that these help you see why you should stop adding resources to your project by recognizing this approach has a steep cost and most often it does not solve the underlying issues derailing performance.
Issue 1 – Onboarding and training are not free
The first misconception is to assume that people are able to come in and be highly productive from the start. As an agile coach you know better, and you know that:
1 – highly productive people put together do not necessarily equal a highly productive team.
2 – you can only be highly productive when you are fully contextualized, equipped, and comfortable in your commitments.
The reality, however, is that in most organization onboarding takes time. It has at least two components: the organizational onboarding and the team onboarding. Get your best java developer and she still needs to understand how the organization works, what tools she will use, and set them up. She also needs to understand who is part of her team, and how the team works (aka team process). Sometimes the new onboarded person needs even some training, either formal or done by their peers.
For quite some time this new “resource”:
- is not yet productive, but it started costing you.
- takes time from other team members, who instead of being productive in their own way, are now teaching, onboarding and solving for the new “resource”.
It’s a double cost.
Because that’s how collaboration works. There is nothing wrong with the picture above. You have to take time to properly onboard the new person because they are not a resource. They are not instantly swappable.
So the first lesson is that before even considering adding people to the team or project you better be able to estimate that cost in money and time to see if it is doable or if you are actually just sinking the project faster.
Issue 2 – More people, more complexity
Whenever you add people to a team or a project you just made their staff bigger.
While in a lot of cases there is strength in numbers, the reality is that agile teams perform better when they are small and mighty. From an extrapolation of the Dunbar number companies like Amazon adopt rules such as “two large pizzas” to feed the entire team. And that is because meetings are shorter, more targeted and you don’t have the opinion of over 10 people to consider.
Let’s face it, everybody in a team has a voice. At least if you want it to perform.
As you need to give voice to 13, 15 or more people, how complex it becomes. Even looking at the kanban board, when the team has one, becomes useless. A tool that should show transparency has now a humungous number of tasks in progress. It’s now just become visual cacophony.
The daily stand-up is also les useful now, as people just quickly blabber what they’ve done so that they can guarantee the arbitrary 15min rule. Or risk spending 30+ minutes and getting lost in the conversation… because the team is so big that they split in sub-teams, and each takes care of a part of what’s to be developed and sometimes don’t even intercommunicate. How is that for performance? I see a Frankenstein in the making. That sort of team (lack of) structure will end up with technical repercussions in the product’s final architecture and quality.
Not to mention, when something needs to be checked, who do you talk to? If you need to ping all the other colleagues, how many interactions are needed before a problem is solved?
There is this common picture, of a variation of it, circulating in the internet that illustrates well how fast you increase communication complexity when you add more people to a team.
Small is good for agile teams. Don’t add “more resources” if you wish for better performance.
In fact, Forbes published this fun article where rather small companies generate huge results. The power of small teams and focused collaboration.
The second lesson is that just adding more “resources” to your tam or project can hurt quality and create more complexity, making it all more difficult to manage.
Issue 3 – Many managers don’t know what the team needs
The third issue you must pay attention to is that this idea of “more resources” is usually an approach indicative of how far the manager (or project manager, team lead, etc.) is from the team.
It is not a hard rule, but usually outsiders tend to think the solution is to add more hands in the team, whereas if you’d ask the team, they’d probably say something different. I’ve coached teams that had no idea they were late in the project and did not know that project manager was planning to add more people to the team.
Terrible vantage point when considering autonomy as well as a lack of communication to say the least! It also tells me this manager is not truly talking to her team. The only problem the team members were seeing was their lack of understanding the scope of the project. They felt like dates and boundaries of scope kept changing more than they could grasp. The manager in this story, felt differently she felt the scope was clear, even though she was not a developer in this team.
Classic miscommunication. Yet, decisions were made considering the (lack of) information the manager had at hand.
I’ll tell you another story that illustrates the ineffectiveness of this “adding resources” to the project.
In this one the manager decided to add another analyst in a team that contains analysts and developers.
My first question, to which there was no clear answer, was “how do you know you need another analyst”? Did they all know what their bottleneck for work items were? Did they have data to corroborate that “feeling” that they needed another analyst? Could have developers take in some of the analysts’ tasks? Could you consider not creating specification documents?
Basically, how would you even know that actually removing a developer was not better for the speed of this team?
The learning point is that you don’t manage by feeling, you should manage by evidence. At least in an agile space. If you are seeking adaptability, flexibility, and ease of accommodation for change, feelings can come in as just one of the points in the equation.
This manager felt the developers were speedy, so the team in this project “needed” more analysts… To produce more specifications to feed the developers. Now, the specifications are pilling up and they have inventory of it. So much documentation that the developers could no longer catch up. Ironic, isn’t it?
You know where the conversation went, don’t’ you? Now they need another developer to make sure it all goes faster. In a team of already 12 people. The manager wants to go there!
I see a never-ending cycle.
I also see the project is still not out of the woods. But everybody in it is busy and occupied. No performance yet, but the “resources” are well utilized.
And that’s because despite the ability to produce more, the problem was never that. The problem was producing the right things, creating a much simpler scope, and gathering feedback faster.
Lesson number three is that the less you know about the reality or heart of a problem, the higher the chances you will make a bad decision that creates even more problems further down the line.
Issue 4 – Team gelling takes time
This is tightly associated with the first issue, about onboarding and how long it takes for a team to perform after incorporating great change, such as a new team member.
But I’d like you to consider this issue on its own. Consider that adding “resources” to your project ignores that these resources are people and that people working in a team need time to mesh well together.
Teams need time and space to gel.
As a team member I don’t just come in and code my Java thingy.
I will have people review my code and I’ll review someone else’s code. I might feel very defensive about this approach have I never used it before. Or I might have a more direct communication style than my peers and for a little we’ll all be taken aback. Maybe I might have different ideas of what a great CI/CD is and I might start suggesting new things and the rest of the team may or may not like it. I might not like to talk about personal stuff while the rest of the team knows each other’s kids by name.
In short, we’ll need to connect as human beings and simple things like not wanting to have coffee in the morning with the rest of the team might delay trust and gelling.
And during all that time, the former team has their current performance affected and I, as a new team member, am still not at my best performance either.
As you can imagine, it’s hard to collect the benefits until this new team member and the team are more adjusted. Until then, the balance for results might not be positive. Yet, you are still paying the bill and none of that integration and gelling can fit a specific schedule just because the project is late.
Lesson number four is humbling: human interactions don’t go at the speed of your will, so by adding more “resources” you might have just made a bad problem worse.
Can’t you add “resources” at all to an already running project?
Simply speaking, you could, in fact, add people to a project. But that is possible sometimes, not always.
Definitely not with the mindset that people are resources, swappable and you can add or remove them at will.
First, that’s dehumanizing. They are not resources, they are people. Despite a thriving business of consulting placing people via contract in organisations everywhere, it’s a wrong assumption that people as resources can be traded, added, removed without much regard for their unique skills and even how they feel about their own contribution.
When you just swap resources, you are not tapping into the magic of motivation and commitment that invested individuals can bring to the table.
But you really should stop adding resources to your project as a way to recover or increase performance.
I want you to consider the following: when you have a performance problem, usually what you need is not more people, but a better game plan.
Think of your favorite sports team: hockey, volleyball, you name it.
In most of these sports you can’t just go adding people. What you do is that with the same number of players, you adjust your strategy according to what is happening in the field.
While your current in the project team may not be a sports team, the analogy can yield much more than just disturbing the current team with a new player.
If that is something that interests you, stay tuned:
In an upcoming blog post I will take you on a tour of what you can do instead of just adding resources to the project and looking into what actually can bring up performance.
