NOTES FROM THE GEMBA — This French tech firm thrives through Lean Thinking, continuous learning, and customer-focused innovation, embodying Toyota-inspired resilience in software development.

Words: Catherine Chabiron

Lille, a large city in northern France, once thrived on the textile industry that powered its prosperity through the 19th and early 20th centuries. Today, two of its former factories have been transformed into the city’s tech hub, and the small company I’m visiting, No Parking, sits just a stone’s throw away. As the newspaper Les Echos put it in a 2017 article, “In Lille, Tech is growing on the ruins of Textiles.”

Welcoming me is manager Perrick Penet. The first thing I ask him is the reason behind the company’s name, as we join his small team of eight people. “No Parking,” he explains, “is information in motion, which never stagnates.” The company developed and created a time management tool, Opentime, 20 years ago. “We started out as an IT services company, and I developed Opentime for our own use. My accountant asked me to develop it for one of his client companies, and that’s how we started selling it. Today, more than 200 companies and associations use it.” The tool accounts for 85% of the No Parking’s turnover.

In a fast-paced world—and this question is even more relevant in the tech world—how do you survive when you're small and facing competition from big software publishers or even the in-house solutions that AI will undoubtedly enable in the near future? Admittedly, No Parking serves at least in part a niche market: law firms, architectural firms, accounting firms, design offices, tech start-ups, and associations, which are less likely to attract large publishers.

Still, competition is fierce, and No Parking's resilience is largely supported by the dual approach I observed on the gemba: Perrick, who closely studied the role of a Chief Engineer at Toyota, constantly works on new value or features that the team can bring to customers, while encouraging the development of knowledge within the team on a weekly basis.

VALUE FOR CUSTOMERS? ESSENTIAL TO SURVIVE

Perrick shows me the Opentime product, which is surprisingly simple and user-friendly. There is no sophisticated navigation or superfluous design; the idea is to go straight to the functionality and value for the customer. The No Parking team also uses Opentime for its own needs, which allows it to identify any shortcomings or malfunctions.

‍

Like any good software, it is updated several times a day, considering corrections or developments requested by users. Unwilling to send out Net Promoter Score questionnaires left, right and centre at the risk of annoying customers, Perrick asks the team to target only new users, once they have familiarized themselves with the product, and all users requesting developments, to understand what still needs to be worked on. For each targeted exchange, he shows me PDCAs that enable problems to be resolved to the customer's complete satisfaction.

The team also provides another service that is particularly appreciated by users: a blog detailing the latest developments, showing how to deal with a specific aspect of labor regulations, or recounting the experience of one of the customers. 

But optimizing what already exists is only part of the Chief Engineer’s role. Exploring new potential customers and business opportunities, analysing what competitors are doing, and listening to testimonials from lean companies in the region (Perrick leads the local lean community) inspire Perrick to imagine new features.

A new app, Fissa, heavily inspired by Opentime, was launched last year. It allows for time and attendance data to be collected using a time clock or a web/mobile interface incorporated into human resources management. They have also recently developed the Skillofi module, which will allow for the management of skills matrices.

FROM TASK MANAGEMENT TO KANBAN

Perrick also shows me the Kanbans module, which only he and his team are currently using. The idea here is to offer a task management feature (this type of software is widely used in tech) but with the addition of a Kanban approach, lead-time visibility and the possibility of levelling (Heijunka). All tasks to be completed are therefore broken down by Kanban, whether they involve pre-production testing, preventive maintenance, certificate renewals, or user requests. The predictable is scheduled (and levelled) in advance, while the unpredictable (user tickets or tickets from gemba kaizen) is inserted into the flow.

Each kanban is assigned a start date, and in theory, should be completed within eight hours. Perrick and the team have a maximum of four kanbans per person per day, which considers the waiting time between two actions on a kanban. These operating rules will therefore enable a scheduler to level out the workload across the entire team and over time (Heijunka). The tool provides views of the workload over time for everyone, as well as an overview of the team.

Of course, if the promise cannot be kept, an Andon is triggered. For Perrick, this is an opportunity to see how quickly countermeasures can be triggered (for example, freeing up time to absorb the delay by postponing less urgent tasks or providing assistance). It is a very visual way of balancing workload and capacity.

‍

WEEKLY GEMBA SESSIONS ON KAIZEN

Value for customers can only come from developing the individual and collective intelligence of the team. Perrick leads several gemba sessions each week to promote a deeper dive into unfamiliar or insufficiently mastered areas, be it code, SQL queries, design, SEO or marketing. The idea is to take a year to delve into a difficult technical subject and explore new fields of action with a leader for each subject, a review frequency of three weeks and successive iterations of PDCAs.

The first gemba I am doing focuses on marketing, together with Chloé. “We continue to develop and improve our product, but we have a real difficulty in being seen or found,” Perrick explains. Chloé has two parallel kaizen topics on this subject: on the one hand, developing partnerships to increase Opentime's visibility;on the other, optimizing the website's SEO so that an internet search can lead more easily to them, without having to pay for more visibility.

