One common question our customers have been asking for years is, “Can we just start with 10 devs to get our app done quickly?” While it is true that adding resources can speed things up, you have to be aware that you will not get a linear increase in overall productivity. The law of diminishing returns definitely applies here. In other words, if a team of 3 developers can finish a project in 4 months, you will not cut that time in half (deliver after just 2 months) by doubling down on developers. Every project is different, but 3 extra devs might not even buy you 1 month which means that you need to budget financially for the difference.
Why is this the case? Every developer you add creates a certain amount of overhead. There is simply more coordination required within the team, more “management” time (yes, even when handled collectively by the team itself), more opinions that need to be discussed during sprint meetings, potential conflict among team members that needs to be resolved, etc. This overhead increases exponentially as each developer is added.
What this means is that at a certain point, adding another development resource might actually start slowing the team down. We’ve experienced these types of situations where the performance solution was to reduce the size of the team.
So is there any other way to speed up your project? Well you might be able to find ways to increase efficiency within a team, but most professional agile teams are constantly doing so already. So really the practical answer is no. If you need to speed up, you might just have to add resources and pay for the overhead. Just be mindful of how far you take it because the strategy could backfire.
For larger projects, you might consider creating multiple teams instead of one very large one. If you do so, make sure you make each team responsible for separate bounded contexts to help reduce potential conflicts between the work that each team is doing.
On the flip side, we have customers ask, “How can we keep this as cheap as possible?” Well, you might now think that hiring a single developer would be the most economical way to get your project done when the timeline isn’t a concern. Disregarding the inherent risk in having just one developer involved in your project, this also isn’t the case. Getting your project done will likely require many skillsets which will not be found in one developer alone. Also, one developer working alone, regardless of skill level, is not nearly as impactful as he/she would be within a team. As a social species, we all need other people to talk to, bounce ideas off of and get general advice and support from. If your goal is to create a quality piece of software that works well, is maintainable, and can handle changes that you’ll throw at it over a long period of time, then you should give your developers what they need to be productive, which is a good cross-functional team to work in.
Therefore, at a minimum you should consider a team of 2-3 developers for your small project. A team of 2 is very minimal, but is infinitely better than 1 if funds are lacking. Scale up (with caution) as needed to meet your timeline and other requirements. Larger projects tend to have more complexity and require more skillsets. If you are missing a required skillset, that will negatively impact quality and the timeline. Again, cautiously build up as needed, and be mindful of the potentially negative impact any added team members might have.
Agile evangelists state that a team of 5-9 is the optimal size for a team, but 5 devs on a really small project is overkill. We also don't like to go above 7 devs on larger projects. If your project is large enough to require that many developers, then you should be able to create separate teams which would likely be more effective. Again, there are always exceptions and each project is different but this is what we've found to be most successful.
Why is this the case? Every developer you add creates a certain amount of overhead. There is simply more coordination required within the team, more “management” time (yes, even when handled collectively by the team itself), more opinions that need to be discussed during sprint meetings, potential conflict among team members that needs to be resolved, etc. This overhead increases exponentially as each developer is added.
What this means is that at a certain point, adding another development resource might actually start slowing the team down. We’ve experienced these types of situations where the performance solution was to reduce the size of the team.
So is there any other way to speed up your project? Well you might be able to find ways to increase efficiency within a team, but most professional agile teams are constantly doing so already. So really the practical answer is no. If you need to speed up, you might just have to add resources and pay for the overhead. Just be mindful of how far you take it because the strategy could backfire.
For larger projects, you might consider creating multiple teams instead of one very large one. If you do so, make sure you make each team responsible for separate bounded contexts to help reduce potential conflicts between the work that each team is doing.
On the flip side, we have customers ask, “How can we keep this as cheap as possible?” Well, you might now think that hiring a single developer would be the most economical way to get your project done when the timeline isn’t a concern. Disregarding the inherent risk in having just one developer involved in your project, this also isn’t the case. Getting your project done will likely require many skillsets which will not be found in one developer alone. Also, one developer working alone, regardless of skill level, is not nearly as impactful as he/she would be within a team. As a social species, we all need other people to talk to, bounce ideas off of and get general advice and support from. If your goal is to create a quality piece of software that works well, is maintainable, and can handle changes that you’ll throw at it over a long period of time, then you should give your developers what they need to be productive, which is a good cross-functional team to work in.
Therefore, at a minimum you should consider a team of 2-3 developers for your small project. A team of 2 is very minimal, but is infinitely better than 1 if funds are lacking. Scale up (with caution) as needed to meet your timeline and other requirements. Larger projects tend to have more complexity and require more skillsets. If you are missing a required skillset, that will negatively impact quality and the timeline. Again, cautiously build up as needed, and be mindful of the potentially negative impact any added team members might have.
Agile evangelists state that a team of 5-9 is the optimal size for a team, but 5 devs on a really small project is overkill. We also don't like to go above 7 devs on larger projects. If your project is large enough to require that many developers, then you should be able to create separate teams which would likely be more effective. Again, there are always exceptions and each project is different but this is what we've found to be most successful.
About Latitude 40
Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.
Don’t just add developers—add direction. Latitude 40 builds teams that deliver.
Contact us today to discuss how we may be of help to your organization.
Don’t just add developers—add direction. Latitude 40 builds teams that deliver.
Contact us today to discuss how we may be of help to your organization.
About the Author
Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps organizations build right-sized development teams that deliver high-quality software through collaborative, principle-driven Agile practices.
RSS Feed
