Material concern is not only inherent to the manufacturing industry. Of course, it is much easier to understand it as it is tangible. This does not mean it is not complex. Take a bicycle, a computer or any manufactured good, you can easily visualise some of their components, but you most probably don’t have a clue how it is assembled and what brings value to that good in terms of mechanics. As a user it is not essential, one will only expect the good to function and deliver the service it is meant to.
Now place yourself in the shoes of the creator (not the almighty) or the people on the assembly line who are in charge of producing value and quality for the future customers. No one will question the need to dispose of clear specifications on how to build the product and test it at various steps to ensure its global quality.
So why should it be different in IT?
An application or a service is the product that someone will use for a specific need. A new functionality is like an option for an existing product that must fit and bring a useful evolution. Taking these aspects into account, how do I make it come true in the business world?
Lean will definitely help you as it focuses on customer satisfaction, built in quality and lead time to produce in the most efficient way possible. Thus how do I start?
- Define clearly what you are aiming to produce and the benefits of that for the end user.
- Represent visually what you want to produce (drawing, state chart, ADR…). First render a view of the functionalities to share their value and prepare a more technical mapping to clarify how it will be built.
- State all the inputs needed for production, list the dependencies and how you will verify that it functions.
- In case of bugs, start technical problem-solving to understand the underlying patterns of error.
Is it easy? No but it can be fun if learning is seen as the key purpose allowing continuous improvement.
Are we speaking the same language?
Code is a language and coding means respecting its grammar. In IT and on earth there are different languages with specific rules, but they all intend to communicate (be it with systems or people) to deliver an understandable and non-ambiguous message which is very close to the principles of security and quality in traditional lean manufacturing. Coding is a skill but also the input for the programme to be.
Mastering a language needs practice and training to understand how it works. Everybody agrees Rome wasn’t built in a day so why should it be different with coding?
Leave the stylistic effects of literature aside to focus on simplicity. A clear and direct sentence will be understood by everybody and its message easy to validate.
First, define what is a simple sentence and how to identify it is really simple (describe the points of control) and explain the reason why it is important to build such kind of sentences. By breaking down how to code correctly it will only become easier to spot abnormalities and logical errors. This is what lean calls “work standards”, and this topic is very well tackled in the book “Training within industry” which has become the name for a learning methodology unchanged since WW2.
By considering coding has its own grammar and syntax obeying to specific rules to create a command that will become something visible and useable for and end-user, we are thinking material flow.
Now that we have demonstrated that industrial production is not far from IT production in its thinking and that the latter depends on material (specifications that will be transformed into code depending on assembling rules) the next question is to understand how it should flow to bring value and quality. Lean is clearly a good way for tackling it and provides a set of tools (Obeya, pull flow, PDCA…) to help you reach the expected target.
Obeya is used to monitor a project. It will help you clarify the purpose of the project with the value and the customer in mind. The future product to be produced is visually represented to ensure all people involved share the same understanding of the goals and how the product has to be built. Major milestones (macro planning) are also visually shared as well as specific tasks (micro panning) to meet them, and performance indicators to make sure the project is on track. Problems identified along the project are listed and dealt with applying the PDCA methodology.
Pull flow is a powerful tool for the production team to understand clearly what must be produced every day and guaranty that the daily production brings value to the end user. It also enables to spot difficulties in real time as the tasks to be done are made visible according to their progress along the production process. In case of bottlenecks, actions can be taken at an early stage to protect the customer. The problem solvings made daily to reach the production targets will only strengthen the team’s knowledge of their job and help improve their work standards.
The plan, do, check, act problem solving tool attributed to Deming can also be described as what David Kahneman names “slow thinking”. The underlying benefit of the PDCA approach is to conduct a thorough root cause analysis on a clearly stated problem (that is a measured gap from an expected target situation). By doing this, a team or an individual avoids jumping to fast conclusions and questions processes or specific tasks differently to eradicate the problem and not only fix it temporarily. Deeper analysis brings deeper understanding of the cause-and-effect relation and as a matter-of-fact deeper knowledge on the job.
The power of lean is that it proposes a variety of tools to help you see problems and address them one after the other. It is a never-ending game with learning at its heart to become more efficient and adapt faster to changes whether they are strategic evolutions or just daily difficulties. Once you have entered the “Toyota house” (Toyota production system) you realise it is like the Sagrada Familia, it is never finished. Improvement is infinite.