NOTES FROM THE GEMBA – The author visits a comparison website that is gradually integrating agile and lean thinking in its processes, identifying new and exciting improvement opportunities.

Words: Catherine Chabiron, lean coach and member of Institut Lean France

I step into the large open-space office buzzing with activity. Outside, a fantastic terrace overlooks the roofs of Paris. I am visiting LesFurets.com, a company that has found a way to hack the not-very-exciting job of finding an insurance coverage.

Comparison websites have become very popular in recent years, finding the best travel deals, hotel rates and flights for us. LesFurets.com compares and selects the best insurance policy for your car, your bike or your house (they have now started to cover financing, healthcare and Internet access).

I am excited to learn more about this brave new world, far away from ties and three-piece suits, during my meeting with Dimitri Baeli, the company’s Chief Technical Officer. Dimitri is a well-known agilist and he co-organizes Lean Kanban meetings in France through FlowCon, but he is also passionate about lean thinking. In fact, in his daily operations at LesFurets.com, Dimitri has managed to bridge the gap between Agile and lean.

Before I tell you about my gemba walk with Dimitri, a word about the name of the company. In French “furet” means “ferret”, small and notoriously agile creatures that can deftly and swiftly move around in any kind of environment. They were often used as hunting assistants, and they were so skillful that the term “ferret out” was coined to refer to the discovery of information through a relentless search. It’s a meaningful name for the company, whose TV commercials also use talking ferrets.

LesFurets.com has a very clear mission statement: to be the marketplace to compare and buy services. The added value for the end user is to detail her insurance needs once and for all – instead of having to repeat her story to different insurance companies – and get a price comparison she can act upon. For the business partner, the added value is to acquire massive volumes of potential, pre-selected buyers.

Dimitri and I start discussing who the company’s customer is: is it the partner companies who pay LesFurets.com for each new contract signed through their website? If so, where does that leave the user of the website? Is the end user nothing but “material” undergoing a transformation process through LesFurets.com? And is the website like a production line, delivering a finished product to the selected insurance company – in the form of a ready-to-sign, converted buyer?

The concept is intriguing, but the risk here is to miss the main point: if LesFurets.com plan to be the marketplace for online services, it means that the targeted customers are the actual users of the website. As in a supermarket, LesFurets.com attracts prospects in their shop, lines up products for them to choose from, and helps potential buyers to pick one. Unlike supermarkets, however, they don’t collect the money but channel out the potential buyers to the actual producer, for a fee. But this doesn’t mean that the actual customer is the payer. In lean management, we see users as the prime customers. The insurance companies and other utility providers are business partners, not customers.

What is crystal clear in Dimitri’s mind is the fact that LesFurets.com has to understand, at each step of the transformation process, what “right first time” and “good quality” mean for the user.

As LesFurets.com grew, silos of expertise started to emerge. This gradually led the developers away from the customers. User queries and complaints are mostly managed by Marketing and only trickle down to developers when a user takes the time to explain a missing vehicle reference or describe a bug. Therefore, taking turns at manning the chat box is key to understand what is bothering customers. By assisting customers and answering their questions, developers can see what’s not working in the way the website is used and fix it.

One such complaint, for example, was the site’s response time once users had completed the online form with their specifics: instead of a strict sequential approach – “first answer all questions, then we will connect to the partners” – the mapping to the various Web partners is now activated for the price comparison as soon as the key data is punched in. This leaves the user to complete the form with other data that is not necessary for price processing. By the time the user has completed the form the processed prices are available, and the response time is no longer perceived as being too long.

HOW DOES LEARNING HAPPEN?

As mentioned in the chart above, the availability of the website is 99.99% (a key element to attract and retain users). One to three production releases are done each day, through a DEVOPS process (automated building and unit testing of new features implemented by developers, automated integration testing and deployment). When they are solidly engineered and their use mastered, digital tools are magical: they can produce one-piece flow without worrying about SMED. Monitoring is also a key aspect of the job, albeit more traditional in IT, with a 24/7 check of the site availability and response time, but also of the databases and the IT architecture itself.

“I see our daily DEVOPS releases as a sort of truck preparation area,” Dimitri says, “They are an opportunity to check that everything we bundled for that release is OK to go.” LesFurets.com, driven by Dimitri, moved from one release a month to one per week, and now to at least one per day. This clearly leveled up the work for the production teams, reduced the lead-time to add value to the website, and taught teams to think in terms of small autonomous batches instead of large fit-for-all releases. It was a complete change of paradigm: everybody agreed that bugs should be corrected right away, but new functionalities were seen as “can wait”. Dimitri managed to get all the teams on board with the daily releases by demonstrating that added value not yet released is a waste and that it comes at a cost.

What interests me most, in this lean and agile discussion, is the user-friendliness and effectiveness of the website itself. How do you permanently improve the offer in such a fast-changing world? And what do you need to learn in order to get there?

I start a long conversation with Dimitri on this, right in front of the board showing the improvement and new features being developed for the website. “We were initially using Scrum and moving our development cards from one column to another (request -> analysis -> development -> release). But it was a pushed flow, and most of the discussions in front of the board ended up focusing on the effort or cost of the development.” Indeed, each card details what development is expected and what effort it will require (categorized from XS to XL, like in clothing sizes). The problem, as Dimitri sees it now, is that their scrum approach was made for large batches (sprints) grouping together major features as well as tiny enhancements, with the light and easy pieces of work waiting in line and the large and complex ones being chased to meet the sprint deadline.

