Visualizing the whole product life cycle is important for everyone to understand how product is developed and maintained. The value stream mapping workshop is a good practice to create a picture of your current flow and to build a future image of it. Please check also this post – The Flow – You mean efficiency? for great details!
This is how Peter Antman in his short eBook Stop The Line describes a bug.
It happened that I’ve read his book a few years ago, but opening it again these days, I found it as confirmation of the efforts doing lately in my organization. Peter outlines the necessity of short feedback loops, testing code as soon as it is written and verifying it as frequently as possible.
The book presents the roots of the automation process started a hundred years ago by Sakichi Toyoda- years before Toyota became an automotive company. Automation with human touch was the aim.
The aim to build quality in is the core of the famous Toyota Production System. It is called Jidoka (autonomation), i.e. automation with a human touch, which is a process of bringing the human detection in discovering quality problems when
they appear. Every worker in his reach has an alarm button (called andon) to signal any abnormality, problem or a quality issue. Such an act may bring the whole production to stop – literary.
Now, compare this to the process of software creation. We have a number of tools to speed up the coding and testing, like syntax and semantics instant checkers, automatic build, automatic tests… continuous integration (CI).
How often do we stop all developers when build is broken and CI tests fail?
A CI failure is not really a halt in the process, it is rather a call for an action, a request to investigate what went wrong and WHY. With the CI, we have a mechanism to create the CULTURE (see the post about culture) of learning and thinking about quality.
As Peter says:
If you – as a developer, as a manager or as a company – are not prepared to change the culture and, at least initially, pay the price of stopping the work and start chasing defects, I would question the value of having automated continuous integration tests. It’s even worse than that. If you have a continuous integration environment that is frequently (or always) red and you don’t stop the line, the system will decline over time. Each instance that the line
is not stopped will result in a push for producing more bugs.
Perhaps in the future we will invent a new paradigm of creating faults-free software when we just specify our wishes, or our thoughts and a 3D hologram will present the solution/product in front of us.
Hmm, not a bad idea – such a pity I shared it publicly…
However, till then, try to follow the practice which is holding now for a hundred years… and gives results. Give me your thought on this – I will HIGHLY appreciate them!
I imagine the organizational flow as a chameleon. There is around 160 species of chameleon on Earth and many of them are able to change their skin color. The usual belief is that they change their skin color to match the surrounding, to camouflage and protect themselves from danger. The scientific truth is that chameleons are not able to produce their own body heat and therefore, they change their skin color to reach or to maintain a favorable body temperature. A color of their skin also changes depending on their mood, where e.g. tension causes bright colors to dominate. Their color also changes to signal their potential partners a willingness to mate. More impressive than the color effect itself is the mechanism that enables chameleons to perform their transformational play. Namely, their skin constitutes of a number of layers, where the outer layer is transparent and quite resistant. The inner layers contain specific cells, filled with different kinds of pigment. Depending on the body temperature or a particular mood, the nervous systems acts towards the cells and makes them contract or expand, which in turn changes the color of the cells. All this is done in a blink.
It is hard to identify our flow with chameleon, especially because the chameleon is not exactly the embodiment of beauty. But, it is the unique specie and perfect in what it does. It took a long evolution process to perfect it; to be able to survive. So, chameleon has not adapted against the environment, but it has kept the skill to continuously adapt. That is the characteristic that we need for our process, for the flow.
The term flow I find appropriate because the value that is produced should be fluid and move nimbly over the obstacles in its way. The flow should be able to adapt to external factors (like temperature) and internal factors (like mood).
The people from The Gemba Academy, in their set of educational videos describe the flow through the Value Stream Map definition, saying: “…all the steps, value added and non-value added required to take a product or service from concept/raw material to the waiting customer”. Mary Poppendieck, the lean SW guru, emphasizes the flow visualization through the sequence of timely labeled actions represented as a map of the value stream in her book “Implementing Lean Software Development: From Concept to Cash“.
There are a number of authors and consultants suggesting the same or a similar approach. Still, very few organizations that I know use the value stream mapping to visualize the flow, and start learning to see the waste and non-value added steps that every organization has.
One of the main obstacles to see and to act supportivelly towards the flow is the organizational border, i.e. effects of local optimization - the situation (and the culture) where focus is on one’s own role and work based on input <>output, rather than working collaboratively on the highest priority/value.
The leaders contribute significantly in creating (or preventing) a flow, which should be as much as possible a continuous and as less interrupted as possible. It is a matter of education and maturity (no hard feelings!). The leaders, as mentioned, should get educated about Lean and flow and be determined to put the flow of value always in focus, rather than the success of their own team or department success. To my experience, this is the prime challenge with the Lean leadership.
The common issues seem to be the following:
- Every department, or a team, or a person, has its own interpretation about the flow
- There is a lack of agreement on which level should the flow be illustrated or drawn
- There is no common interpretation on what the flow unit is (what actually ‘flows’)
When people from different departments, or teams, work together on a common value stream, it is a precondition to build a common perspective. The prerequisite is to look at the big picture, not individual processes. It is to realize that there is always the information flow attached to the production flow. The information flow is: all the documents, materials, visual information, etc. helping and supporting the production flow. Usually, there is a tendency to get involved with a lot of process details when drawing the flow image. We should start with the high level first.
In SW development, the unit of the flow may vary from organization to organization. It could be a feature, a requirement, or a user story..
Experiment with the flow and the unit of the flow, but have in mind that you always need to work on the most prioritized items. There are no successful and sustainable (Lean) benefits without focusing on the flow. As a matter of fact, Lean and flow are inseparable.