Why did soldiers drill on parade grounds? Was this simply a way to keep them busy during those long days of encampment between battles? Was it so they could look good after a victory when they paraded in full regalia before the king? These were surely part of the purpose, but primarily it was to make sure the soldiers could effectively maneuver on the battlefield as a coordinated unit and not as a mob. It had life and death ramifications. If they did not quick step together, form ranks and prepare to fire in a coordinated way, they would be overrun by the enemy, or even worse, end up shooting each other. Working to a cadence (the fife and drum) was the key to them being able to maneuver in the midst of the battle. The army who did these maneuvers most effectively won the battle.
This same principle applies to agile at scale. In large scale agile there could be dozens if not hundreds of teams who must work in a coordinated way. They need to all integrate into the same build stream. They must all be able to test in a common integrated environment. They must all have code in a shippable state when the code is going to be deployed. Changes in direction must be implemented in a way that doesn’t create chaos. Let's focus on the critical role cadence plays in helping these large scale initiatives achieve the coordination necessary to quickly change direction successfully.
The first step in being able to effectively change priorities within and between large initiatives is to organize in a way to maximize self determination while minimizing the amount of coordination between small delivery teams. In the Revolutionary War, patrols and companies were the unit of delivery on the battlefield. These self sufficient units could be given an objective and be expected to achieve that objective with minimal communication with other companies. The cadence allowed them to do this. If objectives changed, entire patrols or companies would be redirected, again cadence would allow them to pivot and maneuver together and stay coordinated with the other companies.
The Scaled Agile Framework (SAFe) provides a similar structure to support this principle. SAFe starts with agile teams who are part of Agile Release Trains (ARTs) or programs of 5 to 12 teams. Both of these structures are self determining and self sufficient to achieve their objectives with minimum coordination outside the ART. The next level in SAFe are Value Streams. A Value Stream can have from one to dozens of ARTs. A Value Stream encompasses the end to end delivery of value to the customer. It is designed to minimize coordination with other value streams.
Cadence is the key to effectively redirecting teams from Value Stream to Value Stream or from ART to ART. One side note before continuing my discussion on cadence. Redirecting people should always be done at the team level. This minimizes the forming and storming involved in organizing new teams or ARTs. It minimizes the demoralization that occurs with team members left behind. In battle they would never try to reorganize the commands even after severe casualties. The companies would continue to operate as depleted units. Even after the battle they would not reorganize, but rather, replenish the ranks or replace them with fresh companies. Maintaining the history and relationships of the veterans was a critical component to army effectiveness.
There are two cadences that are important in SAFe. Every team must be on the same two week cadence for their iterations within an ART, and every ART within a Value Stream must be on the same program increment cadence. Being on the same cadences allows the organization to pivot at the boundaries of the increments and iterations with minimal disruption to quality, objectives and people.
Let’s look at a few common scenarios and how cadence supports the pivots.
Scenario 1: I need to start a new value stream, and I need teams from two other value streams to form this new ART.
Best choice: Shift teams during the IP iteration as shown in the chart below.
This approach will have no impact on objectives and minimal impact on the planning for the old value streams. They may need to provide some support for a short period of time. The teams pulled out will immediately start preparing for the first planning session of the new value stream by doing other preparation work such as setting up environments, preparing build streams, etc.
Second best: The business may determine they cannot wait for the next Increment to end. They need to move now. In this case, pivot at the end of the current iteration as shown in this chart.
This presents more issues, but is still better than pivoting mid-iteration. The old Value Streams will have to do a mini replan based on losing these teams, but if they are doing a good job of minimizing dependencies between teams, this should be manageable. In this case, because of the rush, the teams will likely not have enough time to prepare adequately for the new value stream planning session. They will have to build into their plan spikes and other stories to set up their environments and deal with all of the unknowns.
Scenario 2: I need to shift teams from one value stream to another due to business priorities.
Best choice: Pull the teams from the first value stream during its planning iteration, and have them join the second value stream, wherever that value stream is in its increment. This chart illustrates this approach.
Since the teams are joining their new value stream in mid-increment, they need to do a mini plan with these new teams for the remaining iterations. Then they will join the increment planning meeting with their new value stream at its already-planned time.
Second best: If time does not permit to pivot at the first value stream’s planning iteration, then break at the next iteration break as shown in this chart.
Again, this presents the issues I identified above when pivoting mid-increment, but is still better than pivoting mid-iteration.
The primary point to focus on is that in none of these cases was the cadence changed. Never was the increment planning meeting moved to accommodate the pivot. Never is the iteration cadence changed. This is the key point. The goal is to contain the pivot impact to as few teams as possible, ideally to only the teams that are involved in the pivot.
There will be many pressures to reschedule increment planning meetings to deal with a pivot. There may be personnel issues beyond the teams being moved. There may be performance problems that are instigating this movement of teams rather than external market issues. Whatever the reasons for the pivot, do not succumb to the pressure to reschedule this meeting.
Here are the top reasons for keeping the increment planning meeting on cadence.
- The unnecessary disruption to the existing teams who will have their objectives prematurely aborted.
- The risk of increased technical debt as features may be partially finished.
- The risk of not having the program backlog ready for the new date.
- The risk of having key people unavailable for the new date.
- The risk of the new and existing teams not having enough time to get ready for the new date.
- The risk of declining team morale as they deal with this unnecessary chaos.
- The risk of declining confidence in the leadership team that they do not know what they are doing.
Want to get the most out of your business?
Make sure you're getting the most out of agile first.
Our experienced team of agile coaches are ready to lead you towards success at any step in your agile journey. Whether you're looking to undergo a business-wide agile transformation, or get guidance on helping individual teams work better together, our personable, insightful team is here to help.
