Agile Forest

With so many frameworks out there that tell you how to scale Agile (LeSS, DAD, Nexus, Enterprise Scrum, SAFe, etc) I have for a long time held off adding fuel to the fire by having a blog series dedicated to Scaling Agile. Why? Well because, just like in the early days of foundational Agile (Scrum, FDD, XP, DSDM), it took time for patterns to emerge of what works and what doesn’t.

In this series I plan to not re-iterate the scaling frameworks, but instead highlight the tips and tricks of patterns that aren’t in those frameworks that I have experienced actually works. These are tricks that have worked not once, but multiple times. These are also tricks that I have validated with other organisations, the sorts of things that people have struggled with when implementing agile at scale but amazingly have come up with similar ideas on how to tackle the problem. It is probably worthwhile to note that the sort of work I do is in really big corporations with heavily bureaucratic environments. These patterns have all been discovered and validated at this level for organisations a few years into their Agile journey.

So what is the first pattern? Well, I will start with my biggest one and probably conceptually a complicated one. It starts pretty simple – when you do Agile at scale, yes you have multiple teams, but what supporting mechanisms to you need around the teams? Whilst a few frameworks prescribe the roles needed to support teams I find that they are somewhat lacking. The term I use is a “Leadership Cell”, not because I see this group of people lording over the teams, but because they are likely to be each leading a backlog.

The Leadership Cell are backlog and decision authority functions of six key areas: Customer Experience, Product Ownership, Adoption, Technology, Delivery and Coach.

These areas each own their own backlog. The Customer Experience area, is focused on customer facing (internal or external) experience, needs, problems, consistency, journey and simplicity. The Product Ownership area is focused on the business needs, problems and worthiness of potential business solutions. The Adoption area is focused on ensuring benefits get realised, change is effectively managed and adoption (internal or external) is successful. In a number of organisations the Product Ownership and Adoption areas are owned by the same person. In smaller scaled environments all three roles may be owned by the one person.

The Technology area is focused on technical problems, needs, solutions. Concerns like increasing technical debt, keeping on top of patch upgrades, sustainability of long term operability of the codebase, etc are great examples of backlog categories of work they may have. Enablers could also be considered technology backlog items, but I prefer enablers to be driven from business need and should be part of Product Ownership.

The Delivery area is potentially more amorphous. In larger enterprises there is a considerable amount of work related to governance, policy and procedures. The Delivery area is focused on getting through these activities. In a great Agile enterprise these activities should be small in number and automated as much as possible, but as most organisations are on a journey this area needs to be the conduit between the old and new worlds, until at least, the enterprise has undergone governance simplification. In addition the Delivery area should be focused on sustainability of pace – are team empowered to pull, is the pipeline realistic given the number of teams, is quality being traded off, is flow consistent? Importantly, the Delivery area is the glue that helps to bind the other areas together if they are not – they are the champion of collaboration across all of the areas and are asking the important questions when a trade-off needs to occur between the areas. They will manage escalations up and shelter the teams, just like a Scrum of Scrums Master.

These areas do not have to be filled by six different people, individuals may fulfill one of more of the key areas – but be wary as it will be challenge to balance decision making.

Note that the Coach role is a little less formal, they may hold continuous improvement and capability (I’m talking about people capability and not product capability here) improvement backlog items, but it is better practice for capability and continuous improvement backlog items to be collectively owned long term by the Leadership Cell itself. In the early days of a transformation it may be useful for someone to be the voice of improvement and hence you could say that rather than “Coach” have the area as “Continuous improvement”, but I believe that continuous improvement should be embedded throughout the other areas, like Customer Experience and Technology and thus wouldn’t separate it out. The argument is then about continuous improvement that impacts across these functions, which might, over time, be enough of an excuse to change the name of the area but I would rather have clarity around the originating tension – ie where the pain is being felt that is driving the continuous improvement and use that area to drive the change. Additionally, the Coach role isn’t a role that I see existing longer term in the leadership cell, it is there to bootstrap the change, but shouldn’t be there indefinitely unlike the other areas.

The more complicated aspect of the Leadership Cell is how these areas interact. Certainly the Leadership Cell should be part of the Scrum of Scrums along with the Scrum Masters. One or more people in the Leadership Cell may also represent impediments as they get raised up above the Scrum of Scrums.

At a more strategic perspective the Leadership Cell starts to veer away from some of the scaling framework guidance. At a regular interval the Leadership Cell should have a prioritisation meeting to balance strategic direction and create a unified backlog for the teams. The frequency of this will depend on the frequency of pull from teams. I generally find that either every four or six weeks with a consolidated backlog of ten items is enough. This meeting is held like a multi Product Owner prioritisation meeting with each person bringing their top five items. As a collective they agree to which items should be pulled next. Like multi Product Owner prioritisation meetings, it does tend to take a few goes at this meeting before it becomes more fair and normalised.

The trade-off discussions can be quite heated, but it should be like a see-saw – sometimes it will be weighted to one perspective and then next time another area may be more heavily weighted. Normally, at scale the Product Owner tends to dominate the work. Using this approach more continuous improvement and operational stability tends to be added as a priority of focus. This is not to say that it will be realistic to have 50% Product Owner work and 50% other focus areas, but more like 80% Product Owner and 20% other focus areas (which would be an improvement from the 95% Product Owner weighting).

The Leadership Cell is also accountable for a lightweight process for agreeing to how to prioritise. I personally like the  DVF approach over WSJF, but each has its merits.

The DVF approach focuses on Desirability, Viability and Feasibility. It can be mathematically weighted and divided by time just like WSJF. The Leadership Cell balances the DVF where the Customer Experience area focuses on desirability, Product Ownership and Adoption focuses on Viability, and Delivery and Technology look at Feasibility. This is not to say that each Leadership Cell function cannot participate and consider all of the DVF elements as they assess and prioritise the work.

I like DVF because it isn’t just a prioritisation process but is importantly a set of considerations to test the work against. I’ll give a few examples of considerations for each.

Desirability consideration examples – Identify the alignment and contribution to the customer end to end journey; quantify the staff problem or opportunity.

Viability consideration examples – Business ability to absorb the change among other initiatives being rolled out and operating workload; identify and quantify the risk reduction and compliance obligations.

Feasibility consideration examples – Quantify business continuity and information risks; identify alignment and contribution to target architecture.

Along with attending the Scrum of Scrums and managing the pipeline for teams to pull from the Leadership Cell should also be part of a regular cross team retrospection. In essence, they act as if they are in a Sprint themselves but the likely timebox is going to be larger than that of the teams. To be clear, this timebox isn’t necessarily a Product or Program Increment, it should be decoupled from the release of a product (we will get into dependency management and PIs in a future blog).

So in summary, the sort of problems that having a Leadership Cell helps to solves includes:

• Having a mechanism to give equal authority of needs so that the team of teams backlog isn’t driven just by business need.
• No one person in the Leadership with higher power or authority over another, it is a peer structure where the coach is also considered a peer.
• Ownership point for work coming into the team of teams
• Considerations that should be applied to work as it comes into teams (DVF like elements).

Stay tuned for my next blog post on the Scaling Agile Tricks Series – Scaling number of teams.