The setting up of quality foundations supported by an iterative approach is a central subject through the exchanges of the community.
However, it is rarely supported by concrete cases.
This is why I decided to share a possible trajectory strongly inspired by my personal experience, in all humility.
The goal is for the practices exemplified to be relevant to you, pictured in context, without trying to give a watered-down picture of reality.
The light is oriented on the concept of the approach, most relevant facts were retained, while shortening in a few paragraphs years of implementation.
Temporality is therefore not represented by choice, and under no circumstances does it want to convey a message of ease, in this context or elsewhere.
This article covers the next steps of a possible approach :
- The need for an organization to “take a wall” to react
- Obtaining business and IT sponsorship in a period of opportunities
- Using a crisis as a leverage effect to change habits
- Implementing an iterative approach focused on the customer and the business
- Focus the overall organization around a transversal quality perspective
- Integrate testability “by design” upstream of the development cycles
- Give space to experiment while overseeing the customer experience
Join the QE Unit to access exclusive and regular content from the community.
La Redoute, a company with a history
La Redoute is a company at the heart of the French panorama, with 99% notoriety in France and more than 180 years of existence.
Everyone keeps the memory of the catalogs on the family living room table, leafed through time and time again, and full of surprises.
It is this longevity that also earned it the legacy of a historical, complex information system, more commonly characterized as a legacy.
Even though La Redoute has rebounded today, an in-depth transformation at all levels of the company was necessary.
In this article, we will focus our prism on the business, the IS, and the software quality.
Confrontation with the cold reality
We have identified the need for organizations to “hit the wall” in order to react.
For La Redoute, I think this pivotal period took place in 2014, with its exit from the PPR group, now Kering.
The company found itself alone faced with significant operational losses, in a complicated organizational and competitive context.
Despite an e-commerce site providing more than 50% of turnover, the mainframe, and its inherent slowness was still the heart of the business reactor.
The e-commerce platform is also a brake on development through quarterly release cycles, followed by complicated periods of deliveries and stabilization.
The teams are regularly tired and generally find it difficult to provide structural changes, major projects suffer considerable delays.
Looking back, this phase of confronting cold reality is a factor in the organization’s ability to adapt more quickly thereafter.
We can unfortunately draw a parallel with a smoker who does not stop using until he has survived a heart attack.
An accelerated and drastic transformation as the only option
A profound transformation was the only possibility to survive in an increasingly competitive and globalized context.
It was during this period that La Redoute began an in-depth transformation, combining an overhaul of the business model as well as leading digitization.
Rationalization and protection is the watchword in a context of survival where severe cuts are taking place at all levels (e.g. reduction of the workforce from 3000 to 1500).
IT is not spared, it must unify its 3 web platforms to meet the needs of acceleration and rationalization.
At the same time, the back office must completely move away from the historical Mainframe in a distributed architecture to provide more speed and flexibility.
It is in this context of strong constraints that opportunities have been created, in particular for quality, a vector of acceleration and stabilization of software deliveries.
Transformative leadership, the de-facto sponsor
As the approach started from afar, the first stage of the foundations was more than necessary.
Fruit of the difficult deliveries experienced by the different teams, moreover repeatedly, development alone could not solve the problems encountered.
Through a systematic analysis of the context, particularly from a system and organizational point of view, the lack of quality is salient.
Convergence to the new platform turned out to be an opportunity to start on a better basis, with strong sponsorship, from both business and IT.
The need for transformation is strong, people in formal leadership or informal influencing positions are driving the dynamic.
Here we find the prerequisite of sponsoring a quality approach, that when absent often turns out to be fatal.
The business and IT transversality in the shared context has, I think, been facilitated by the history and the sense of the urgency of the transformation.
“Deliver less, but every day”, a strong and necessary message
A team vision is driven to be able to deliver small changes every day, with confidence and stability.
This is a strong message in a previous context where the number of subjects pushed into a release was the performance index followed.
Moreover, this principle implies drastic changes in software development processes, in direct confrontation with the habits of the organization.
Take the example of version control branches – another topic to be debated – where developers often like to have their own “local” branch.
Personally, this word “local” activates an internal warning signal.
Linking to system-thinking, the dangers of local optimizations are not far away.
For example, it was necessary to switch to trunk-based development to support a daily delivery cycle of small synchronized changes.
Hence the need for sponsorship up to engineering to succeed in these transformations, a change in organizational habit being a real challenge.
A minimal, stable, fast, and customer-oriented test battery is implemented
The delivery cycles being faster and more controlled, ensuring their quality remains key.
This is where a minimal test campaign is set up.
The minimal roles are defined in order to secure this approach: Cross-functional project manager, quality manager, DevOps by putting the Product Owners, Developers, and QA at the heart of the process.
An initial test battery is defined, with the aim of validating the minimum number of non-regression core functionalities, from a customer point of view.
In the context of the company, we often refer to the customer journey in connection with personas to focus the tests carried out.
The first campaigns are difficult, the tests are hardly stabilized due to data sets and integration issues that must be resolved.
The business is starting to become impatient, we must defend the approach put in place to avoid getting back into the old habits.
After a few weeks, a delivery rhythm begins to set in, even if few changes are integrated incrementally.
Integrating “by design” testability upstream of development cycles
Succeeding in the first cycles is the first step, but how do you stay in the course?
From experience, control of the run is a prerequisite for an organization that wants to be more agile and accelerate.
The use of LEAN, problem solving and automation are often combined to achieve real results.
Once under control, it remains the balance between the evolutions and the maintainability of the existing one.
This is where the requirements needed to be translated into testing upstream of the developments.
Without speaking of BDD or TDD, the approach remained pragmatic by aligning the business use-cases with those of the functional tests.
The work of the QA teams during the sprint is then to prepare the automated tests while validating the use-cases manually, as and when daily deliveries are made.
It is a complicated exercise, full of constraints, which requires real prioritization, sharing between the teams, and modularity of the tests.
This subject is never finished, the focus must be on improving the maturity of the teams on their implementation and guaranteeing the stability and maintenance of the existing one.
A need for freedom and experimentation in the profession
In a desire to experiment more strongly with ideas on digital interactions, teams need more freedom of action.
This is when the features-flag are studied.
They represent real engineering challenges to be used correctly, from their design, maintenance, and until their removal.
These flag features alone are often useful for IT teams to manage progressive deployments but fall short for business.
This is where the complementarity of A/B Testing mechanisms comes into play to bring a transversal value to the organization.
Once tested, they make it possible to deliver even partial functionalities, while being able to gradually activate or even deactivate them.
This degree of latitude on the platform raises the question of the stability of the customer experience.
How to ensure that it is not impacted by all these continuous experiments?
The beginnings of observability
Functional tests focused on customer journeys are a pivotal part.
Technical supervision talking to us about processor, memory and network latency is tiring and far from the customer experience.
A focus on customer experience is necessary.
The regular execution of functional tests in production provides a first guarantee of the stability of customer journeys.
Directly integrated with supervision, both business and IT teams can have a comprehensive view of the experience on different devices, countries and environments.
Over time, we also realize that data only used in supervision could also be useful in reporting.
The implementation of dashboards makes it possible, for example, to monitor the stability of the login, basket addition and checkout processes.
Without realizing it, the team also follows common KPIs between business and IT, facilitating an extended and accelerated collaboration.
The wars of excel and loss justification are almost forgotten.
The establishment of foundations, a transversal, iterative and incremental approach
I think these three words sum up the establishment of a foundation for a quality approach.
Without transversality, sponsorship appears difficult, and local optimizations only alternate temporary resolutions and the appearance of new problems.
Cross-functionality is also found in the practices put in place, they range from business, QA, IT, development to operations.
You have to know how to compose and adapt, as in a jazz ensemble, to the context and issues of the moment, hence the value of an iterative process.
Iterations provide the ability to limit initial complexity and adapt efficient processes, or inefficient constraints, much faster.
This is why an incremental approach in a complex, uncertain ecosystem with strong human change is more than relevant.
Finally, let’s not forget that an iterative process does not have to mean that it is without a goal, nor a vision or a destination in mind.
Vision is a key difference for a team that arrives at its destination and the one that ends up returning to its starting port.