This is how we accelerate with Quality Engineering

On July 14th, we did a webinar called This is how we accelerate with Quality Engineering.
Guest speaker Antoine Craske shared how they improved and accelerated software delivery at the international retailer La Redoute, where he is the Director of Architecture & Technology.
The webinar shows a real-world example of how Antoine transformed La Redoute’s software pipeline through Quality Engineering, using the Accelerate metrics for benchmarking and measuring results. Antoine also shared with us the main lessons you learned along the way and takeaways you can apply in your context.
“Accelerate is becoming a standard to drive DevOps implementation on the four key metrics. We used the model to improve our pipelines over various increments, aligned with the DevOps principles. We act on various domains from methodology, organization, and architecture to remove limiting factors along our software pipeline. Multiple teams are now delivering multiple times per day with stability, a game-changer compared to our previous performance across teams.”
I think that your “ice cream cone” approach is quite non-standard. (00:54:32)
La Redoute applies the same type of best practices of software to testing. One of those best practices is having test design in place. Their test automation tool has a modular approach to test automation. All the user journeys and user paths are very modular, and all objects are in the data library. That allows La Redoute to have a reduced maintenance effort, with 3 people working on the implementation and maintenance of tests.
In a nutshell, the best approach is to use the best practices in maintenance, test modularity, and test design. There is also shared ownership between business, IT teams, and QA teams around the referential of tests.
Plus, La Redoute also does daily delivery, which works like a daily test of their tests. So if tests are unstable and are not helping, they quickly need to be fixed or removed. It’s also a key element to have this feedback loop around the 8 hours of their test suite.

7000 tests run in 50 elapsed minutes? (00:42:37)
Of these 7000 tests, around 1500 are for the mobile application, and the rest are for the website. They are not only API tests but user experience tests simulating a user on the UI.
Plus, they are not necessarily isolated because they can simulate user scenarios that can happen right now on the website of La Redoute. These tests may be performing API calls because they’re clicking on buttons, but it’s user experience tests, not that much API, and they’re running in parallel to simulate the business behavior.
Why so few unit tests and so much upper-level approaches? (00:47:14)
In the back-end, La Redoute has more unit and integration tests, a standard approach for back-end services. However, on the digital part, they had much more user experience tests.
At the time, there was a gap between business and IT teams, where they were not talking with each other about the user experience, customer journey, and user path.
If they simply said, “let’s do a lot of unit tests to try to accelerate,” Antoine believes they would always have issues translating the unit tests into business and wouldn’t have much collaboration and shared vision about the business improvement and iteration.
As such, if La Redoute had invested more in unit tests rather than upper-level approaches, they would have been much slower to transform the company and would have probably failed to do daily delivery. It was a trade-off then, and today they are balancing the pyramid.
Do you use trunk-based development? (00:44:14)
In the digital platform – the web and mobile application – La Redoute uses trunk-based development because they’re still on SVN. However, they started to move the front-end to Git.
The back office is also on Git, where they’re using GitHub flow, so it’s, in fact, the concept of trunk-based development. They only have one main line, but they have a branch for peer review and validation before going to the main one, which goes directly to production. So, the short answer is yes, but with a specific model for Git, which is GitHub flow.

If you were to go through the transformation journey again, what would you do differently based on what you know now? (00:45:16)
Invest much more in the transformation of people and their skills and mindset is the main one. A lot of times, limiting factors are not technology; it’s the adoption of people and the resistance to change.
As such, Antoine would invest much more into the transformation, pushing people and explaining to them the transformation. The people part needs to be balanced to drive better transformation.
Was there any resistance (from devs, management, etc.) to implement the changes needed? (00:49:44)
There was a lot of resistance to change. For example, La Redoute had developers that didn’t want to go up to production, operation people that didn’t want developers to go to production, and management people who didn’t want to adopt cloud technologies.
However, more than change itself, there was also a lot of resistance for people to become true managers and leaders rather than managing their silos. So they had to push many people into transversality and work beyond their comfort zone.
The discussion should be around transition management rather than change management because you have to manage the transition ecosystem. You need to manage a specific level of transition in maturity.


The quality culture transition guide, is that from Alan Page? (00:46:24)
The quality culture guide is from Alan Page. But what Antoine is building in the Quality Engineering Framework it’s not only the culture guide from Alan Page; it’s a broader quality engineering guide.

How does engineering culture fit into the equation? (00:52:25)
For Antoine, culture is the result of addressing all the other parts of the MAMOS framework. This is because what La Redoute had to change in culture was around transversality, the perception people have of their work and their contribution, and how they should interact with each other and their contribution to the business.
Quality culture is about changing the individual perception of what is their role in the global organization and transversality. That way, people see where they contribute to the value chain, and you need to create a shared mindset. With that, you remove the local tribes and the local silos. The quality culture is about opening the global perception for people to make globally better decisions.
Thank you to everyone who joined live and those who watched the recording later on! Let’s keep the conversation going in our community.