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 at least 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. For larger projects, I’d say that 4 should be the minimum depending on the individual project's needs. These 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 from there 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 2 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 at least 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. For larger projects, I’d say that 4 should be the minimum depending on the individual project's needs. These 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 from there 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 2 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.
RSS Feed
