Our new life after SAFe®

Short version

This article presents what we implemented following our withdrawal from SAFe®. It describes 3 major changes: our process from A to Z, the objects handled and our prioritisation process.

Target public

Anyone wondering how to get organised in a changing environment and interested in SAFe® on any level.

Long version

In the article “Why we decided to no longer use SAFe®”, we described the problems SAFe® created for us, i.e. a time-to-market out of step with our needs, a saturation of teams and a tendency towards imitation. What we did not mention is that we had other sticking points which were not specifically related to SAFe®, such as the clarification of roles and responsibilities throughout the product development cycle. We began by reviewing our process first, which naturally led us to scrap SAFe®. Here are the key adjustments we made:

The basis: The process from A to Z

What is our vision? What is our strategy? Without revealing our strategic priorities, we find ourselves facing the standard issues of a product as a service: we want the most standard product possible to respond to the largest possible number of customers with a clear differentiator.

We thus began to build our process with this aim in mind.

Ideas come in to us from customers, prospects and from within the company. These ideas are above all inspirations of excessively variable sizes that must be filtered via our product strategy. We then move into a phase of problem validation and solution definition with regard to an aim (product discovery). Then comes the production phase, with a strong focus on the size of (small) batches in addition to the reduction of dependencies (product delivery). Lastly, we learn, which helps us to re-adjust our plans (product learning). This is a summary of our process from start to finish.

Objects: Highlight the contrast

For the second step to clarify roles and responsibilities, we worked on the objects to be handled, to help everyone understand more easily. We ended up with the definition of 4 objects and 4 co-responsibilities.

· Opportunity, or the link between strategy and execution — under the responsibility of the Chief Product Officer / VP Engineering. This covers incoming requests from prospects and customers, or in-house ideas. This is the object which serves as a benchmark for customer engagements.

· The medium-term aim of 3 months maximum for delivery which describes an expected impact (and not a functionality) — under the responsibility of the Heads Of Product / Engineering Directors. The major paradigm shift here is the focus on the expected impact from a business perspective, and not the deliverable. This object is the support for the product roadmap and includes the success criterion which we measure in product learning.

· The change in user behaviour or value piece — under the responsibility of the Product Managers / Engineering Managers. This is the most detailed object which adds value when activated in production. It is used for release notes.

· The change in product behaviour — under the responsibility of the Product Owners / Team Leaders. For agilists, we are talking about the User Stories which provide us with feedback prior to production.

We placed a strong emphasis on the objects and transition criteria to create a contrast. In the past, we had more objects, many of which were shared between several people. Our aim was to ensure that everyone knows where their responsibilities lie, while allowing freedom to decide who contributes to what.

Prioritisation : Moving on without losing direction

Our last task was to use the first two steps (process and objects) to reduce the time-to-market and avoid saturation. Goodbye PI planning and hello to the world of flow:

· We are shifting from prioritisation by scope to prioritisation by sorting. We are no longer doing 3-month batches with a fixed scope; we use a sorted list of subjects which we go through one by one as we unstack.

· We are increasing the prioritisation rate to enable arbitration more often, while forbidding to stop anything already in progress.

In practical terms, each job area prioritises its subjects every month with a 3-month time horizon (rolling). Any work in progress cannot be stopped, whereas the waiting list can be sorted at will. This allows us more flexibility in prioritisation.

The prerequisite to switching to this mode is to have broken down as many dependencies as possible, which is what we did by rethinking our product organisation. In this way, each business domain prioritises independently. At present, around 10% of the 3-month aims are shared between several areas. We have kept a central prioritisation meeting as a sort of sweeper to deal with all dependencies between business domains.

To avoid making short-term decisions, we added a quarterly meeting for long term discussion. This allows us to take stock of what we have done, what we are doing and determine if our vision/strategy duo needs adapting.

Reducing work in progress

When we brought in the new prioritisation process, we created a new dashboard to see all the “Ambition” objects within the product development cycle, and we took a look at our stock. We had more than 10 subjects open per team, which had not been visible before because the PI prioritisation was made of a finer mesh (the change in user behaviour) and the discovery steps were not very clear before.

Such a loaded system generated a lot of multi-tasking and it was difficult to move items forward. We thus decided to lower the level of work in progress with a focus on finishing what had been started, or to stop certain subjects which had been ongoing for too long. We did not have a formal mechanism to limit work in progress, but we halved the number of open subjects, a figure which remains relatively stable.

Our result

At present, four months after our changes, we have observed a reduction in work in progress and a slight rise in flow, which should reflect on the time-to-market. As we already had subjects in the pipeline, the visible effect of the change will take time. Is all this perfect? Not yet, and probably never. As we gain speed, we realise that the car is rattling. This comes as no surprise, and we are taking stock of the adjustments to be made before accelerating again.