What would "process points" be in software development?
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.
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.
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.
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.
Don't you use kamishibai cards; you've never written about them?
Dear Gemba Coach,
We use a kamishibai board along with standardized work and visual management to sustain our lean efforts on the factory floor. It works great. You've written about standardized work and visuals but not kamishibai cards. Don't you use them?
As head of a lean office, what must I do to really walk the talk?
Dear Gemba Coach,
I am the head of a lean office. I’d like to lead by example, but it occurs to me that we often make the very same mistakes we coach others not to do. What must I watch out for in order to really walk the talk?
Got any recommendations for applying lean in the tool and die shop to stop our dies from crashing like crazy?
Dear Gemba Coach,
We applied SMED to increase the flexibility in our production cells. Now our dies are crashing like crazy and disrupting production because maintenance can't keep up! Got any recommendations or experiences in applying lean in the tool and die shop?