FEATURE – This month, the author learns how gemba walks happen in a digital environment, where the work and information are typically hidden in computers.

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

This is my fourth gemba dive into the Theodo group. In the first three articles in this series, we have seen how the company is improving its customer lead-time, effectively thinking out customer value, and recruiting and retaining talent. As you follow the progress of my investigation, I hope you are also able to experience some of the gemba fun I am having!

One of the many challenges facing a fast-growing digital group such as Theodo is how to walk the “shop floor” and check on the status of both code design and production, when all the information is hidden in computers. Understanding how Theodo is trying to overcome this obstacle is the purpose of my visit to Marek, BAM’s Chief Technical Officer. BAM is one of Theodo’s earlier spin-offs (it was founded back in 2014) and, like most of its sister companies in the group, it has enjoyed double-digit growth in 2020.

Marek tells me why he co-founded BAM: “Theodo was and still is very much dedicated to web Apps, but we wanted to develop our expertise on mobile Apps too. We had the hunch that being able to develop both on iOS (Apple) and Android at the same time would make a breakthrough.” Back then, Marek explains, an app would have to be developed twice – on iOS and on Android – and that required the expertise of very different sets of developers. Then Facebook developed ReactNative,  which helped to considerably reduce the complexity of such projects. BAM piggy-backed on it and learned the trade. They are now starting to do the same with Flutter, developed by Google, and are also improving their own iOS and Android skills.

Competition is everywhere on mobile apps and BAM’s early move towards them in 2014 is already losing its edge. Competitors can be companies like BAM, but the talent of the developers they hire or sub-contract can make the difference. “We can either try to go and chase the top guns, at the risk of losing them later for one reason or another,” Marek says, “or we can train ourselves to learn the trade continuously and hone our technique so as to systematically deliver quality and reliability. This is the path we are following.”

Marek shows me a graph on his office wall, tracking the number of days sold divided by the number of bugs during that same period: the equivalent of a ppm tracking or, rather, the number of worked days with no bugs. The number has been improving recently, but it is a never-ending fight.

WALK THE GEMBA IN A TECH WORLD

“As a CTO, walking the gemba is one of the most important contributions I can make,” Marek says. “The market is moving very fast and CTOs are confronted with three major issues: stay close to the code and the technology while scaling up; constantly develop and align the team; and manage a permanent crisis between demand and capacity. Any slippage on any one of those topics can hurt the business badly.”

You might wonder what scaling up concretely means in Marek’s life. Tech people used to directly report to him some years back, but are now led by a Team Leader, who reports to an Engineering Manager, who will soon report to a freshly recruited Engineering VP, who will in turn report to Marek.

As CTO, Marek has developed his own idea of gemba walks: “It’s an on-the-job silent observation, whatever the job is – developing code, designing functionalities or the underlying architecture, performing maintenance, overseeing roll-outs.” (Some examples of the notes he takes while observing can be seen below.)

The observation (which lasts around 20 minutes) is followed by an exchange. Marek tells me: “It is not an audit, but rather a way to check on the work system I have created as a CTO. It’s an opportunity to help people when the problem is outside of their control – methods, staffing, training, and so on.”

Marek interrupts our discussion as it is now time for his gemba observation. With the pandemic and some of the staff working from home, gemba walks often have to be conducted remotely, as is the case of the one I am observing. “It is far from ideal conditions. When sitting next to someone, I can see when the person is looking for missing data or a certain piece of information. I can see where she goes, how she investigates, what she looks for. There is much to be learned from this, for things like our 5S or our on-boarding and training processes. In a remote session, I can only see what the person chooses to share.”

GO SEE, ASK WHY, SHOW RESPECT

The remote gemba walk we are starting with Marek focuses on a functional and technical design workshop. It is between a BAM architecture expert (Guillaume) and a third-party developer, sub-contracted for the job (Vincent).  Also attending remotely is Antoine, the manager of this team.

The topic is the design of a common eCommerce, click-and-collect App for professionals purchasing building materials. The customer wants to merge the needs and specificities of its four brands into one common tool, starting from one legacy App. At this stage, the team is working on a Minimum Viable Product (MVP).

We watch in silence as Guillaume and Vincent work on and discuss the design of a screen that describes the sales outlet, the address and its opening hours and days. As the original App was developed by the customer, they are using a collaborative platform, Postman, to reverse-engineer the API (interface). In other words, they are trying to understand the current App and build a new one using their observations.

Twenty minutes later, Marek, who took many notes, stops the work, and engages in a discussion with the team. He probes each of them, one at a time, with these two questions: what do you think of the current situation? Can it be improved?

Guillaume, the Architect, explains what they are trying to do: “It is important that we agree on the data model upfront to avoid reworks later on.” But he then stumbles on a technical issue: “I have not been able to access the Postman configuration created by Vincent. We should share them as soon as they are created.”

Vincent, the external dev, admits that they are struggling with the naming conventions: “We possibly spent too much time wondering how to name the opening time field and qualifying it with a string, number or float. Should we have done more preparation work upstream? Or maybe ask the customer API expert to attend?”

Antoine, the manager, steps in and starts with the “well done” points: “I fully agree on the importance of securing standards on the data model.” He then wonders, as Vincent did, whether the workshop is of any help in this instance: “Working together is useful to solve an issue or to train someone, but was it the best way to progress here?”

