BUILDING BRIDGES – This month, a CTO explains how his software company borrowed the kaizen spirit – and the idea of a dojo – from an avionics factory and put it to good use.

Words: Woody Rousseau, CTO and co-founder of Sipios

When I co-founded Sipios at the end of 2017, we were lucky to start with a small but amazing technical team, working right away on an ambitious digital product for a large corporate client. There is no doubt we got this opportunity because we are a nimble startup that uses lean and agile and that is, therefore, much faster than what our client was used to: we can launch a minimum viable product in just a few weeks, whereas it takes most organizations of that size one to two years.

In agile, one way of measuring speed is velocity. Each feature added to the product is assigned a certain number of complexity points by the technical team, and the velocity will be determined by the amount of complexity points a developer can deliver in a day.

Unlike lean’s takt time, this metric is not based on the client’s request, but on what the current team can deliver. Everyone expects this metric to grow as the team learns to work together. And, indeed, the stability of the team allowed for a 40% increase in velocity during the first four weeks of the project. But after that, our progress began to stagnate, as new team members joined and new tools made the development flow more complex.

This problem reminded me of an avionics factory I had visited a while back. The site had been practicing lean for the last 10 years, and I remember being struck by their ability to multiply by ten the production of parts, due to an increase of client request in just six months. I was particularly impressed by their effort to standardize the way parts were built to avoid rework, and by the dojo system they had in place to teach those standards to new workers.

Can this idea work in a digital environment? I think it can! Think of Amazon’s AWS Well Architected Framework, in which a system to onboard new team members is described as “enabling access to a virtual community of principal engineers who can review their designs and help them understand what AWS best practices are”. The terms are different – standards are “best practices” and training is “design reviews” – but the idea behind them is still lean thinking. If the big ones (the GAFAS – Google, Apple, Facebook and Amazon) can do it, why can’t we?

ELIMINATING REWORK THROUGH KAIZEN

After around two months developing features for our corporate client, we noticed that new team members were often incapable of defining a step-by-step technical strategy to deliver new features, as the product was getting more complex. A much lighter technical approach was defined on a weekly basis during a workshop, but this was not enough to ensure the on-time delivery of some of the features. The problem we had was rework, both during the development phase and after it (when a senior team members reviews the code the developer wrote).

This didn’t happen in the avionics factory, because workers on the production line knew exactly how to build parts and because each task was standardized. In a bid to replicate their success, one of our team members (Thierry) started a kaizen aimed at having “zero rework on features”.

The first countermeasure identified was to add a “technical design” step before starting the actual development. This new stage in the process entailed the developer writing on a piece of paper a step-by-step technical strategy that listed actual code snippets whenever needed and named the functions and data flowing into the feature. Before moving on to writing the code, the developer would have their strategy challenged by a team leaderto ensure the alignment of the suggested steps with the standards of development.

This new system improved the team’s speed of delivery dramatically, bringing their velocity from 5.6 to 8.3 in just three weeks – an increase of almost 50%.

But there is another, more important benefit to tracking the causes of rework: we were now able to exactly identify the actions our developers didn’t master. Therefore, the obvious next step would be to provide team member with dojo training to help them get rid of the root causes of rework once and for all.

THE POWER OF A DOJO

As I mentioned, the dojo setup was one of the most impressive things I had seen during my factory tour. Right beside the production line, they had placed two dojo workstations. The training of workers would entail the gradual development of their skills: first, the team leader shows the trainee how to product the part; then, the trainee produces the part with the help of the team leader; finally, the trainee produces the part on her own and then delivers it to the team leader.

The trainee was only allowed on the product line when he could build the part right first time, without a requirement of reaching the production takt time as speed was expected to increase along the line. This had an impact on the global delivery of the team and required more resources at first to meet the customer requirements, but it allowed for faster onboarding of new hires.

As I reflected on our work at Sipios, I could see certain similarities between this situation in the factory and a software company being asked by a client to scale because of an important deadline and to build a brand new feature into the product.

Typically, when faced with such a situation, the team would take a certain amount of time to “investigate” the new feature. This often causes the lead-time to deliver the feature to grow to two weeks – one week to investigate, one week to produce.

We figured the “dojo” model could really help us. So, we applied the exact same model I had observed in the avionics factory: developers can now sign up for dojo sessions with an expert of the task (based on the features that are to be developed in the next week of development and on the skills of the team that will work on those features).

On the last two features in need of investigation that we worked on – running code every time a user action impacts what is stored in the database, and writing automated tests – the team was able to complete the work straight away, as at least one member of the team had trained with an expert in the dojo. I can’t stress enough how big an impact this has on our work.

My biggest takeaway from this is that running experiments with solutions or ideas coming from other industries (like avionics, in our case) is key to scale – a lesson GAFAS learned a few years ago. We have the unique opportunity to show the kaizen spirit to corporations that would never think it could apply to digital projects. Let’s seize it!

_{THE AUTHOR}

‍