Standard (or standardized) work is to establish how work is done, a description of how a process should operate. Standardization aims to remove variation in order to create consistency. It ensures that the process is done the same way every time, no matter who does it. The standard represents the best way of doing things.
This sounds quite reasonable in manufacturing process that repeat the same work over and over.
But when I heard about Standard work in a software context I was not to sure. It got me think of Waterfall, Rational Unified Process, lots of documents in dusty binders and bureaucracy. It brought me back to my pre agile days in the 1990s. I thought to my self, how can Standard work be applied to software development? Every project, every software I write is unique, one of a kind! Otherwise I would just reuse what I have previously done. Software development is a craft, an act of design and divine inspiration. Standard work can’t be applied to software development and at the same time be agile!
A few years back I got interested in Lean after reading Mary and Tom Poppendieck’s book Implementing Lean Software Development From Concept to Cash. I started to read Lean books, lots of books. In many of these books Standard work is described as the cornerstone for continuous improvement and continuous improvement is the driving force in Lean.
The counter intuitive and contradictive nature of Standard (or standardized) work in Lean is that:
Standard work will continuously change!
To continuously improve you need to know if a change is a real improvement or not. So how do you know if you improve or not? You need to know your current condition, something to compare against. In Lean this something is Standard work. Standard work describes how work is actually done today and not how it could be done(this comes later). Standard work is developed on the shop floor by the people doing the job(sometimes with some help). Then when you repeatedly do what you described you are performing the Standard work.
When you perform the work and the standard is not followed you have a learning opportunity. You have the opportunity to find out why you did not follow the Standard work.
- Was it something that was stopping you?
- Was it not as efficient as another way of doing it?
- Did the Standard work create any unanticipated problems for you or somewhere else in the process?
If these learning opportunities result in a suggestion to do the work differently you formulate a hypothesis of how the new Standard work, the target condition, should be. You then try it out for a while. If your hypothesis is validated you change your process to use the new Standard work.
Implementing Standard work in a manufacturing process with repetitive task sounds reasonable but how do you implement standard work in something as variable as software development?
It is all about how detailed you get in describing your Standard work. If you abstract up, every process can be described as Standard work. A very basic and abstract, and probably not very useful, way to describe Standard work could be:
- Keep a list of work to do
- Do work on the highest priority item on the to do list
- Keep records of done work
The more concrete you can describe the Standard work the more useful it can be. Standard work should be something that helps you perform the process over and over with consistency. If some part of your process has a high degree of variation of how the work is really done you can start by not detailing this part of the process. As you learn more about the process you can make it more detailed if you need.
In summary: Standard work should describe how the work is actually done. When you find a better way of working, then you change the Standard work to the new way of working and this will for now on be the new Standard work.
In part 2 of Standard work in software development I will show how a team I been working with have used Standard work.