US National Archives - Creative Commons image

Workers assembling radios. Photographer Lewis Hine. US National Archives – Creative Commons image

Typically in plan driven model, scope is fixed and the cost and schedule are variables.  Many large scale software projects were and continued to be implemented this way.  In many instances, when a particular scope is desired within a giving time-frame (fixing the schedule), plan driven projects add resources.  But as we know simply adding resources to a project doesn’t always bring about the desired goals.  As a matter of fact, if resources are added late on a software project, it actually has an adverse effect.  This was indeed observed by Fred Brooks in his book The Mythical Man Month, also known as Brooks’ Law: “adding manpower to a late software project makes it later”. 

With Agile software development, the triangle gets  inverted – where cost and schedules are fixed and the scope is variable.

Waterfall-Agile Triangle

Even for Agile projects, there could be instances when a fixed scope is desired within a given time period.  For example, when an external entity drives a compliance or mandated project.  In those instances, the only lever stakeholders may have is adding resources for a delivery with fix scope and schedule.  But, are there better ways to add resources or capacity to an Agile project without falling in the same traps of experienced with plan driven methods?

Before we answer that, lets briefly consider teams on Agile projects.  Agilists  have generally made 2 recommendations for effective teams:

  • Keep team intact or stable for a long periods of time
  • Keep team size between 5-9

A recent paper called The Impact of Agile Quantified seems to support these two recommendations out through empirical data.

Stable teams, defined as having less than 10% membership change in a 3 months period vs Unstable teams defined as 40% variance in their membership tend to:

  • Have more throughput (volume or work)
  • Have less variance in their  throughput (they are more predictable)
  • Have less defect density (higher quality)
  • Have less time in process (better time to market)

From the same research findings, teams of 5-9 team members have the most balanced performance when it comes to predictability, productivity, quality and responsiveness.   Generally, smaller teams (of 1-3 people) are 40% less predictable and have 17% lower quality; however, they do have 17% more productivity.

Instability in Agile teams can happen sometimes which may not be in direct control of the resource managers.  Like, for example, a team member gets promoted or changes positions or leaves the company altogether.  In some instances, a resource manager may also have to move team members due to skills match, team dynamics or performance considerations.

So given these findings, what would be the best options in adding resources to an Agile project or a release?  Creating a whole new cross-functional team of 5-9 team members during early to mid part of the project along with a Product Owner and a ScrumMaster (presuming you are following Scrum) would be the best option.  This will allow added capacity without running foul of the Brooks’ Law.

But if the budget add doesn’t allow addition of an entire new Agile team, then other viable options becomes little less ideal.  One option would be to add team members to an existing team to make them more cross-functional or remove a crucial skills constraint, so the team becomes more self-sufficient.  The other option is to shore up smaller teams that have less than 5 team members.

Alternatively, you can level-off a larger team and form 2 teams.  Take for example, there is additional funding for 4 team members and Original Team A makeup: 9 team members + PO + SM.  Form Team B: 5 team members – 3 new team members + 2 team members from Team A (presumably a team member can initially serve as SM initially) and  a PO.  Now New Team A would be: 7 team members + PO + SM.  Since, both teams would be within the ideal size range, and assuming you are able to maintain the cross-functional nature of both teams, you can still reap the benefits of higher throughput, better quality, more predictability and better time to market.  Again, these aren’t the best options because affecting existing well performing teams will inevitably create an initial setback as new teams re-form and then re-norm.

Ideally, if short term results are desired, say within a quarter, scope reduction is probably still the best option instead of disrupting Agile teams.