Aligning Lean with Design Thinking, Kanban and Scrum (Part I)
Lean and Design Thinking share the common attribute of being user centric philosophies. Although they developed independently they share a number of common features, and even steps in their application. On their part, Kanban and Scrum for software development are applications of Lean, which in turns is a development of Deming’s 14 management principles.
The following is an attempt at creating a lean flow that uses the best of each methodology and that eliminates waste in the design and fabrication process as well as in the product as well.
Although there are other design methodologies in the Lean & Six Sigma world, namely, DSFSS, Quality Function Deployment or House of Quality, Taguchi robust design methodology, TRIZ, etc., design thinking is the design methodology most capable of creating disruptive ideas that move beyond incremental improvement, or architectural improvement. In a sense, Design Thinking provides a reliable methodology for systematizing the creation of a Lean Ideal State.
Lean excels at eliminating waste, and when properly applied, the lean techniques will provide a high level of customer satisfaction and sometimes disruptive ideas (for instance Hybrid cars). However, due to its strong reliance on past data, and on inferential methods, Lean most often than not will provide incremental improvements in a direct correlation to the ability of the Lean practitioner.
Our method, since it attempts to achieve superior results in the creation of products, is an application of Lean Thinking in general, and of Lean methodologies in particular cases.
It may be time for some definitions. When most people think in terms of process, they think in a set of rules, instructions, constrains, etc. The Lean philosophy (not to confuse with Lean methodologies) recognizes that processes exist regardless of the intention of the participants. We all somehow get to work (or get to do work) every morning. A survey may reveal that most users do a series of tasks to go from lying down in bed to be sitting in front of a computer (and hopefully creating some value). If you think back about what you do every morning, you will notice that even the least methodic person will perform a number of actions every single day. That’s the process of waking up and getting to work. Whether you standardize it or not, doesn’t negate the existence of the process.
Although we as designers may be focused on observing, documenting and eliminating waste from the users’ processes, the discussion about process may not always be productive due to the semantic ambiguity of the word process itself. So, there is a word of caution about how to approach the users when discussing process or software design, because when you mention the word process they will be thinking in terms of a laundry list of steps, or a standardized process documented on a process control plan, or some variant of those, but in general, they will be always thinking about something static and unnatural. We, on the other hand, know that process plans are the step of a new process change, as process are an organic artifact created by the collective mind of the organization.
We all create natural processes, and we tend to systematize the things that go well and avoid those that don’t. Process systematization is part of the human nature. Our goal as designers is first to understand the natural processes and to improve the lives of our users by eliminating the things that don’t add value (or that subtract value from their lives or work activities).
It is my belief that unconstrained by societal or organizational constrains any group of people will tend to find natural ways to achieve its goals in the most efficient manner. This is one underlying idea behind the Agile manifesto, when it focuses on individuals and interactions over processes and tools. The Agile manifesto is a powerful aspiration, and it has been a very productive one in creating methodologies (or systematizations of best practices, in other words, processes). This is so because only in rarest of circumstances individuals are empowered to act like such, and interactions are those of equals. In most cases it is necessary to create frameworks, processes, and methods to enable productive work.
It doesn’t mean that the Agile values and principles are not valid, on the contrary, they should be achievable and are perfectly aligned with the Lean principles and value, and Lean can be the philosophy that creates the type of open and trusting organization necessary for successful and productive Agile production.
For practical reasons, during the fabrication phase of our designs we will focus however on two methodologies that intersect both Agile and Lean: Kanban and Scrum.
