Because it is essential to understanding lean (and I want to refer to this continuously), today we’ll talk about lean standards. If you’re already thinking that standards aren’t lean (or agile) because they’re rigid, audited for compliance, and defended from change, then you are not familiar with lean standards.
Hello Lean Standards
To quickly introduce lean standard work, we’ll go to the grandfather of lean
Today’s standardization…is the necessary foundation on which tomorrow’s improvements will be based. If you think “standardization” as the best you know today, but which is to be improved tomorrow – you get somewhere. But if you think of standards as confining, then progress stops.
– Henry Ford
Standard work is typically designed by those who know the work best. These are also the people who are most well equipped to evaluate changes to the standard. These are the people actually doing the work.
The key is that everyone in that role follows the standard. When someone invents a way to do the work better, the standard is changed. Because everyone follows the standard, the improvement cascades across the entire team. In this way having a standard is a tool for individual empowerment, innovation, and continuous improvement (kaizen). It allows us to prove that a change is an improvement (by comparing it to the current standard), rather than demonstrating that we have found merely another way of doing the job.
For standards, there should be a simple visual control so that everyone can see if something is within the standard.
This can be the job instructions (posted outward so that others can see that we are following the standard). If we were on an assembly line this might be colored regions on the floor indicating at which point you should be done with your job and getting ready for the next car. If you see someone working on a car after that marker, they are out of standard. Because there is something out of standard, there is a problem. Because there is a problem, there is an opportunity for kaizen.
Standards & Kaizen
There are several forms of kaizen. The most abundant kind involves just handling the problems the world throws at us everyday. Whenever anything is out of standard (a misshapen part, a misplaced tool, a person behind the takt, code coverage is too low) then there is a problem; there is an opportunity for kaizen. We must strive to sustain the standard.
Bigger process improvements, that most people think of when they hear “kaizen”, are typically obtained by changing the standard; sometimes dramatically. Such a change means that you are out of standard more often and must find a way to improve the process.
Agile alludes to, but does not include the idea of standards. Scrum, being a bit more explicit, gets closer but is also lacking. The prescribed Scrum activities can give way to standards, but they do not provide this.
We’ll find that in most environments, agile benefits greatly from the use of lean standard work and visual management. However, we’ll draw attention to a good use of lean standards as we explore topics rather than trying to create a list here. For your consideration, here are the three agile principles that insinuate the presence of a standard.
9. Continuous attention to technical excellence and good design enhances agility.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Do you have any standards that support those agile principles? Any best practices?
Do you have visual management to support those standards? Can everyone see and do they use these?
When something is out of standard, is kaizen practiced to immediately fix the problem?