Two Worlds , Many Questions

Hello colleagues and welcome back to a special edition of the Weekly Lean Series. For quite a time, both looking at ideas in industries and during discussions with different experts I came to understand that there are many different grasps of two different worlds, namely Lean and Agile, and with a deeper look, I couldn't help but notice that for some, these two worlds are alternatives and in this part I would like to cover some misinterpretations.

To begin with, Lean methodology originates from the shop floors of manufacturing. The principles that lay the foundations are sound practical applications to help create value, control waste and increase Value Add in a manufacturing environment. To begin with, we cannot deny the quality influence of Edward Deming in Japan after WW2 where he worked with industry leaders of Japan regarding quality management. With this influence at hand and with PDCA logic intact , it was Toyoda family who decided to go one step further in their automotive business where at the time Ford in America was a pioneer competitor with vast resources .

Certain components like the pull idea by Taiichi Ohno , a different inventory perception ,waste focus , set-up focus due to necessity of building a range of models , the idea of flow by Ford, quality losses and the tight resource constraints the company facing made engineers like Shiego Shingo think out of the box and Toyota built its first tools simply via learning by doing , experimenting, standardizing good practices and striving for improvement further. The practical applications of Lean, even at its birth place at Toyota, faced serious resistance. It took years of "patience and persistence" for a guru like Taichi Ohno to implement his ideas about pull and flow. Therefore the foundations of Lean; like "Respect for People" and "Continuous Improvement" or technical methods like Kanban, SMED or Jidoka found its way in a natural evolution setting and later became the mold for Lean Culture and TPS.

Agile is the common sense for developing software and also managing projects. It has many techniques (scrum, kanban) and concepts like MVP (minimum viable product) that enable teams to incrementally understand requirements, design solutions and test results . Imagine a software project where you divide the stages like understanding business requirements, analyzing resources, designing and building the solution , test and launch. When you work like this , at each stage you have no / little room for changes which may be required either by a different interpretation of a business requirement, an incorrect solution design that does not really cover the customer need , misunderstandings among teams or simply errors during execution. So this method of development is fragile and time consuming because every time a change is required different teams have to go through the same set of stages causing more variation in the overall result.

The first misunderstanding is the term confusion for an obvious reason that the words are the same. For instance "Kanban" in agile , although originating from the Lean world, means the visualization of tasks and workload around different stages of development for a project run by agile. In this way teams see how they are doing , resource bottlenecks and assess the situation easily. On the contrary, Kanban in Lean is a signal that allows a production action to take place in a setting where physical WIP is controlled via the amount of signals in the system and triggered when the customer or customer process uses the part. Although the base logic is transformed into Agile world in terms of task visualization & control, this same word means quite different concepts in these two worlds.

Another is the concept of flow. Again originating from the lean understanding , in Agile flow focus is to see how things are getting done and understand any situation that blocks the flow of work done to address the remedy. The remedies can range from working in parallel, stop starting and start finishing etc. and is a way to move forward the increments Agile is based on. Flow in lean however defines 7 types of movement in a Value Stream: Flow of raw material, WIP, finished product , operators, machines, information and engineering. Each of these elements identify the Takt-Flow-Rhythm relations of the value stream in question. Traditionally Value Stream Mapping is used to identify issues with the flow.

In production, variation and rework is negative and expensive whereas in a development process this can lead to innovation and good solutions. Since lean management was born with the intention of making production systems more efficient and the Agile methodology was born in the creative and software development environment; although there are similarities the aim differs in application. In the first it is important that processes work in such a way that no waste occurs. This ultimately translates into a final product that is produced as efficiently as possible. In the second situation, instead, the development of prototypes is foreseen, which are first tested and evaluated in order to then develop the final product. Needless to remind, Lean is often applied to improve processes in all organizations. On the other hand, the Agile methodology is applied within a team, often composed of no more than a dozen people.

A term used as to have an agile organization or an agile production simply means to build the necessary framework that enables the unit to respond to changes in the environment, as in market demand, regulations etc. Of course agile logic in itself, due to its incremental nature, inherently is a very adaptive approach to software development and project management. However, it does not mean this method as a whole is what makes organizations agile. So the confusion in the use of the word "agile" can lead to incorrect conclusions.

In a nutshell the discussion of being agile or being lean is an entirely unnecessary waste of time. Both worlds in itself have originated for different reasons, have a great logic and different topics of implementation and neither the similarities in logic nor the extent of the techniques mean that they are alternatives.