Points of View

In Agile, size matters – Project executives must focus on building the right team for the job

Jun 9, 2020 Cyrus Semmence

How many of us can recall a conversation when the only solution on offer to improve delivery speed was to throw more resources into a project? “Big teams are faster” is perhaps one of the biggest myths of project management, and when it comes to Agile Project Management (APM), building the right team is far more critical than rallying as many troops as possible to throw into the battle. Project executives must realize that adding resources to a project won’t necessarily make things go faster. In fact, it could cause things to take longer. Spending time getting the right team size and structure will pay dividends down the line.


In most cases, modern businesses have two distinct parts. Business as usual (BAU) is where the day to day activities that generate revenue sit, as well as the operations that support those activities; for example, sales teams (and the functions that support them) trying to win more business. And then there’s the difficult world of “change”—project work that originates from a need to change the business—perhaps to respond to market forces or a new wave of regulations, or because a shiny new technology promises to double revenues and halve costs. In the financial services industry, you often hear these two essential business components captured in the elegant and straightforward phrases “run the bank” and “change the bank.”


When IT use exploded in the 90s and 00s and the drive to centralize infrastructure began, it was common to see multi-skilled teams working on projects with team members from both sides of the fence—BAU and projects (if there was even a fence in the first place). This practice brought real benefits, as it meant anything going into production would also be supported by the people who built the solution. The strategy was not just a case of throwing a project over the fence into production and hoping for the best.


Skills commoditization reduced quality along with costs as businesses sought simplicity in complex project structures


As complexity grew and companies expanded, we saw a shift toward a production line and, manufacturing mentality. Platforms and roles dictated team structure, a natural evolution as IT workloads and team sizes grew exponentially. Beleaguered managers welcomed any form of simplicity in complex environments. For example, ERP rollouts would include both project and BAU teams in the form of development project and production application support teams. This approach had significant benefits for the commoditization of delivery. Breaking everything down into its components makes sense when the goal is to efficiently distribute work packages to the right teams. The costs could be easily quantified; however, there was a problem. IT projects are notoriously complex, and with this new model, team members tended to focus on their remit instead of engaging with other teams. As a result, the number of professionals with a good understanding of the end-to-end solution withered, which often caused increases in defects, coordination overhead, and delays.


The Agile evolution shows us this: bigger teams mean slower projects


Research conducted by consultancy QSM back in 2005 spotted the challenge with large teams delivering distinct parts of complex projects; it concluded that smaller teams were more efficient than larger teams by a significant margin. The research studied 564 information systems projects completed since 2002. Larger teams (more than 20 people) took an average of 8.92 months to complete 100,000 equivalent lines of source code. Smaller groups (with fewer than five professionals) needed just a week or so more—9.12 months—to complete the same work. The cost of the larger team size didn’t pay off in the long-run.


Bafflingly, the pressure to meet tight deadlines seems to fuel the assumption that increasing team size and splitting the work into small sub-projects allows teams to work on simultaneously and reduces the time needed to complete the task. But with increasing communication overhead, more exposure to risk, and managing more complexity, the reality is far from the expectation.  The bigger the team the more interruptions team members will face leading to a reduction in focus.


Another study published in 2012 by UCLA puts more light on the topic. An interesting experiment tasked two teams, one with two people and one with four, with making a model of LEGO bricks.  Unsurprisingly, the team of two completed the task in 36 minutes—20 minutes faster than the team of four.


The APM and DevOps model comes into its own in this environment. The team that runs the platform is also responsible for delivering change into that platform, which has some distinct advantages. Working in ops tends to be repetitive break-fix work. It means team members are not being pushed to learn about the more complex aspects of the systems they are supporting, resulting in de-skilling and difficulty in maintaining an optimum level of morale. By adopting the DevOps model, everyone in the team is learning and supporting all aspects of the software platform. There is no throwing a project change over the fence and running away. With a business product owner dedicated to the DevOps team, you ensure the business is working closely with an efficient, self-sufficient team. One caveat is that a small team needs each member to be more skilled than those on a large team, which can draw from a bigger pool of experiences.


The Bottom Line: Quality over quantity is the key to successful software project delivery.


There are countless cases of failing projects where senior executives tried to solve the problem by adding resources. However, only a small percentage of these efforts led to success. Our candid conversations with industry executives reveal a maturation of the approach enterprises are adopting when working with providers, many of whom still rely on traditional routes to rescuing at-risk projects by bringing in more resources in the hope that delivery speeds up. The common misconception is that many teams working in parallel will speed up delivery. What is required is a more highly skilled agile team that can get on with delivery rather than spending their time working on development conflicts with other teams. As the old saying goes, if it takes a woman nine months to have one baby, you can’t bring in nine women and expect a baby in one month.

Sign in or register an account to access HFS' Content

Sign In

Create an account

Enter a phone number
Select the newsletter(s) to which you wish to subscribe.