The Simple Solution to Deciding Your Agile Team Size
Photo by Katie Rainbow 🏳️🌈 on Unsplash
Our Scrum meeting never seems to fit into its hour-long meeting. This has been predominately caused by the size of the team. We can’t get our Agile game under control and it’s no wonder.
“If you can’t handle time-boxing with your Agile team, things are going great. For those who are a little hard of understanding, here The Secret Developer is being sarcastic.
Like anything in software development, Agile is only as good as the people implementing it. In my case, let us look at what is going wrong.”
Your Size Is Always Wrong
Some practitioners of Agile claim that having an Agile team of 5–7 people is always right. The Secret Developer has a pretty predictable reaction to this assertion.
“It’s not great to take the received wisdom verbatim for pretty much any topic in software development. To put this in a way a junior developer can understand — remember when you copy-pasted code from Stack Overflow and got shouted out? This is like that.
To build the perfect team you need to weigh up the advantages and disadvantages of any given size and think about what suits your culture and environment. Oftentimes people in software development do not seem to understand the problem they are solving and perhaps unsurprisingly in such cases produce a less-than-optimal solution.
With that said there ARE mistakes that you can make with your choices (you just can never get it right). Let me take you through a few situations where you would almost certainly get it wrong.”
Situation One: Your team is too small
Small teams are prized in the software engineering world. However, there are still trade-offs that need to be considered.
“Remember when we all seemed to agree with Bezos’s two-pizza rule? You are not supposed to have any meeting where the participants cannot be fed by two pizzas.
For Agile this is fine in theory. However, it doesn’t take a massively complicated project to need several specialists in order to deliver features. A web developer here, a mobile developer there and some specialist developers everywhere and two pizzas will be insufficient if you wish to actually be able to deliver the features required by the business.
It’s not just a temptation to increase the team size. It’s about building a team where the number of members of the team is insufficient, and you start sharing resources between teams. When you begin to do that, you’re in effect expanding the team. If you keep doing that eventually you’ll end up with situation two.”
Situation Two: Your team is too large
“Your Agile ceremonies take too long.
In our case Stand up is supposed to take 30 minutes and we never (ever) make it. It stops The Secret Developer from getting their work done and I guess the rest of the team’s productivity is not great either.
In my case (and probably because we are termed as being) people feel like resources. You can be replaced with another resource and pretty much nobody will care about you. It simply takes too long to talk about problems in the team (and Folake always seems to be on vacation).”
The Solution to these Situations
“In order to balance an Agile team you will need to think about the requirements from the business and the tech team. You’ll need to think about what you actually need to achieve and want to achieve to be able to do so. Instead of choosing one thing move your preferences along a scale.
Resilience — Agility
Productivity — Bonding
Span of Control — Individual Attentiveness
You can’t possibly have it all. If you could then your project would probably be able to have it all and your project manager wouldn’t be cutting corners all over the place in order to deliver your features.”
Conclusion
“Make your choices wisely. Think deeply.
Then jump in.”