Agile is now the default way to run project and product initiatives. Either at an enterprise level or within just a few application teams, companies today have gone down the path of adopting agile methodologies into their development lifecycle in order to reap the benefits focusing on business value, continuous improvement and embracing that the environment will forever be changing.

For those new to agile software development, it is best described as an approach under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers / end users. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement to deliver software in a rapid and flexible response to change.

Success in agile can often be achieved with smaller sized teams (10 people or less), but many companies are struggling to take agile methodologies to the next level by either scaling to a large single application team or scaling at the enterprise level.

I have observed approaches to scaling agile that introduce new challenges and, ultimately, make a high performing agile team less effective. These approaches (with slight variations) are:

1. Adding developers disproportionately to other agile team member roles.
2. Increasing team member numbers but not scaling supporting tools & processes (e.g., Development Operations [DevOps] and Planning).
3. Increasing the length of a sprint or the number of sprints.

These methods fail to increase throughput because they create bigger bottlenecks with testing, deploying, etc., or as with the case of the longer sprint, they increase batch size. This is an anti-pattern to the lean agile approach. Scaling agile effectively involves adding elements of all team members proportionally to create multiple encapsulated agile teams. These standalone teams are commonly referred to as feature teams. The number of feature teams can increase the overall development capacity by aligning them to logical scope within a single application.

In the following diagram, the feature teams include members from product management, development, architecture, security and the testing teams. Even though all the feature teams are working on a single application, these fully functioning agile teams work independently on separate backlog items with continual integration of the code.

Successful scaling of agile incorporates the following principles:

1. Ensuring collaboration between teams increases as much as scaling team member numbers. Often a feature lead role is used to ensure effective collaboration between the multiple feature teams. These feature leads are assigned very early in the product lifecycle.
2. Scaling team members in proportion for all roles on an agile team. As noted in the diagram, the ratio of product team members, developers, architects, etc. are proportionally in line with other feature teams, and therefore staffed optimally.
3. Increasing release and product planning activities as much (if not more) than scaling in team member size. Introducing Program Increment (PI) Planning concepts is an effective way to plan at scale. Pipeline meetings and cross program prioritization are critical activities when scaling agile.
4. Increasing DevOps capabilities to support increased technical complexity such as multiple code branches, multiple environments, and additional development dependencies.

The benefits of scaling agile by creating multiple feature teams are:

1. Effective communication between teams to ensure alignment and dependencies are identified and tracked.
2. Increased overall throughput of development capacity.
3. Increased flexibility to ebb and flow teams to specific functionality or capabilities.
4. Re-enforcement of the team mentality.

For example, Kenway has guided clients that scaled their agile teams by adding many developers, without increasing their product management capacity accordingly. After correcting the proportions of all agile team roles or creating additional teams to maintain the optimal team size, we introduced a new feature engagement process that added a monthly pipeline review meeting, feature prioritization meetings, and ensured (well, maybe forced) collaboration between agile teams. Effective communication was significantly increased, and all agile teams felt more connected with the feature roadmap while optimally planning for upcoming features.

Kenway provides IT Strategy services that can help any team trying to scale agile or just wanting to take their effectiveness to the next level. To do this, we can provide embedded expertise inside your delivery teams to provide coaching and / or scrum mastering to teach effective agile techniques while performing work as part of the agile team. Or Kenway can help by conducting an agile assessment to provide an outside perspective with observations and recommendations to make your agile team(s) more effective.

If you’re interested in learning more about Kenway Consulting’s approach to agile methodologies, please contact us at [email protected].