Dear Gemba Coach,
Thank you for your previous column that has raised profound questions for me to work on with my software development teams. For example, what are our “process points”? How do we as lean managers enable thinking deeper together about them? What are the behaviors that encourage “better people to work better with each other to create better processes”?
Thank you, that’s nice to hear. There are two parts to this question. In software development, process points are code plain and simple.
In manufacturing, a process point tends to be repeatable. You think that if you attach a door handle to a car, each door handle should be attached the same way to every car on the line. This is true to some extent, but there are variations: what if you have different models running on the line – door handles might attach in a similar way, but not exactly the same, and quality will lie in the exact precise difference.
Or if one day, you have a really tall guy attaching the door handle, as opposed to the usual operator who’s a short lady. Their movements are likely to be different: their line of sight will be different, their angle of attack will be different. So, ultimately, the process point will be different as the handle will not hit the door body exactly the same way.
Quality and flexibility, in lean terms, comes from making it our business (indeed, obsession) to understand door handle attachment: the moment the handle touches the door and the fasteners are put in, and what tool is used and how the team member understands the job and what his or her hands are doing and so on.
Now, obviously, some process points are more sensitive than others. Some are very tolerant because, hey, a bolt is a bolt, and whatever the car model, whatever the body type of the operator, of the level of mindfulness on the job, at the end of the day, once the bolt is screwed on, it will do the job no matter what.
But some are highly sensitive to context – think of placing a windscreen glass plate without scratching it.
What I’ve seen in software development is that first, everyone assumes that every bit of code is unique (why should it be?) and that every coder should be left alone to code (as if they knew what they were doing).
These two assumptions are by and large correct – in the end, the software will come together as a result of what coders do, will more or less perform what it was supposed to (or not) and will need more or less debugging to getting it to work. This is considered as normal, unavoidable, and the cost of doing business in software development.
But is it?
I don’t know what kind of software you work on, but let’s look at a gemba I was recently in – web apps development at Theodo, a leading software house. Quite obviously, the speed at which a page loads on the web or phone is a huge element of competitive advantage. My (admittedly naïve) understanding is that if your page loads in more than 5 seconds, you’re in the last quartile of the web, users expect a page to load in 2 seconds and will abandon a page after 3 seconds, and if your page loads in less than a second, you’re top of the class. Amazons says that for every second delay conversions drop by 7%.
Clearly coding matters. Again, naively, from looking at the gemba, I understand that loading time is a factor of time needed to generate the files (processing time on the server, database optimization, etc.) bandwidth (can’t do much about it other than assume customers have different bandwidths), file sizes, and processing time on the browser.
Now, I’m getting into territory I really don’t understand, but they tell me that the way your JavaScript code is written (whatever that is) makes a big difference to the way your pages load
Now, every coder can be left alone to develop their JavaScript code, and then some are good at it in some contexts, and pages run up quickly, some are not, and pages are slow. Or, you can think lean, and support the team leader in becoming an expert on the relationship between JavaScript and loading time – this is a process point.
The team leader can then get coders to share their practices, try to recognize different typical cases and isolate typical problems, and ask people to start to solve these problems in their own ways and start agreeing on standards if some can be found. Kaizen.
Now to the second part of your question. In this gemba case, page loading is not just a factor of the JavaScript code, many other factors are involved. Many of these factors occur far away from the JavaScript coding team – they involve data crunching, page design, file sizes everywhere and so on. So when we look at this particular process point, the JavaScript design, and we’ve cleaned up the obvious “don’t do it” points, such as have useless code lying around and so on, we will soon discover that many of the bizarre and inefficient lines of code written that slow the page loading have reasons.
Left to their own design, coders solved their particular problems in their own way, as if each operator had to reinvent how to attach a door handle to the door. But as you look into together how they actually do it, you find that they solve differently some very real difficulties which have to do with the door design, handle design, attachment design and so on.
What happens in other departments far away, as they pass their work over the wall and leave the page loading guys to code the loading, can have a disproportionate impact on the actual loading time.
This is the crucial moment in teamwork when the CEO does a gemba walk, goes and sees the kaizen effort in cleaning up the JavaScript code, and looks into the standards her coding teams are establishing (the process point and how people think about it) – and asks her direct reports – the heads of other coding teams – to explain the obvious problems the coders are dealing with: why do you give them functional code that is so hard to load in the first place?
The Power of Process Points
For instance, in Theodo, moving front-fixing frontend issues, the kaizen team led by the team leader then explored other issues, such as compression of all files, elimination of unnecessary requests from servers prioritizing content loaded for users (most critical content loaded first), and optimization of backend code by eliminating duplicated requests from databases, all of which required looking deep into the code and dealing with issues one by one.
The “lean moment” occurs when the heads of internal supply function realized by themselves by looking at the kaizen (often because the CEO rubs their face in it) that the upstream work they’ve delivered causes many problems to the team, and a lot of nonstandardization comes from issues from internal process deliveries. Furthermore, once these issues are better understood they are shared across the company so that others teams learn what to watch out for.
This is like realizing that the car handle is designed poorly, arrives with manufacturing defects, that the door has not been designed for attaching a handle to it, that the tools to attach the handle jam one time out of ten, and so on. It’s now obvious that the handle team members will have evolved a lot of coping strategies which will be dangerous in terms of quality and wasteful in terms of efficiency – they’re coping with what they’re given.
Kaizen at the process point creates three powerful opportunities:
- Get the people who do the work every day to reconsider how they work, think more deeply about their own techniques and, as they try to improve narrow, specific issues, discover new insights that will make them much better at what they do;
- Bring the heads of supply functions and enabling processes to look at these ideas, realize most of the team members are struggling with work poorly packaged for them in the first place (problems to solve in the supply or enabling functions);
- Occasionally, the CEO will discover in a creative idea from a local team a new idea that could impact the entire business, as they connect the dots on how a very local problem can be the syndrome of an endemic waste no one has ever looked at and has large disruptive potential.
Yet, all of this starts at the process point.
