Improve the environment rather than produce poorly
This is the 2nd post from my sincere dev manifesto series.
Upgrading the environment by 1% each of the 218 days we’re supposed to work annually in France, stacks up to a 77% increase at the end of the year.
On the other hand, letting the environment deteriorate by 1%, each of the 218 days, adds up to a total 89% decrease at the end of the year.
And the system naturally decays.
Imagine comparing the teams that continuously improves and the team that lets the system decay, at the end of the year. Between them, you get an 77 fold ratio. Hard to justify, right? Continuous improvement is a mandate, it needs to be a part of every task the team does, every day.
So let’s go for:
- The boy-scout rule, leave the place better than you found it. Fix warnings, make intentions clearer, give pieces of code a name, write and update standards, talk to people, take a walk and think, remove clutter or obsolete things, clean up the place, say no and make sure it’s OK to say no, be an example of what you evangelize, fix broken windows…
- Retrospectives. There’s much say about them, and whole books are dedicated to it. Basically, it’s a double diamond (find issues and analyze them, find counter measures and prioritize them). It’s great for low hanging fruits, issues that are easy to fix in a meeting and agreed upon. For more complex issues, the best action you can come up with is “think about the issue”.
- Andon is a practice that makes you stop the line at any problem, in order to look at it now, in the context where it happened. In software, you can see it at many places: compiler errors and warnings, CI pipelines blocking deployments, teams stopping doing anything else when the build is red, kanban expedite lanes for customers/prod issues, 0-bug policy… You want to provoke fail-fast everywhere in your process, and react quickly to issues while you have information available to understand them.
- A3 problem solving is a longer activity, where you take the time to put issues in context, measure them, measure causes, measure and compare counter-measures, and think about how to spread the word about what you discovered. It typically takes weeks or months. When running an A3 problem solving, you learn a lot about the context and what makes it unique. Which is why this practice is actually a teaching practice at Toyota, where senior managers use it to teach middle managers about lean, the scientific approach, and the context. Do you think we don’t need to learn problem solving? I definitely do.
- Kaizen workshops, where you optimize a standard as a team. We don’t see them much in software because it starts from a standard for a somehow stable activity. But we can use this format for many things, like sharing practices, finding new ones by mixing what people do, or writing standards. And we need to share practices a lot more than we do today.
- You might also want to put poka-yoke in place in order to make sure that issues are actual issues. Poka yoke consists in making know issues impossible, like foolproof devices, type systems, automatic tests, prefilled choices, and so on.
- Writing standards. Standards are best yet known ways of doing things. They need to evolve on a regular basis. There are several legends about standards and Taishi Ohno, one the main lean gurus at Toyota, like turning to fury mode when he saw a standard paper turning yellow, or writing subtly wrong standards on purpose, when the teams wouldn’t have one, to make sure they updated it.
Improve code, architecture, practices, people, knowledge, understanding, health, inclusion, diversity, process, relationships, behaviors, influence, fun, all the things. It is part of every single task, and everybody’s job. Your future self will hug you.
There’s a lean saying that goes “no problem is a problem”. There’s always a problem to solve. If there’s not, we’re not ambitious enough. Once you spot a problem, fix it. This is how we learn, understand, progress.
By the way, making improvement everybody’s job is the great breakthrough from Taylor’s scientific method to lean. In taylorism, brains think and arms do. In lean, we try to push decisions to the place where information actually is, i.e. the gemba, the plant, the lab. “Next time you call me a resource, I call you overhead”
I commit to taking the time to identify, prioritize, understand, and fix issues, every day, whatever the stated priorities.
AAAgile 
One comment