Discover What all the Frameworks Have in Common
An agile framework must remain simple for everyone involved to understand it. The same is true for agility at scale.
Let’s begin with your set of agile teams. Keep the number of additional methodological items to a minimum to get your teams working together using a simple and easily understood framework.
The frameworks on the market are really all about capitalizing on skills and expertise. They have proven themselves on the ground and can serve as a source of inspiration.
Each framework includes a number of principles that translate into practices. Adhering to these principles is important because they describe what has to be done. However, practices can and should be adapted because they describe how things should be done, and are therefore specific to your scope.
Phasing, synchronization and alignment are the core principles that provide the structure that underpins all of the frameworks.
It's up to you to gain a good grasp of them so that you can put them into practice! 😊
Ensure Your Teams are Creating Phased Solutions
Phasing is the idea that the items that are being worked on by different agile teams make sense when taken as a whole. As many features may span teams or require the output of other groups, you should ensure a phased solution for your customers is being developed.
What does this actually mean, though?
Understand the interrelated nature of the work you are doing and ensure that when you integrate your work with others that the result is a phased increment of customer value.
But why should I do this?
If you don’t do this, you run into many different types of risks; a few are outlined below:
Some features may not be fully releasable if they lack a key component that, for some reason, wasn’t completed.
Customers or users may feel like a release of value is disjointed, and while everything may be done, it may feel disjointed.
Without a phased plan, you may not be able to deliver on a key goal for your product, but instead, just focus on getting work done.
Testing, documentation, communication plans and updating all the relevant people outside the teams may get more complex and more difficult.
Benefits:
A clear benefit to customers from having a phased release.
Product Owners will be able to more easily maintain a roadmap with milestones.
Teams will feel an increased sense of pride by contributing to a shared goal rather than disconnected work.
Testing, documentation, communication with stakeholders, and other related work are clearer and usually easier.
Synchronize Your Teams
The principle of synchronization enables the following at the end of each iteration:
Integration of the work completed by all of your teams.
Benefits:
Integration problems are detected and corrected as early as possible.
Lower correction costs.
A demonstration of a unique and common product.
Benefits:
Frequent feedback loops.
Teams that are moving in the right direction together.
Synchronization may mean that you want to have a standard, or at least consistent, cadence of iteration lengths. You should always balance the desire for synchronization with the problems, expected benefits, and empirical data rather than just asking teams to comply with a “standard.”
Hmmm. I’m not really following....
Don't panic! Look at the diagram below:
On the left, the teams are doing very different iteration lengths. They don't have the same rhythm.
On the right, teams 2 and 3 have adopted team 1's rhythm. They are now a lot more synchronized. Whether or not this is enough synchronization among the three teams is subjective and should be discussed.
When starting out, I always advise teams to use iterations of two weeks, with four weeks being the absolute maximum. When iterations are too long, three major disadvantages arise:
A large volume of code that makes integration work difficult.
There is less feedback, as demonstrations are less frequent and too long.
The team may be unable to pivot to changing conditions as easily.
In practical terms, this means establishing a common schedule in which all your iterations start and end at the same time for all of your teams.
Align Your Teams
The principle of alignment mobilizes all of your agile teams in pursuit of a common goal, while avoiding teams going off in different directions.
A best practice is to align your teams along three axes:
A business/functional axis for sharing business challenges so that each team understands how their work contributes to the whole project.
A methodological and organizational axis to harmonize the working methods.
A technical axis for sharing a common architecture, good design practices, development standards, common objectives for code quality, a common testing strategy, etc.
From a practical point of view, there are at least three strategies relating to the roles that secure the alignment of your teams:
You don't change anything! You keep your existing teams and make one of the existing Product Owners and one of the Scrum Masters a “scaled” version of this role.
You keep just one Product Owner and one Scrum Master.
You keep your existing teams, and you add a Scaled Product Owner and a Scaled Scrum Master.
Here are the advantages and disadvantages of each strategy:
Strategy | Advantages | Disadvantages |
1 - One PO per team and one SM per team. One of the PO takes the role of a Scaled Product Owner and one of the SM takes the role of a Scaled Scrum Master |
|
|
2 - A single PO and a single SM for all the teams |
|
|
3 - One SPO and one SSM |
|
|
Your agile events at scale also contribute to your teams' alignment. There are at least two possible strategies when it comes to the participants who should be invited:
Aim for simplicity by inviting the minimum number of people, i.e., a Product Owner role, a Scrum Master role, and a developer from each team.
Encourage exchanges by inviting everyone.
Here are the advantages and disadvantages of these two strategies:
Strategy | Advantages | Disadvantages |
1 - Scaled PO + Scaled SM + a developer from each team |
|
|
2 - Everyone |
|
|
To align your agile teams, you have defined your roles and events at scale. Without realizing it, you have laid the foundations for your own agile at scale framework! 😃
Over to You!
Suggest a common agenda for the Fidelio scope and its two-team system.
Select an organizational strategy for your roles and events.
Answer Sheet
You can consult the answer sheet to check if your strategies are correct.
Let's Recap!
To get agile teams working together, it's best to use a simple framework that is easy to understand.
Phasing teams sets a rhythm that is common to all.
Synchronization provides integration and frequent demonstrations of the common product.
Alignment ensures that all of the teams are indeed moving in the same direction.
In practice, alignment is realized using an organizational strategy based on roles and agile events at scale.
You have now mastered the associated principles and practices. I suggest that you now select your agile at scale framework.
