In my previous article on the CTO’s gemba, I discussed why the gemba practice is essential for tech leaders and outlined my four-step method. Let’s move on to the practical side of things and share a few examples from my personal experience to illustrate this confrontation with the reality on the ground. This will be an opportunity to highlight the lessons learned for managers and the lessons learned for teams.
Quality of specifications: we make do with what we have…
Paul is working on a new feature for our back-office application. He shows me his specification, which fits into a single line in a Jira ticket in the form of the beginning of a user story: « As a contributor, I want to manage the change history of my document. » No mock-ups, no test cases, no additional management rules…
We agree that this is a bit short for the planned 12 days of development. So I ask him how he manages to develop from so little input. And then, resigned, Paul tells me that he asked ChatGPT to generate a more complete specification for him because the Product Owner, who wrote the specification, is on vacation!
Clever, but does it really meet users’ needs and solve their problems? 🤨
What can we learn from this situation?
Once the initial surprise wore off, I understood that the Product Owner in charge of specifications did not deem it necessary to provide more details about this feature. On this point, it would be interesting to talk to him directly and understand why. Did the functionality seem obvious to him? Did he run out of time? Ultimately, what would be the checklist to ensure that a specification is ready for development, aka Definition Of Ready?
The second realization I had that day was that my team develops even if they don’t have all the necessary information, even if it means inventing it with AI. And that’s a tremendous opportunity for me to assert our role in technology. If certain elements of the specifications are unclear, we have to validate the assumptions before developing with the real customer needs. It’s better to block the feature than to continue developing code that doesn’t meet user needs. The worst waste of all is developing features that are useless to the customer.
And Paul realizes that he has the right to say no and to be more demanding about specifications if necessary. This turning point marks the beginning of a journey toward greater maturity and confidence with the ongoing support of the manager.
The flipping feature
A second example involves a developer, Emma, who is working on a feature requested by one of our most prestigious and important clients. Emma is therefore under some pressure to get it right. The task involves formatting copyright information in a PDF file that strictly adheres to the web layout. Previously, the PDF was rather rough compared to the web page.
Development is almost complete, and I see that the Jira ticket indicates that this feature will need to be enabled via feature flipping for this customer. You know the impact of this type of activation in the code: an additional if statement that complicates maintenance and yet another property to enable/document for each customer (even if it can tend to encourage the Separation Of Concerns !).
I ask Emma what she thinks about the interest of feature flipping in this specific case. The answer is clearly negative:
We could easily offer this feature to all customers. Who could refuse such an obvious improvement?
But once again, what do we do?
Emma asks the Product Owner, who wrote the specification, what he thinks. Fifteen minutes and one Slack message later, we get the answer:
Oh yes, I put this feature in feature flipping because I didn’t know if it would interest other customers. We’ll see later 😉
Once again, two very interesting lessons emerge.
On the product side, of course, because the Product Owner is clearly unaware of the impact of her decision. Even if it may seem prudent at first glance, because we are limiting the risk of dissatisfaction by activating this feature only for the requesting customer, in the long term, the impact is catastrophic for the maintainability of the application. Given the cross-functional nature of the issue, I suggest to Emma that I deal with it personally at my level with the product team. A few weeks later, this will result in a demonstration to the product team of the impact of feature flipping in the code, a reminder of the dozens of features activated for just one customer (no flag clean-up process), and ultimately, a joint decision to limit feature flipping to exceptional cases.
As for Emma, she realized that she could challenge a request that seemed absurd to her and make a clever counterproposal based on her technical and functional expertise. This subsequently enabled us to adjust the roles and responsibilities of the product team in relation to the engineering team within our organization.
Repeated disconnections
We are here at a large distribution company with Bruno, a young developer working on an AS/400 system. During the gemba, Bruno is disconnected from the internal VPN three times while coding, which causes him some annoyance. Each time, he has to reconnect, resynchronize his code repositories, and get back into the context. We discuss the recurrence of these disconnections, and he explains that all AS/400 developers are annoyed by this.
It’s always been like that, whether working from home or at the office!
In addition to the significant disruption for the entire development team, I quickly do the math: approximately 10 disconnections per day x 15 developers x 3 minutes lost = 7.5 hours, or 1 FTE!
I then ask Bruno if he wants us to try to understand why this is happening and how we could solve this recurring problem. He first explains to me that several people have already tried, but that it has to do with IBM and that it’s very complicated… After some encouragement from me, Bruno decides to take the matter personally.
After several weeks and numerous false leads (VPN timeouts, Git settings, etc.), Bruno finally found the root cause and the correct settings at the AS/400 level with the help of IBM support. For all his colleagues in the IT department, it was a relief—disconnections are now just a bad memory!
Bruno, the « youngster », is now the person in the team who has the best understanding of the end-to-end network configuration from the development workstation to the server. And to top it all off, Bruno will be interviewed on the IT department’s internal video channel in front of 150 colleagues to explain his approach and what he has learned from it.
More than just learning, for me it confirms that a young employee who is given confidence can have a very strong impact on a team thanks to his determination and desire to shake up the status quo, where sometimes more experienced or senior people may be more resigned.
The users’s perspective
And finally, to conclude, I would like to introduce another type of gemba: the user gemba. The principle and objectives remain the same, but this time the observation is carried out among end users.
The problem I was facing was as follows. A tech team had developed a web portal configuration application for internal users. Let’s call these users « configurators »: their role is to configure web portals for customers down to the last pixel. I regularly heard numerous complaints such as:
The configuration application is completely unsuitable! It’s a nightmare…
You spend hours trying to configure simple things…
Can you imagine the impact on:
- Customer satisfaction: delays in portal deliveries, quality issues…;
- Our software company: direct impact on profits because more time than expected is spent on configuration;
- And the teams: some configurators are a bit desesperate, and of course tensions are beginning to arise between teams.
I avoid launching a series of workshops to identify the problems encountered, which would probably result in dozens of changes and fixes in an already overloaded product backlog. Instead, I ask some of the developers on the team:
Do you know how configurators set up web portals?
Almost unanimous response:
Er, no, not really.
At that moment, I realised that my development teams didn’t really understand the specific use of the product they were developing. To exaggerate slightly, it was a bit like an automotive engineer designing an engine without ever having been in a car. And this situation exists in our company despite the geographical proximity of the teams and the generally good working relationship. Silos are very much present in our small company (around 100 employees).
My goal is to help them connect with customers: discover how users actually use the product so they can better integrate this into their daily development work. I then suggest to three developers on the team that we work with them to conduct a user gemba with a real end user, a configurator. The meeting is set with Zoé, who plans to configure a new portal during the reserved time slot.
And then we spend two fascinating hours. The reality literally jumps out at us: the sticking points, the wasted time… The team of developers becomes aware of the actual uses and obstacles imposed on Zoé with the current application.
For example, every time she changes the user language, Zoe loses her focus on the (very long!) page listing all the available settings, which wastes valuable time… We begin discussing some very simple changes that could significantly speed up Zoe’s work.
The consequences are rapid and highly impactful, with developers coming up with ideas to improve certain flaws that have been identified. Within a few weeks, direct exchanges between configurators (end users) and developers have resulted in the delivery of around ten new features. The configurators are rather satisfied and their team’s velocity is on the rise again. Another direct consequence is that the volume of specifications related to this configuration application is decreasing thanks to the developers’ growing expertise.
Of course, one could argue that it is the role of the product or project management teams to specify everything clearly and unambiguously, but the reality is that they don’t have the time to do so, and there are always implicit assumptions! Above all, this should not prevent the tech teams in charge of development from understanding the purpose and use of what they are developing in order to be even more relevant.
Conclusion: help us to see the elephant in the room!
Quite regularly, during gemba there is what is known as an « elephant in the room », i.e. a significant malfunction, problem or blockage. However, the person is not always aware of this, as in the example of disconnections. This is a very common situation and is part of the learning process for managers and employees who suddenly become aware of it. We are all used to living with obstacles imposed by software, processes, practices, etc. for days, months or years. Gemba helps us turn on the light so we can see the elephant! Of course, the problems observed cannot be solved overnight, and this much sought-after culture of continuous improvement must be constantly supported by all managers.
As with our politicians, who are often criticised for being « out of touch with reality », gemba seems to me to be an essential practice for managers. It enables them to develop a leadership style that is closer to and more attentive to their employees, and to build a culture of continuous improvement where everyone has the right to make mistakes by involving each person directly. Finally, it enables the tech leaders to make more informed decisions based on the reality on the ground. One caveat, however: while gemba is rich in lessons, it can also destabilise employees, hence the importance of creating a climate of trust and security.
The excellent Boulet illustrates this confrontation with reality in his own way:
Heavy is the Reality Brick on the Strawberry Tart of our Illusions.
(c) Boulet
And you, what have you discovered in the field with your teams, what lessons have you learned from this ?
Many thanks to Thomas L, Natacha R, and Philippe F for their help and inspiration!
Laisser un commentaire