Agility at scale is one of the crucial issues for large organizations. We interviewed four experts in order to put together an ebook, allowing to understand the contributions of agility at scale and SAFe. The following article is an excerpt from this ebook and allows us to understand how scaled agile practices be implemented with distributed teams.

Scaled Agile ebook

jean-claude delagrange coach agile
Jean-Claude DELAGRANGE, agile coach

Establish roles to encourage synchronization

While avoiding repeating what existing frameworks specify (SAFe goes the furthest in this area), Id’ say that it’s absolutely necessary to put in place roles focused on synchronization, whatever from or name it takes, and on each of the levels (product, customer approach, teams, architecture, go-live, etc.). In fact, the overall vision depends on this.

But implementation, which is based on execution-related tasks (organization of events, monitoring of consolated workflows, consolidation of backlogs, etc.), will also require operational resources, including secretarial/support roles, PMOs, etc., and this definitely shouldn’t be overlooked.

My experience of two platforms was as follows:

  • In the first, trust was placed in a secretarial pool that was treated as a full team, with its own backlog, producing value for all other teams, and gaining control of room bookings, meetings, support software, equipment for reviews, minuting meetings, ordering trays of food and drinks: in this case, every PI Planning session was virtually a party;
  • In the other, lots of money was spent on hiring PMOs who didn’t want to lower themselves to subordinate tasks and delegated them to the secretarial teams, resulting in postponements, absences, time wasted getting projectors to work, flip charts going missing, CRs coming in late, and so on; the first stages were tough.
Laurence Hanot coach agile
Laurence HANOT, agile coach at Zenika

Adapt to the transformation with existing roles

The larger the scale, the more you’ll need to synchronize, apply candences, coordinate, align people and practices, and delineate requirements at multiple levels and for a large number of people.

Whatever the approach undertaken or the underlying framework, it’ll be necessary to “scale” the rles: with Super Scrum Masters or RTEs / STEs, Super Product Owners or Product Managers / Solution Managers, multilevel architects with different perspectives and backgrounds, and so forth.

Apart from the specific roles of Business and Epic Owners in SAFe, I’d say that every context will be different and that new requirements will emerge during the scaling process that will need to be supported by existing roles (agile or not), and that this is part of adapting agile to each organization’s situation.

I’ve often seen people—managers in particular—lose their way or feel reticent about an agile transformation because they don’t fall into any of the roles described by the method. It’s a good idea to take account of their apprehensions, work with them to take stock of their current responsibilities / activities, compare those with agile roles, and see what they can move toward, if they want to, or whether they can “invent” their own role in this new way of working.

Read on