Category: Scaling Agile

US National Archives - Creative Commons image

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

Typically in a 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 through empirical data.

Stable teams, defined as having less than 10% membership change in a 3 months period, versus 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.


In articulating agile requirements, best practice is to write user stories. A user story follows the 3 Cs process – Card, Conversation, and Confirmation.  At team level, a product owner who represents the business owns the story card.  The product owner through the card briefly states from a business perspective what she wants the delivery team to build.  The card is generally stated in the user story format of As a <user role> …I would like <build functionality>….so that I can <achieve a business goal>.

The story card was originally intended to be written down on a 4×6 index card.  The requirement in this case are barely sufficient to convey the intent and idea of what needs to be built and the details are left for latter conversation with the team and the Product Owner.  The acceptance criteria were sketched out on the back of the card.  The card serves as a reminder for a future conversation.  In the traditional software development, going through staged gates and going through functional silos, meant more emphasis on writing things down.  That is how we did handoffs from one stage to another, from one functional team to the other.

With Agile, we sketch out our idea about the requirements with the assumption that at the onset of the project, we don’t always have perfect information and that information and situations do change on the ground during the implementation of the project.  We also have cross-functional teams which obviate the need of writing detailed specifications.  So for example, a cross-functional team with development, QA or test, analysts, and database resources won’t need explicit documentation as each of these team members participate in all conversation regarding their backlog and projects.  These conversations could in formal meetings such as planning sessions and story grooming sessions or informal conversations with Product Owner and other stakeholders.

So far so good, all of this has now been well understood with the basic agile approach to requirements articulation.  But, with the use of Agile Lifecycle Management Software, sometimes Product Owners and teams have tendency to forego the brevity required with the use of 4×6 index cards.  Soon, if you are not careful, a story card starts resembling software specifications documentation.  Similarly, scaling Agile to multiple teams and multiple projects sometimes necessitates that the Product Owner role would get further refined.  Leffingwell highlights two distinct set of responsibilities: one that is market/customer facing product managers and another that is solution/product/technology facing product owner (Leffingwell, 2010, Loc 4078 of 10384).  At a high level, Leffingwell assigns these responsibilities to each of these distinct roles:

Agile Product Owner Agile Product Manager
Product/Technology-facing Market/customer-facing
Co-located (may report into development/technology) Co-located (may report into marketing/business)
Focuses on product and implementation technology Focuses on market segments, portfolio, ROI
Owns the implementation Owns the Vision and Roadmap
Drives the iterations Drives the release

With this type of distinction, it generally falls to Agile Product Manager to own the higher level Feature and Epic definitions at the program/project level; whereas, the Agile Product Owner is focused at the sub-epic, story level with their respective teams.

As the Product Owner responsibility gets split, product management and their respective teams have a tendency to revert back to form and rely heavily on process, and on the ALM software, which then starts resembling the traditional requirements gathering process.  Product Managers may engage in heavy requirement sessions and considers that to be the end all and be all.

But fundamentally, the concept of 3Cs doesn’t go away with Agile scaling – the Agile Product Manager can still maintain just enough documentation at the feature and epic levels and then use conversation with other Product Owners to drive the details, just as a Product Owner would do for lower level epics and story with their respective teams.  The concept of having information tomorrow than today still holds.

Mike Cohn makes 3 points regarding writing requirements down in details and relying on it as a primary communication tool (Cohn, 2009, pg 237): 

  1. Written documents make things official, team members will suspend judgement about challenging it.
  2. Written documents tend to discourage everyone from iterating over the intent and meaning as we do in conversations
  3. Written documents are instrumental in creating seuqential hand-offs and they tend decrease the whole-team responsibilites

So the key then remains in having conversation within the product management team and then laterally with the agile teams so that ambiguity can be driven out, intent can be clarified, and the story boundaries can be defined, on a continual basis as new information gets uncovered about a project.


  • Leffingwell, Dean, 2010, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Kindle edition, Addison-Wesley Professional.
  • Cohn, Mike, 2009, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional.
%d bloggers like this: