Why bigger team doesn’t ensure faster results in software development
716
Software development is unlike mass production. It is actually quite similar to reproduction: if you want to receive a well-made and useful product, you need to treat it like a baby. There are you, the customer, who brings the idea, and there is a software vendor, who composes a required team, which delivers a product in some time, with appropriate care and attention.
Having a bigger team might seem great — but similarly to how 9 women can’t give birth to a single baby in one month, increasing the headcount on a software delivery project does not equal increasing its efficiency and reducing time-to-market. Read on to find out why.
Specifics of the software development field
Let’s take a closer look at 5 important aspects of the software development life cycle.
- There is a software development and project management law (unfortunately, not enough-known) – Brooks’ law: “Adding manpower to a late software project will mate it later, not shorter”. This means, that when you have a team that fails to meet deadlines due to some trouble, but promises to deliver the product in the end, just somewhat later — adding new people will not solve the problem. The team has an in-depth understanding of the product, knows the obstacles they have to overcome, and can provide approximate evaluations of the time and effort needed to achieve the result.
Should you add more people, somebody will have to dedicate their time to onboarding new resources, which will prolong things in the end. This also adds more uncertainty, human error risks, and the need for additional control — quite the opposite of the expected result. - One of the visionaries of software engineering, the author of “You can’t control what you can’t measure” principle, Tom DeMarco has stated that “when you concentrate on control and metrics, you get projects aimed at delivering some MARGINAL results on time, instead of delivering value”. A much better approach, according to DeMarco, would be to “concentrate on projects where precise control won’t mean too much. Then, we need to reduce our expectations on how much we are able to control, no matter how hard we try to” © Tom DeMarco.
In other words, software delivery projects take as long as they take. The best way to ensure they are delivered on time is to set adequate deadlines (read our previous article on the importance of correct project estimates). You should understand that software delivery is all about adaptability to overcome unexpected obstacles, with expertise, appropriate tools, and transparent management — not rigid planning and tracking artificial metrics. - It is also important to note that much software development projects depend on open-source libraries and components, which the developers have no control over. On the plus side — you don’t need to pay for building every little module from scratch, there always are some building blocks. On the flip side, if some update to any such library is needed to continue the work on your project — the developers can’t guarantee this update will happen according to your schedule.
- Yet another aspect that affects the project longevity is the implementation of new technologies — programming languages and frameworks, etc. According to studies by Robert Glass, yet another software engineering specialist — software developers work in reflection cycles. They receive a task and try to accomplish it using the tools at their disposal. Regardless of whether they achieved the result easily or had to overcome obstacles, with time they have to stop and reflect on alternative ways of doing things.
From such reflections, new concepts and ideas are born, as people constantly seek better ways to achieve results — or we would still all be writing code in Fortran and Algol. We have quite the opposite, as new programming languages and frameworks appear all the time, and developers have to stay up to date with these advances.
It means they need some time to experiment in order to provide the best result for your project. This is impossible if you expect everything to be done perfectly first try. - SDLC is actually not a cycle but a spiral, according to Barry Boehm, a renowned software engineering expert. Unfortunately, software projects tend to spiral out of control, when more people are thrown at the problem.
Source: The IT Measurement Compendium
This duration can be compressed by up to 25% if appropriately more people work on the project. Compressing it beyond that point is not possible, as adding more people only prolongs the project duration.
To round it up: small (up to 8 people), established teams with polished processes are best for delivering software projects in a timely and predictable manner. Increasing the headcount does not mean increasing the project delivery speed, and often leads to the opposite.
The mutual dependence between the scope of work, its duration, and cost
We are sure you are all well-acquainted with the Venn diagram:
Quality is always somewhere there… but is never in the center. So keep your expectations realistic.
There also is the “iron triangle” principle:
Whichever of the triangle corners you want to adjust, two others will adjust accordingly.
No verbose explanations are needed here, don’t you think? But how to go ensure good product quality in software development then?
The quality of the team and the workflow organization
The expertise of team members means a lot. Hiring 8 junior developers might seem a way to conserve resources — until you realize the cost of their potential errors. Senior and middle software engineers composed into cohesive teams might cost more — but are much more likely to deliver the expected results on time. Keep in mind the long-term implications — the better the quality and architecture of a product, the easier it is to maintain and update.
As a popular misconception, Agile is considered a flexible project management approach, enabling you to switch project goals, architecture, and features in the process. As it stands, Agile is more about flexibility in achieving the expected results — but those results should be planned in advance nonetheless. Even if you decide to add or truncate a feature mid-development — it is better to plan this task for the next product version rather than readjusting and repartitioning all the tasks planned.
Sometimes customers think that if they push the Project Manager to promise to deliver the results in a shorter time, he/she will then push the team to do this. The correct answer to that is “it takes as long as it takes” — remember the pregnancy reference? Excessive optimism in assigning deadlines will totally expectedly result in not hitting those ambitious goals. When the team evaluates the project complexity and comes up with estimates — you might like them or not, but they REALLY can’t be made any quicker or cheaper. Well… you can… by reducing the quality, as shown above.
At least, this is how we do it at Academy Smart. We evaluate the project complexity honestly, provide transparent estimates, and guarantee good product quality as a result. Should you experience this firsthand, get in touch and let’s discuss the idea of your next project!
