Three tips when working agile at scale

High-performance IT delivery is especially challenging with agile at scale where multiple teams create IT products that have to be combined to deliver value in the end-to-end business process. In a previous blog post, we talked about challenges when working agile at scale. In this blog post we will approach the topic from a different perspective.

At scale has two dimensions: number of teams and number of decision-making layers. What are the implications of working together with multiple teams? What are the consequences of multi-layered decision-making? And what does this mean for training/coaching/mentoring?

In this blog, we will give three tips when working agile at scale.

(This is the twelfth blog in the series “How to train cross-functional teams”, for links to previous blogs please go to the end of this blog)

Transparent Communication

With multiple teams or multi-layer decision-making, lack of information flow often trips us up. Our first tip is therefore to make sure transparent communication is in place. When working agile at scale there’s a lot of dependencies which makes it easy to miss one. If we, instead of just communicating on a needs-to-know basis, make sure we’ve always got transparent communication both with all the other teams and with all stakeholders at each and every one of the decision layers, the risk of missing vital information is less.

We can’t rely solely on written communication, because the nuances and the possibility of follow-up questions are limited. Therefore, we must make sure to also have face-to-face communication. Interactive communication is essential to ensure quality.

There are several commonly used tools to help to get transparent communication when working agile at scale. Scrum-of-scrums can for instance help with inter-team communication when you have multiple teams. When you have multi-layered decision-making, it can help to use a business process meeting there you gather the stakeholders at different levels around the business process. The business process can be detailed into epics and features. When we’ve used this method, the business process divided into epics and features has been visualized on the wall, and at regular meetings we’ve met and discussed the status and actions of each part.

Neither of those examples are, of course, sufficient by themselves. Transparent communications need to be a mindset and permeate everything you do.

Joint Planning

When working agile at scale, all plans need to be aligned. Otherwise, one team’s plan can render another team’s plan impossible due to unforeseen dependencies. One way of solving this problem is with joint planning.

In a joint planning session, all teams and stakeholders plan together. This leads to joint responsibility and that we more easily discover dependencies. Often you need to plan on different levels, e.g., release planning and detailed planning. As well as focused on different areas, e.g., test environments, testing, and business analysis.

Adjustments of plans are often captured during other synchronizing meetings like for instance scrum-of-scrums business process meetings, but you need to regularly have joint planning to make sure we’re all going in the right direction.

Decision Meetings

Agile at scale requires synchronized decisions over multiple teams. If product owners prioritize independently, the teams’ plans will never align. It’s far too frequent with one team being dependent on a user story from another team to fulfil one high priority user stories while that user story has a low priority for the other team. Often because the product owner doesn’t realize the dependency and the consequence of the low priority.

The decisions must also be aligned across different organizational levels. A top-level decision is depending on decisions made on lower levels. If they are not aligned, we wouldn’t deliver the needed business value.

To manage the alignment and synchronization of decision, decisions meeting can be used. This is meetings aimed at synchronizing and aligning decisions. For instance, with multiple teams, the prioritization of user stories can be done jointly with all stakeholders. This means different team’s product owners can adjust the priority to make sure the most business value can be delivered.

A by-product of decision meetings is that it cuts down on the necessary after-the-fact discussions and adjustments. Therefore, it makes the decision process more efficient and transparent.

Conclusion

Agile at scale is challenging but often necessary to deliver the value to the users. We’ve just given you a few tips when working agile at scale. In reality, we could have a new blog series just talking about this topic. Hopefully, this one will be useful.

If you maintain transparent communication with all the other teams and all stakeholders, plan jointly, and use decision meetings to make the decision process more efficient and transparent, agile at scale will work more smoothly and the quality of your deliveries will be higher.

Be aware, most people have learned about agile for a single team with one decision-making layer. Train your teams and stakeholders in the differences.

What is your main tip when working agile at scale?

Please, let us know in the comments below!

This blog has been co-authored by Rik Marselis, Principal Quality Consultant at Sogeti in the Netherlands

(For other blogs in the series “How to train cross-functional teams”, use this link: https://labs.sogeti.com/training-cross-functional-teams/.)