We are standing in front of the board managed by Chloé. The first interesting thing is the diagram showing what they are trying to “crack”: what partnership and with whom? With large clients who put them on their list of suppliers? Accounting or payroll software publishers with whom Opentime interfaces to transfer time data? Marketplaces? Trade shows or communicators? The diagram lists specific targets, some of which are already ticked off, revealing Chloé's progress in her exploration.

REPEATED ITERATIONS FOR BETTER LEARNING

What strikes me is the simplicity of this approach: with this clear vision of what she is looking for, Chloé opened one, then two, then several PDCA lines. Each line follows the typical structure of Problem - Cause - Countermeasure - Result - Learning - Status (open or closed).

‍

For example, if the problem is finding the right contact for a marketplace (cause: we don't know them), and the search countermeasure has yielded a result (the marketplace is open to partnership but requires extensive technical documentation), Perrick discusses the learning with Chloé (it turns out that the marketplace is even better known in the target market than they initially thought) and closes the line with a stamp. Then he and Chloé open another line on technical documentation (this is a problem because she knows nothing about it and will have to find help). After discussion, the countermeasure will require working with one of No Parking's Project Managers to provide technical information and even validate an interface. Chloé and Perrick agree not to have more than four PDCAs open at the same time.

But this is where it gets even more interesting. Chloe could have outsourced the task by creating a kanban in Opentime and waited for a Technical Project Manager from the team to deal with it—a well-known technique used by our brains, which seek to save energy and tend to dismiss the problem once someone else has been assigned to follow up on it.

LEARNING TOGETHER

At No Parking, inspired by pair programming and peer reviews, they prefer to work in pairs: the Technical Project Manager will contribute their technical knowledge, while Chloé will provide her knowledge of marketplace issues. They will work on the issue, and learn, together. Chloé will therefore have to negotiate the time and availability of the Technical Project Manager (who has his own code development or kaizen work to do) and assess the difficulty or time required for her request. This is an opportunity, if necessary, to prepare it better next time.

I regularly see Perrick returning to the initial intention (what we are trying to achieve) and asking Chloé for her own understanding of the “next step” to be taken. It's a real learning curve: the team has created tokens (specific URLs) to see who is coming to their Opentime site and where they are coming from, to see if the partnerships are working.

A SUCCESSFUL WEEK REQUIRES TIME FOR EXPLORATION

Perrick has managerial constraints: he must bring in new customers, invoice them and then get paid. A small publisher struggles to get its largest customers to pay the licence fee. It is necessary to negotiate and follow a whole process of acceptance and control, at the risk of sometimes stumbling at the last minute over an overlooked administrative detail. Perrick closely monitors the results of this groundwork, as the cash collected funds the time spent on new modules in development.

But Perrick does not consider his week complete without also setting aside some time for exploration, both for himself and his team. A successful week for him means being able to 1) explore (look at the market, meet partners, customers and prospects, analyse the competition, listen to lean feedback, etc.), 2) create new customers, 3) invoice, 4) discuss kaizen with at least two members of his team, be it code, design, customers or marketing. He even tracks it visually each week. This exploration takt spreads throughout the team and transforms the intention to progress into actual daily progress.

We continue the gemba with Perrick. Léa, who oversees design, is working on Cascading Style Sheets (CSS). In her latest kaizen, she had already identified and corrected several design issues in the software and website, including defects and inconsistencies, some of which stem from the variation in software versions. After discussion, Léa, who knows what target architecture vision she wants to pursue, sets herself the next step of designing the current CSS architecture. In particular, she wants to create a matrix between CSS files and software versions to see which file is called on which version. It is from the current precise observation that she will be able to see how to move towards the target.

‍

A few desks away, Jeff, Technical Project Manager, is looking to improve the software’s performance. Time management tools contain a huge amount of data per employee per month, and HR departments are fond of historical extracts, sometimes covering very long periods, and these exports are resource intensive.

Laury, also a Technical Project Manager, is working on the software's mobile application, whose performance had not been monitored until now. Probes now send alerts if the application slows down. Laury learned her first lesson from this kaizen: she has identified code copy-and-pastes that are proving dangerous. Rather than correcting each instance individually, she needs to redesign the overall architecture to avoid these duplications and then upgrade the central node.

AND IT WORKS!

A sign that this whole approach is working is that there is no turnover in the team, even among the most senior members (the company is over twenty years old). It is no doubt easier in a small team to build trust and collaboration, and to ensure that everything runs smoothly when the manager shares the same office. But there are eight different professions within No Parking, each with its own agenda and specific perspective on performance. Even with eight people, it is necessary to negotiate and find compromises—clearly, PDCA iterations contribute to this.

The challenges Perrick presents to them make all the more sense in business terms, as the results demonstrate: all major accounts have renewed their contracts until 2026 (Perrick is keen to reproduce Toyota’s lifelong customers concept: some have been customers since 2006), and marketing efforts have tripled the number of incoming leads with the same budget (and without online advertising, to boot). Building trust through pairing, offering technical challenges through PDCA iterations, giving meaning, seeking value for the customer, exploring: a great approach for this small, successful team.

_{THE AUTHOR}

‍