A FRUITFUL SWITCH TO CUSTOMER SATISFACTION IN 2012
Fabrice Bernhard, one of the two co-founders of the group, is sitting in front of me, reflecting on how Theodo’s strong focus on quality really came about. “Back in 2012, we had our first brainwave: we needed to focus far more on customer satisfaction so that customers would come back and buy more,” he says. Inspired by Toyota’s Once a customer, always a customer approach, weekly checks to probe how the customer felt about Theodo’s delivery were designed. The project teams now send out weekly reports to their customers as soon as the deal is locked and ask them about their satisfaction with the speed of delivery and the team’s support.
This turned out to be a real game-changer. This type of “customer andon” forces the developer to intently listen to the customer at least once a week and stick to what she actually wants. It may not be a comfortable confrontation, but it is certainly a great opportunity to learn. The result of this switch to customer satisfaction was impressive: by 2016, Theodo had grown their turnover tenfold thanks, at least in part, to returning customers.
THE POOR COUSIN OF DELIVERY?
Unfortunately, being supportive and delivering fast is not enough to fully satisfy a customer. Today I am also meeting Rémy Luciani, who is known within Theodo as Mr Kaizen. Rémy explains how the stress on delivery may have occasionally overshadowed the need for built-in quality: “In our line of work, we have a constant pressure on delivery. Our incentives, both inside the company and in our relationship with customers, tend to be based on lead-times. This is probably because we can easily measure output through the delivery of scheduled tasks, while assessing quality is not as straightforward.”
The two founders of Theodo – Fabrice Bernhard and Benoît Charles-Lavauzelle – went to Japan in 2017 and 2019 to see the Toyota Production System in action at Toyota suppliers. “It came as a blow,” Fabrice recounts. “We learned we had to be at the gemba far more than we were, to develop good thinking and learning in design, if we wanted to seriously reduce rework and delays.”
The story of the visit to Mifune, a Toyota Tier-2 supplier, is a favorite within Theodo’s management team. During the tour of the supplier, Fabrice and Benoît asked how often the President of Mifune was on the gemba, expecting an answer in the range of a few hours per week or per month. They were told he was there on average 10 minutes each hour! Not only did this reveal the reality of top management presence on the shop floor, but it also shed a light on the powerful choice of carrying out gemba walks in small batches to observe different operations or activities at different times of the day. They also discovered that the top-quality levels expected by the customer were not measured just ahead of the delivery, but that it was a continuous effort at all production stages.
This gave them food for thought. When you develop an application, you can choose to test at the end (the equivalent of a final inspection on an assembly line) or as you code (self-checks at each step of “assembly”). If you go for the former – the so-called User Acceptance Test – you usually face a lengthy assessment that often results in a long list of last-minute changes and rework items. This activity includes a wide array of stress or scalability tests (can the product withstand simultaneous connections from many users?), non-regression tests (is a change in one function creating a defect in another function?), and integration tests (do data easily flow end-to-end, with the expected transformations?).
RE-FOCUS ON QUALITY
In 2019, Fabrice himself started to walk the gemba to check the code and learn from the issues the team encountered. A quality framework, called the 3S, was soon set up for the Theodo group:
- Stability – no bugs
- Speed – fast response time
- Security – no vulnerability
There was a large debate on the response time. People wondered whether it should be the response time as seen by an individual user or the response time when a large group of users was connected. The focus on the customer typical of Lean Thinking prevailed in the end: what was checked there was not the scalability of the app, but the response time perceived by an individual user, whether he connected alone or at the same time as a large group of people.
When checking on the gemba, Fabrice has three clear goals: check the reality of the “shop floor” versus what he has in mind as a top manager and co-founder; showcase the achievements of the Techs he visits; and facilitate the development of a quality strategy among Team Leaders.
The two gemba walks per week he has been taking over the past two years have revealed interesting things about the teams. “We have brilliant recruits creating smart things,” he tells me, “but while they can think out of the box and master complex technologies, kaizen is an opportunity to raise interesting questions on the job and the way to address a customer request.” Visiting teams twice a week helps to understand who does what and who is particularly proficient on any given subject, and Fabrice sometimes re-directs the Techs he visited to teams or individuals who could help and save them time.
The code is also a great source of potential improvements. “I sometimes see bugs or potential bugs. And when I ask to see the last segment of code developers have written, I am surprised to see it is often the rework of a previous faulty code,” he continues. Code libraries are great ideas, but copying-and-pasting a code segment without a clear understanding of the intent behind the code can lead to misuse. Fabrice’s intent is to encourage people to think before using a standard code.
Funnily enough, this reminds me of the so-called “best practices” large corporations love to promote: copy and paste something that has been cooked up by a team to address a specific issue elsewhere may not be a great idea. On the other end, stating the initial problem the team was addressing can be a great way to learn from others and develop your own answer. In other words, do not share the solution but the initial question to trigger people to think lean.
The need to work on code quality was therefore confirmed and, in September 2020, Rémy was asked to help teams on kaizen.
PROBLEM-BASED LEARNING
Fabrice confirms that Theodo had their first kaizen attempt focused on code and development back in 2016. Although interesting, he says that those were framed as lengthy processes and that addressing such and complex issues could easily put people off.
Rémy was therefore assigned to help with these kaizens last year. He has been working for Theodo for 10 years and is fully convinced of the need to use a scientific approach at work. He saw too often how teams would shortcut an issue to avoid a deep investigation on why it occurred in the first place. Rémy says that some of the time that is spent debating the comparative merits of available market tools in the digital should be diverted to developing a fundamental understanding of how things actually work.
Fully aware of the fact he was facing a long, dicey journey to try and convince the teams to find time for regular kaizen, Rémy decided to make it simple for them. “I am pushing teams to select focused, team topics. Trying to address vast, transversal projects, as we once did, is a sure way to drown them in corrective actions, most of which they have no leverage on,” Rémy explains.
He also knows that kaizen in the past may have been window-dressed for the purpose of a peer review. If you remember what Marie, the Theodo Group HR, said in the third article of the series, a kaizen maturity model was once a mandatory step in career development. They have since then moved away from it.
So Rémy takes project teams one by one and helps them surface a performance issue that can be addressed in a maximum of one or two days. “We need to build trust in the approach, and confidence will increase as soon as results and/or learnings are quickly obtained,” he tells me.
Rémy fully buys into problem-based learning on code: “Fostering collaboration on a quality issue is a great way to develop your skills both on the code and on your capability to listen actively while influencing others.”
Once the performance issue has been defined, and if the team is in reasonably stable conditions (the basis of TPS), Rémy proposes to schedule a one-day kaizen workshop. With a new difficulty: with the prevailing focus on delivery and the fact that customer billing is based on the time spent on the app in the digital world, rather than on the outcome, someone needs to tell the customer that a full day dedicated to quality improvement will be charged. While some customers may think it’s a great idea, others will no doubt frown and will need some convincing. Mind you, this is not because they don’t care about quality, but because they believed this was an intrinsic part of the job to begin with!
With a slow start at the end of 2020, Rémy has now reached a cruising speed of one to two kaizen workshops per week.
KAIZEN IN SIX STEPS
Rémy uses a classical 6-step kaizen approach.
First, you agree on the performance that needs improving. Then, you spend time observing how the work is done today and take real-time measurements as you do, repeating them in the event of high variability. Rémy shows me an example where they timed the full release to production, all the way down to the Apple Store. It turned out the team was not familiar with the tools, was losing time setting them up or waiting for a notification that would not come. They viewed the whole process as complex and unfamiliar and were therefore tempted to batch big lumps of build before attempting to release them to the Apple Store. This increased the time-to-market of new features.
This current method observation phase is crucial: you could be quickly tempted to jump to a solution crossing your mind without investigating the matter deeply enough and Rémy’s role is essential to avoiding this. “My day is a success if I see them open their eyes and beam at their learnings. They often tell me that it’s great to be able to take the time to observe, analyze, and think,” he says.
The third step is to discuss new ideas. In this example, the team found 16 ideas to alleviate the load and reduce the risk of mistakes. They selected one at this stage – automate the upload of the builds.
This “new idea” step is an opportunity to individually experiment with a few of those ideas so as to be in a position to compare and select the best one. “We generally observe and analyze in the morning and play around with the new ideas in the afternoon. The point is really to try out something immediately because it may unveil unexpected hurdles. In addition, each team member will learn while practicing, alone or as part of a pair,” Rémy says. Learning doesn’t happen collectively. You learn as you investigate an idea and experiment a possible solution, and you learn alone. The time allocated by Rémy to individual learning is crucial.
Rémy then insists: “It’s a very hands-on workshop. Sometimes, we start on an issue and the kaizen is closed by midday. We can then start a new one in the afternoon. In other cases, the analysis takes time, but the learnings are useful even when results are not achieved by the end of the day, both on how people view their job and on the kaizen approach itself.” Rémy’s objective for the day is to reach at least step 4 – define the implementation plan for the selected idea.
Step 5 – implementing the plan – and Step 6 – evaluating the new method – are left to the teams.
Rémy shows me another kaizen on Data Transfer Objects. He tells me: “Our developers actually spend more time reading code than writing it. They maintain applications or start from a customer legacy app to create a new one. Poor quality code soon becomes a mental burden for them. And DTOs are one of our targets as they are frequently used.”
He shows me the case of a DTO with ID or email and access rights, typically designed to deal with access rights to a page or an app. But looking more closely at it, there are actually two different use cases for this DTO: an account creation or an access permission once the account is created. And while the DTO they are looking at is relevant in the first instance, it isn’t in the second. Duplication without much thought given to the use case.
Other issues on this DTOs include different data types within the same app (a chain of characters in one instance, a permission name in another).
Indeed, the number of activities that can be a topic for kaizen is staggering. Fabrice can list quite a number of them: “Techs take the lead on choosing their tools and the flow. And those choices are not always the best ones. Some kaizens are consequently dedicated to the lead-time or the touch time in delivery, but there are many possible improvements on the software architecture, too, on duplication issues, interfaces, databases. Or on tests. We definitely lack standards there”.
He then adds with a smile: “Possibly also anything that prevents Techs from working smoothly, in the flow, with a sense that everything falls into place when needed.” Rémy underlines: “I can think of an app whose development environment takes eight minutes to get started in the morning – pretty painful.”
CELEBRATE LEARNINGS
Rémy believes that, at this stage, only 5 to 10% of the teams that attended a kaizen workshop with him have pursued kaizen efforts on their own. The road will be long and anyone who has tried to promote the famous JOB = WORK + KAIZEN mantra has at one point or another had to face this disheartening reality. But the stakes are high and Rémy is determined.
One way to encourage kaizen is to talk profusely about the lessons learned. Fabrice steps in: “We debrief on kaizen learnings once a month in the UK. And in France, both the Theodo TV and the Asakai meetings are used to showcase the findings and thank the Techs who got involved.”
The purpose of these debriefs is to value the time people spend learning. “Only the top geeks do this continuous learning spontaneously,” Fabrice says. “We want to show everyone in the group how much we value the effort of thinking before acting and how enjoyable this can be. Good thinking for good products, as Toyota teaches us. I have often been very impressed by the investigation and the learnings resulting from a problem, and this is the sort of examples we need to continue to disseminate around the company.”
