Understanding current reality with Scrum@Scale

A facilitation and systemic coaching method

Carl J Rogers
Agile Insider
4 min readSep 10, 2022

--

I have been experimenting with using the Scrum@Scale framework diagram to help groups build a shared understanding and alignment on the current state reality of a network of teams. This is one step in a wider organisational change effort, not a complete cycle. Nor is the goal to implement Scrum@Scale, just to use its design to facilitate a conversation.

Start With Now

In his book Change.: A practitioners guide to Enterprise Agile Coaching, Simon Powers presents the Enterprise Change Pattern, which he defines as:

a step-by-step guide on how to rapidly change an organisation so that everyone works together to solve the real hidden problems that stop an organisation from making the most of its opportunities.

The engine of this pattern is the experiment cycle. Good experimentation requires an understanding of the current reality. The first step of the experiment cycle is therefore to Start with now, and align people to this. Corollary to this is the first principle of Kanban, start with what you do now, and is a pre-requisite to the second, agree to pursue incremental, evolutionary change.

The first rule for the Enterprise Change Pattern is that Start with now is conducted with systemic coaching and advanced facilitation that includes what people feel (important) as well as what people do’. This method is but one approach.

Scrum@Scale Framework

Scrum@Scale has 13 components within two cycles: the Product Owner cycle coordinating the “What”; and the Scrum Master cycle coordinating the “How”. Depending on how you anticipate these terms resonating within your context, you may wish to go simply with What & How.

The Executive Action Team and Executive MetaScrum are in the heart of their respective cycles, however given as the goal is not to implement Scrum@Scale in this exercise, I have been removing these two components to focus on the cycles themselves.

It is necessary to have a grounding in the framework, or otherwise sufficiently understand each component so that you can provide clarifications and help people determine where to best place their observations.

The Scrum@Scale component diagram
Scrum@Scale component diagram

The Workshop

The participants for this workshop represent the lowest level of leadership within the network of teams with authority to make change to process and structure. We also seek to ensure that all voices are heard from the network so that we maximise perspectives on the current system.

I’ve run this session virtually so far, using Miro to create a board like below which all participants have access to. Each component has a linked box that participants can add observations to using sticky notes. This format can certainly be applied to real life, you just need a suitable amount of space for people to work around.

Miro based workshop template using the Scrum@Scale framework
Workshop Template

From the perspective of De Bono’s six thinking hats this session covers White and Red hats. Firstly through White hat thinking in the gathering of facts from a neutral and objective viewpoint, and articulating what we know now.

Having provided a quick orientation to the framework components, the first step is to ask everybody to capture what they know about the system in the relevant boxes. Given that it is unlikely everybody will have a complete view of the system, I have given participants time to consider all boxes together, rather than work through them sequentially.

After a suitable time-box, ask the group to walk through their observations on the board. This is likely to trigger additional ideas so encourage these to be captured on the board as well. Once these feel reasonably (not exhaustively) complete test for any objections in proceeding.

Now we switch to Red Hat thinking by asking the participants to categorise how they feel about how effective each of these components in the framework is today. We’re looking for the groups’ intuition, gut instinct, and feelings right now. As the next step, participants colour code their observations red, amber, green for working well, good enough for now, and in need of improvement. A useful prompt, or question to save for the walk through, is ‘what supports this view’? While reasons for feelings don’t have to be given, this helps start to qualify evidence being gathered on the current state.

As before, after a suitable time-box, review the board with the group and test for alignment, cautions, or objections as each component is discussed. From this we have a view of the current system for ‘what we do’, and ‘how we do it’; and a view of the hot spots where improvement is needed. A next good step might be to explore the relationships between these areas, e.g. the relationship between issues with Backlog Prioritization and Delivery, or Release Planning and Cross-Team Coordination.

From this further exploration of the current state may be necessary, or you may have the basis already for beginning to form hypotheses for where improvements could be made to the system, and what these can be.

Can you see this being useful? How might you improve it? Please do leave a comment as it would be great to build on the ideas presented here!

Check out part II of this experiment.

--

--

Carl J Rogers
Agile Insider

Join me on my exploration of de-scaling, agile mindset growth, and agility experiments within the context of large, complex networks of teams.