Published on

More people means more what?

Authors

More people means more what?

In the world of capitalism, most organization have deep desire of quickly develop and deliver products or features. The whole agile manifesto is to increase the agility and quality of the software produced.

Even today I hear phrases like

We need to get this done by x, and we are ready to put more bodies at it'.

Most times it feels like its purely mathematical, we all have heard the questions like if x men can build a wall in 12 days then how many ...

Yet, the landscape of work, especially in IT or other domains, has evolved into intricacies far beyond the simplicity of constructing a wall. In fact now a days even building a wall could be very complex in the context of artworks. A team of researcher / designer will do a deep research on the social or historical topic, figure out what the design will represent, develop multiple prototype, discard or select one, develop with a team of developers and so on. This way we changed the paradigm from plain task to complex work.

Now x people are not making it fast but adding to the value of the wall. Coming back to IT or any other domain, domain is becoming complex and most times more people won''t necessarily mean it gets done faster. This article talks about what do more people can add? and how should you add more people?

What do more people can add?

Quality

Increasing team size contributes to enhanced quality. The addition of more individuals brings diverse perspectives, broader coverage in conceptualizing business flows, better idea refinements, and more research.

Run more prototypes

In many instances, teams conduct time-boxed explorations. Having more team members available amplifies the capacity to explore diverse ways or prototypes before making a final decision. Consequently, this elevates the quality of the product and promotes deliberate decision-making. When a team selects a technology or solution after considering numerous viable options, the likelihood of success is higher, mitigating the risk of adopting a fail-fast approach. Not denying the fail-fast approach here by any means.

Reliability

With more people you get different skill set in the team, which adds reliability of the product. The complexity of an application development gets extended to infrastructure, best use of cloud services, observability itself is such a huge domain doing it properly mean you need specialised skill.

Elevating Security in Development

Security considerations are frequently an afterthought in development, often controlled or addressed through organizational policies. While this approach can accomplish a fair amount with minimal investment, true security must be ingrained at the core of the development process. The infusion of experienced engineers into the team, providing them with dedicated time to meticulously review code, make necessary amendments to enhance security, and steadfastly avoiding the accumulation of technical debt are overarching advantages.

Teams are frequently caught in a balancing act between applying security patches and developing new features. The common narrative involves business deprioritising upgrades or patches to expedite feature delivery. This compromise poses a significant threat to security, which falls short of the ideal standard.

Adding redundancies

More people reduce the risk and dependency on individuals.

How to add more people

Strategic Team Expansion for Efficient Collaboration:

The addition of more team members necessitates a thoughtful strategy to ensure productivity and collaboration. This involves breaking down the entire project into smaller, manageable tasks or problems. This modular approach enables multiple teams to concurrently address distinct components, ultimately contributing to the creation of a tangible IT artifact, be it a package, Docker image, or provisioning code—all neatly encapsulated within a Git repository.

Crucially, each team producing an artifact meant for internal use must adopt a customer-centric mindset, viewing the internal teams as their customers. This perspective fosters a culture of collaboration and service within the organization. Unfortunately, in many instances, departments overseeing policies may lack the principle of considering other teams as customers. However, the underlying idea is to ensure that the artifact is not only functional but also customer-friendly.

By instilling this customer-oriented approach, teams contribute to the development of IT artifacts that are not merely functional but also align seamlessly with the needs of the end-users—whether they be internal teams or external customers. This strategy promotes efficiency, collaboration, and the creation of high-quality, reusable artifacts within the organization.