Marek has listened intensely and starts by approving the data model defined upfront. But he then challenges the group: “We are working on an eCommerce App, a widely-known product in our tech world. Could we start from something that exists rather than create the standard from scratch?”

Both Antoine and Marek have verbally confirmed the good points (secure a data model) and challenged the Techs with questions - two management behaviours essential in a gemba walk. Everyone knows what Fujio Cho, honorary chairman of the Toyota Motor Corporation, would say: “Go see, ask why, show respect.” Having a senior exec sitting next to you is impressive enough (Marek is currently a N+3), but when she gives a solution rather than foster learning and experimentation through questions, people will likely think to themselves: “Who am I to challenge her?”

The art of gemba walks is to probe the current situation – “Are we under normal conditions?” “Are we working right-first-time?” “Are we on track?” – and to raise questions on possible alternative ways.

Guillaume and Vincent have to leave the meeting, and the debrief continues with Antoine alone:

Marek: “Antoine, what did you learn as a manager?”

Antoine: “That we spend too much time on design.”

Marek: “What is the misconception here?”

Antoine: “Believing that no help is needed to design the data model?”

Marek finally allows himself to propose a possible track. “The data model comes from the existing customer API. What could help here is a Domain Driven Design approach, to agree on the objects (entities, events, transactions), their naming and interactions. Once that is clarified, coding should come easily,” he says. As he will later explain to me, the team was trying to reverse-engineer the API built by the customer, with no clear idea of how the data model should work. The most efficient way to approach this would be to think out the data model they need first, with a DDD approach, and then go to the legacy API and pull the data information from it.

Antoine continues: “Point taken. I have planned to strengthen the team with the addition of an experienced team leader, but I also need to think in terms of typical problems/typical solutions when I do a gemba walk. DDD would naturally emerge as a solution in this instance.”

Marek also asks him to check the design platform they are using to draw the architecture scheme. Developers are free to select their design environment, but Marek wonders whether this platform is actually enabling collaboration with other ongoing projects, in order to benefit from existing models. The discussion between Marek and Antoine is interesting: they are very conscious that sharing the code is a must (in fact, Antoine even designed a shared code library for BAM), but have not yet questioned the need to share the design environment itself. This gemba walk is a clear opportunity to raise this point.

WALK THE GEMBA WITH AN UNDERLYING FRAMEWORK IN MIND

As the discussion with Antoine ends, I ask Marek how he prepares for his gemba walks. He confirms it is never a surprise visit. To show respect means that a formal appointment is taken and explanations are given on the why (check whether people work under the best possible conditions) and the how (observe and exchange). “I plan two such gemba walks every week. When we started BAM, I was working directly with the Devs and when I‘d see that one of them stayed at work late, I would stop and sit next to him or her to try and understand the issue and help. I really started a gemba schedule in 2020, because we all worked remotely. A gemba walk, even a remote one, is a great way to nurture trust and tighten bonds within our BAM Tech team.”

Thinking about what I have just witnessed, I must say that the richness of the gemba walk is truly amazing. How else can you detect non-standard conditions, such as the choice of a collaborative design platform with a sub-contractor? How else can you spot training needs such as a DDD approach to save time on the data models? How do you help managers develop their own support role? Scaling up means you are constantly onboarding newcomers to keep up with the growth. Checking on them is the least you can do to help them ramp up as quickly as possible.

Marek confirms that there is much to be learned on the gemba. “It feeds my own understanding of where we are in terms of staffing, technology and strategy. It also nurtures my lean thinking on our strategy,” he says.

When I ask him what he would recommend to those who are beginning to go on their own gemba walks, he tells me that it’s important to have a clear framework in mind, a representation of both the business and the human interactions within it, as well as a good understanding of the technical competences you need. Marek is adamant about this: “You cannot watch and observe without a framework you can refer to. I have been on the gemba for quite some time now, this has enriched my understanding of the technical competences we need, something I am always on the lookout for. When we started discussing data models just now, the framework that came to my mind was DDD. Another framework I use is the TPS (Toyota Production System), of course. I have learned from my sensei to think in terms of who needs to learn what in order to improve.”

Remember the exchange with Antoine, the manager? Marek was clearly probing for misconceptions and learning there, sensing Antoine’s understanding of what he had witnessed, challenging him on what he did not see, helping him to develop his own framework, and fostering problem solving.

Marek tells me something he experienced on a gemba walk. The Tech he was sitting with was testing a feature for a mobile App. He witnessed 17 minutes of laboring once the code was ready to be tested: looking for multiple devices in the device lab, on which to test the developed code, not immediately finding all the models he needed, then manually downloading the latest application version on each, failing the test and seeing the App crash. Marek pulled out his two usual questions. “Does this happen often?” “Rather,” the Tech said. “What do you think of it, is it normal?” “Hmm, no, not really.” Marek then challenged him to keep the build and test of any new feature under 10 minutes. This triggered thinking and two weeks later that same person came back. He had found a way to reduce the time to install and test the feature on the devices, saving one man-day per week for BAM.

It is easy, when you pile up responsibilities and move up in the organization, to stop visiting the gemba altogether. Bureaucracy, major cross-department issues and corporate politics (among other things) have a tendency of sucking us in. That’s why the only way to keep up with the real world, help teams grow their competences and customers benefit from them, is to set up a schedule of very regular visits to the gemba. “Gemba walks are opportunities to align the teams around BAMs’ strategy and to correct it if it can’t be executed correctly,” Marek adds with a smile.

_{THE AUTHOR}