Scaling Agile for Larger Teams

Scaling Agile for Large Teams

Over the years, Agile Software Corporation has had to evolve their Product Lifecycle Management (PLM) software in order to cater to larger teams (often broken down into groups) who employ the software at program level.

This post covers the key objectives of the agile approaches designed for large-scale projects; two particular approaches that will be discussed are “Scott Ambler’s Disciplined Agile Delivery” and “Dean Leffingwell’s Scaled Agile Framework”.

Both these approaches seem to be a re-evaluation of IBM Rational Unified Process framework. A common concept in these three approaches is that teams can balance upfront planning needs while maintaining Agile's ability to improve the plan based on empirical observation of actual results. These approaches also highlight the architectural framework of a software that enable it to provide larger teams with a steady base, such as feedback through iterations, technical practices to build in quality, and lean thinking to optimize the overall system.

There are a few Agile approaches that are still popular for larger teams such as feedback afforded by iterations in Scrum and technical practices that are focused on ensuring quality. These frameworks ensure that relationships among agile teams are synchronized; it is important to be particular about the alignment of teams so as the timely release of the product is definite.

Three general underlying principles for methods of scaling agile for teams consisting of seven members to as many as 100 members are:

  1. Investment governance: Larger projects require higher funding and investments; this necessitates increased levels of preparation so as to justify the numbers. Additionally, the dependencies amongst teams would be more intricate. Features, infrastructure work and nonfunctional requirements are also a matter of concern. Lastly, investment gate models are a must so as to guarantee wise allocation of funds.
  2. Technical architecture: Guidelines and patterns need not be decided beforehand when dealing with smaller agile teams, however in the case of larger teams a lot of deliberation is required with regards to overall design and architecture as these factors lead to better coordination amongst teams. Furthermore, with larger teams, as the demand for shared infrastructure increases, the people who work as part of supporting teams that create features also gain more importance.
  3. Metrics: Larger teams require specifically designed metrics that provide a comprehensive view of the entire team and its health in terms of performance by providing data of the smaller groups within. By giving a clear picture about where exactly the project stands, these metrics facilitate project leaders in taking decisions that have wide-ranging impacts on the project.
Muhammad Zeeshan Ali's picture
A Senior Advisory Software Engineer at Systems Limited with over 12 years of experience in Traditional and Agile Project Management, Zeeshan Ali is based in Lahore and is a regular contributor of the Systems Limited Blog.

Disclaimer: The views expressed here are solely those of the author in his private capacity and do not in any way represent the views of Systems Limited, or any other entity related to Systems Limited.


Anonymous's picture
Submitted by Anonymous on Wed, 09/30/2015 - 18:53

Decent and simple thoughts on working with larger teams
Asma 's picture
Submitted by Asma on Wed, 09/30/2015 - 22:33

Impressive article to help new agile professionals managing large teams

Add new comment