“Lean and pulled flows had us thinking hard about this, and we ended up changing our approach,” Dimitri tells me. He and his team started to employ Kanban (well, what Agile refers to as Kanban):  starting from Marketing and Website management, ideas for improvements were cropping up but they were developed as mini-projects (in traditional IT, projects deliver a large batch of features bundled in a release), whereas now they are divided into autonomous batches (reduce batch size) with the expected value for the user added to the development card (again, rated from XS to XL).

“Actually, we learned from experience that the smaller the batch size, the faster we can get the improvement online. But we were still more Agile than lean, because we deemed our job finished as soon as it was correctly released. So, we added a column – Live Analysis – to check whether the change was having the expected effect,” Dimitri explains.

Discussions can now focus on value and priorities (an XS effort that delivers XL value should come first) and the Live Analysis helps developers to check the effectiveness of an idea or the efficiency and quality of the code.

However, looking at the board together, Dimitri and I can still spot some missing key lean elements:

• Kanban cards already analysed but not yet developed were piling up in the Analysis column, way past the immediate development capacity (a clear sign of a pushed flow).

• It is not possible at first glance to spot what is late or what is not. The cards bore no indications of dates or targets. We would expect to see the progress against takt time (or at least, in Agile mode, along a burndown chart).

• There is a reason for moving paper cards on a white board in the 21st century, instead of tracking tasks in an IT system (which they do anyway on JIRA – a task assignment tool): to open a space for collaborative thinking and kaizen. (What do we have to learn to overcome this issue?) With the aforementioned elements not visible, there is a risk that developers will fail to see the importance of the board versus JIRA and will stick to their online collaborative tools, where they can easily move activity cards from step to step until they are completed.

• Agile is too often seen as a ritualized process to build fluidly and efficiently, but what has been lost over time is the lean regular practice of step-by-step problem solving and kaizen, in order to develop collaboration but also technical skills. How do you retain the knowledge you have developed through kaizen? How do you share it?

TAKT TIME, FLEXIBILITY AND JIDOKA

We decide to move on to another key activity for the credibility of the website – the integration and follow-up of new partners.

Here, again, Kanban cards are used to follow up on tasks and move along the sequential process steps such as specifications, formulas and exceptions, price mapping, and so on. But Dimitri has kept two shots of the same board over months and it is interesting to see how it has evolved. The first photo shows a line for each developer, pushing tasks from step to step: this sort of visual management focused on resources (workload, task assignment) and process. Very much of a pushed make-to-order kind of scenario.

Over time, four major (lean) changes were made to the board:

1. As in a Heijunka Board in a plant, the rows now focus on products to deliver rather than resources, and expected delivery time is shown at each step. Target times weren’t present in the initial version of the board.
2. The notion of right-first-time is introduced, particularly on the quality of the data collected upstream with the partner (left hand side).
3. A delivery of one finished product per week is computed on the right-hand side. Collaboration is the only way to ensure this takt time is followed.
4. Any problem hindering compliance with takt time is highlighted and commented upon.

As I observe the two versions of the board, I can see the main differences in the approach. First, a focus on the regularity of the effort (level) and on sticking to the customer pace (takt time), and not on internal processes and the use of resources. This way, if a finished product can’t be delivered this week and can’t therefore be removed from the board to trigger a “replenishment” (a new partner to be integrated), it remains visible to everyone. It shows the problem must be solved.

Secondly, a Heijunka board also displays the ultimate goal of lean: flexibility of the mix of products (tasks) to deliver, at all times, since a bit of everything is produced at any given time. For LesFurets.com, this requires the agility to move from one partner to another, from one step to another, if one is stuck with missing data or an action from the partner is pending.

While discussing this, Dimitri and I can see further streams of improvement: do we have the right size of batches (deliverables)? Dimitri confirms he has identified 50 different actions a developer needs to master to correctly map a new partner. And are we sure we are producing a bit of everything everyday? And how do we track production time versus user expectations and competitors’ progress? Dimitri has some figures in mind: “Today, it takes six months to integrate an insurance partner. In those six months, development really takes one month. And the “touch time” within this month is a mere 10 working days.” Does this mean development time is not really an issue compared to the lengthy exchanges on contractual terms or getting the right input data? Maybe, but what if 10 days’ worth of work could be turned into a right-first-time one-day effort? Wouldn’t this attract more would-be partners and enlarge the offer for users, making the website more attractive?

Further questions are raised: what does “do it right” mean for each of those tasks? What is the key skill required here as we map partner data fields with those of the LesFurets.com website? How do we learn from mistakes in delivery? How do we share what we learn? I can see a few kaizen attempts to tackle this, but they have only just started.

We finally move on to see the team monitoring existing partners. A new question is raised here, as we look at the display tracking the production of each partner’s webservices: if a partner’s webservice processing experiences problems, do we pull the andon cord? If one or more key partners for the price comparison are unavailable, do we stop the line and/or alert the user? What does Jidoka look like in this environment?

As the end of my gemba walk with Dimitri approaches, we quickly sketch all the lean questions raised in this agile environment around a representation of the Toyota Production System.

There are still many open questions here, while some have been addressed head-on – like introducing customer takt time and small batches. LesFurets.com is growing fast (two-digit growth over the last five years) and expanding to new markets, and it is clear to me that this couldn’t have been achieved without facing some ugly truths and changing the company’s mindset on how things work. But lean clearly offers some yet-to-be-discovered opportunities for improvement.

_{THE AUTHOR}