two tips for a hassle free agile transition.

DISs - and companies - are being forced to become more adaptable and flexible, but also more responsive in an ever-changing market environment. Agile methods offer a possible response. However, applying an Agile SCRUM method in a small team is totally different from doing it in a company with over 50 employees. This requires other models such as SAFe.

This article will discuss agile transformations i.e. going from using a SCRUM model involving several teams to using a SAFe model.

After experiencing three Programme Increments (PIs) and one Agile transformation, I would like to share two user tips, which will facilitate the implementation of SAFe in an organisation. These tips rely on two Agile Manifesto values:

• individuals and interactions over processes and tools;
• responding to change over following a plan.

These tips will help you avoid frustrating situations including the ‘switching off’ and ‘non-involvement’ of the SCRUM TEAM (Product Owner, ScrumMaster, Dev Team, etc.).

What is safe ?

SAFe (Scaled Agile Framework) is a framework created in 2011 to help companies implement ‘agility at scale’. The main problem of this ‘at scale’ change is how to get different teams on the same page in terms of different techniques, processes and contexts. This is possible thanks to the addition of a lean-agile framework.

This allows several teams to work together within the same structure. The particularity of SAFe is that it has an impact on all levels of a company i.e. from Top Management to Middle Management to the Technical Team.

In SAFe, the Top Management level can be linked to the “Portfolio” level, the Programme level to the Middle Management level while the Team level represents the operational level of the company. The Large Solution level is just an extension of the Programme level.

The diagram below shows SAFe basics. It is available on the official website and you can click on each section to understand its role.

Generally, the context of an agile transformation leads to focusing on the transformation and the model to be implemented (the technique) whereas the focus should be on values, often forgotten due to the changes. Before being a framework, SAFe is “Agile”. And if it’s Agile then it involves the Agile Manifesto.

The Agile Manifesto is built on four pillars:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation;
• responding to change over following a plan.

Here, we will focus on the two pillars, which were often a source of problems during the transformations I was involved in.

Individuals and interactions

When moving from a SCRUM to a SAFe model, individuals and their interactions must be taken into account. We must be aware of the type of interactions that existed before the transformation, we need to understand that the transformation will impact existing roles and that it will be necessary to adapt by adopting active listening techniques.

• Before SAFe, a full SCRUM team:

the Scrum Team comprises three roles: Dev Team, ScrumMaster and Product Owner (PO).

In addition to defining the acceptance criteria and building the Product Backlog, one of the Product Owner's main responsibilities is to understand the needs and priorities of the Stakeholders.

The Product Owner, whose main function is to write User Stories, Features and Epics, represents the Stakeholders. Among the latter, we find the Programme Manager, Partner, Business Owner, Sponsor, users and others.

Here is a diagram that summarises the PO’s relations:

• introduction of the change with SAFe

With SAFe, new roles appear e.g. Product Manager, Release Train Engineer, etc. Their roles impact those of some members of the ScrumTeam and in particular the role of the Product Owner.

The RTE (Release Train Engineer) is the Super ScrumMaster at the Train level (visible on the diagram previously shown and representing SAFe).

The Product Owner will be in charge of writing User Stories; he/she will no longer be in charge of Features.

The Product Manager will now be in charge of Features and will work closely with the Product Owner. He/she is more involved at the Programme level, as shown in the diagram below.

Their relations (PM-PO-Team) are shown on this graph:

The first frustration to watch out for concerns the Product Owner (PO) due to his/her change of role caused by the arrival of the Product Manager (PM). Minimising his/her frustrations can have a positive impact on your teams’ productivity.

I observed these types of frustrations during my first PI planning.

The Product Owners were fed up as they were no longer in charge of the Features. They were no longer completely in touch with the businesses either, which they perceived as a decrease in their scope. We observed a lack of involvement during meetings and even a certain amount of animosity toward the Product Managers. This resulted in a decrease in productivity at the end of the PI and an incomplete Feature due to the lack of understanding between the two roles.

Active listening by the RTE (Release Train Engineer) is also necessary to correct this problem. It is advisable to arrange a “PO/PM roles and responsibilities” workshop so that everyone knows what to expect from others. This eliminates any ambiguities and makes for healthier relations.

Using this type of workshop prior to starting the first Programme Increment prepares the Product Owners for this change, as well as encouraging exchanges between the Product Owner-Product Manager about what they can expect from each other.

Responding to change over following a plan.

In addition to taking into account the interactions, all models must reflect the context.

With SAFe, new ceremonies are added at the Programme level in addition to the usual ceremonies (Sprint Schedule, Review, Retrospective, Refinement).

The events at the Team Events level are identical to the SCRUM ceremonies, the only difference is the name.

Each of these events has a specific objective and a clear presentation of the details, which can be found here. At the Programme level, we have the System Demo, which takes place after each Sprint provided that the Feature is finished. During this event, the demonstration of the functionality deployed in the Staging environment is carried out.

The Product Owners carry out the demonstration of the Done Feature for the Product Managers/Product Owner, the System Team, the Business Owners, the executive sponsors, the customers, the RTE and the System Architect/Engineer. And this is the cause of the frustration.

In a Sprint Review, the Dev Team gives a demonstration of the Feature to the Product Owner and the Stakeholders. The feedback is shared directly with the designers and it is this team which will receive the kudos.

With the System Demo, this ceremony (Review) is modified and the Stakeholders are not involved. It is an exchange between the Dev Team and the PO only. The Stakeholders meet the PO at the System Demo during which comments about the Feature are shared. In a SAFe environment, the PO acts as the intermediary between the Stakeholders and the Dev Team. The technical team no longer receives criticism directly even though it is responsible for the design of the Feature.

In my previous experience, this really frustrated the Dev Teams. They had done all the hard work yet it was the Product Owners who received all the praise. In our case, the absence of change and adaptation only increased the frustration of the Dev Team, which was already dissatisfied and fed up. Hence, the importance of adapting the action plan to the organisational context when transitioning from SCRUM to SAFe.

I recommend inviting at least one Dev Team member to this ceremony. A Lead tech would be an appropriate choice.

To sum up :

All organisational changes lead to frustrations. However, these can be mitigated by managing the problem upstream and applying certain levers.

In the case of several teams transitioning from SCRUM to a SAFe train, it is essential to take into account the two values from the Agile Manifesto, and to activate them by organising a "Roles and Responsibilities" workshop prior to the first PI Planning and by inviting the Lead Techs to the System Demo. These two tips will mitigate any frustrations of the Product Owner but also the Dev team.