Constantly decreasing costs, no waste, minimum throughput time, maximum capacity, unlimited flexibility, and high customer satisfaction. Sounds too good to be true?
But that’s what lean is all about.
What is “lean”?
Being able to progressively create “insanely great” products, as Steve Jobs would put it, and especially at the lowest possible cost – who wouldn’t want that!? In fact, in today’s business context, efficiency and speed in creating the products that the customers want have become a matter of life and death for any organization. To survive, companies need a solid process for innovation. This is when lean practices come in handy.
If you haven’t been living under a rock for the last ten years, you’ve definitely heard about lean. Simply put, it is a product development philosophy or mindset that revolves around cutting out all of the unnecessary work or effort until you’re absolutely sure what you need to do for your customers.
The story behind lean
“Lean” started in the manufacturing world, and was originally developed by Toyota in the 1950s. At this time, Japanese industry was recovering from the ravages of World War II, and all companies faced a serious crisis. In order to survive, the Toyota Motor Company devised new methods for meeting market demands and maintaining production. This heralded the start of the Toyota Production System, centred on the concepts of customer value and waste reduction.
As the effect was dramatic, the rest of the world could hardly ignore this development, and wanted to know the secret of their remarkable turnaround. This led to different research aimed at cracking the code of Toyota’s success. The approach became well-known in the 1990s when many books were released explaining why the Japanese were beating the U.S. in so many industries. They also brought forth the concept of Lean Production and its capstone formula:
- Identify value for the end customer. The cornerstone of lean production is value. And when it comes to being Lean, value is defined by the customer. Just do not get fooled determining value from the customers’ standpoint, as it is all about their actions, not their words. You can have an excellent and well-executed mission, but if no one pays for your product or service, then its value remains unproven.
- Map the Value Stream. Once you know what the customers value in your product, you can create a map to identify steps without added value, and eliminate them whenever possible.
- Create flow. The production value-creating process must be designed in a way that it flows continuously and smoothly.
- Establish the pull. As flow is introduced, ensure that nothing is made before there is a customer demand for it. To put it differently, customers should pull the work through the system.
- Seek perfection through repetition. The next step is a continuous improvement towards achieving perfection. Begin the process again and continue it until a product with value is created with minimum waste. The truth is that absolute perfection is an unattainable goal, but the optimization should always continue.
The Principles of Lean
Fortunately, lean thinking is no longer limited to the manufacturing industry. It also serves other industries well, including construction, healthcare, and high-tech; Even personal life can benefit.
In 2003 Mary and Tom Poppendieck brought Lean into the software development world. In their book “Lean Software Development”, an Agile Toolkit famously applied all Lean values, practices, and principles to the software industry.
They also identified seven Lean principles to follow when developing code:
1) Eliminate waste. As the goal of Lean is to deliver value quickly and sustainably, it’s not surprising that the first principle of Lean is to eliminate waste. Waste is defined as any part of the product development process that does not add value. However, not all waste is created equal.
There are two different types of waste, necessary and unnecessary. Necessary waste is made up of activities that don’t directly create value but support the process – for example, daily team meetings. If you face difficulty deciding whether some waste is necessary or not, ask yourself, will the value still be created if you discard the activity in question?
There are at least seven typical types of waste found in software development:
- Defects. Each time a defect is found, it creates failure demand, i.e. the work you have to do now because something wasn’t done properly in the past. For example, most work-facing support teams can be classified as failure demand. This can include failure to create appropriate user documentation, or failure to properly code a feature.
- Handoffs. There is always a level of tacit or implied knowledge that exists, as it’s impossible to capture every decision or every little piece of information that might be needed. It was estimated that each time you hand off a piece of work to someone else, as much as 50% of that tacit knowledge is lost. Excessive handoffs can sabotage the way workflows through the process, creating delays, relearning, task switching, and other waste.
- Delay. Actually, delays can be caused by many different factors. For example, if the organization has functional work structures, work must pass through multiple teams in order to be completed, which may lead to setbacks in decision-making or delays in approvals.
- Task switching. Every time you put one task aside to start another, you lose time to refocus and switch the context. This is particularly acute for complex tasks. Without even realizing it, stopping and returning to tasks will lead to a lot of interruptions and excessive work.
- Relearning. If chaos prevails in your documentation, you can’t recall what was already learned, or expertise is available to you via your colleagues but you don’t make use of it, you’ll experience relearning. Unlike learning, relearning decreases your capability to deliver quickly or sustainably.
- Extra features. If the customer doesn’t need a feature, it’s a waste. Creating extra features leads to an unnecessarily complex codebase that’s difficult to maintain and build upon. This buildup is one of the reasons big businesses often deliver more slowly than startups.
- Partially done work. This includes unused designs, specifications, unverified code, tests, shelved work, etc. This usually occurs when you plan too early, multitask or change priorities frequently.
2) Build quality into the product. Quality is at the heart of lean. Instead of relying solely on sound testing after the work has been completed, lean teams take steps to prevent defects from occurring in the first place; prevention is better than cure. In software development techniques, the teams are used to build quality into the project, including test-driven development, automated testing, continuous integration, refactoring, and error-proofing.
3) Amplify learning. You amplify learning by short cycles of delivering working code that is tested and elicits feedback continuously. Lean software development teams experiment and learn through any outcome, challenge the status quo, and fine-tune the team’s ability to respond to unexpected situations. Tools like Kata, set-based design, and A3 help master these capabilities.
4) Defer commitment. To avoid costly payoffs of premature decisions, commit as late as possible. Allow yourself a learning curve to ensure that decisions are only made when there’s enough information to make a good decision. This is not a new, sophisticated method of procrastination, neither being reactive or passive. In the Lean context, it is quite the opposite. Whether committing to what architectural choice to make or which framework to choose, keep your options open as long as possible; this will give you the most flexibility for making the best choices over time. In its essence, an iterative approach allows you to do just that. It is also important to make forward-looking, change-tolerant designs that will allow you to go back when needed and make necessary changes. Approaching development with a mindset that embraces change instead of fears will set you on the right path to be able to recover from what would otherwise be a costly mistake.
5) Deliver fast. To be more precise, deliver as quickly as it is feasible. Fast delivery shouldn’t become something you have to sacrifice quality or cost to provide. Lean teams reduce the number of things they do at one time, so they can focus and finish them faster. They also spend time and effort working on reducing the number of work items in queues, especially those they’ve already started. These actions have a significant impact on delivery speed.
6) Respect people. Respect for people means respecting both the customer (e.g. by making the software product easy to acquire and use) and employees (e.g. providing the right level of autonomy to teams so that they can use their expertise to build the product in the best possible way).
7) Optimize the whole. Optimizing the whole means focusing on improving the whole product development process, all the way from the initial concept to delivery and beyond, to maintenance and operation. However, it also means looking at your software as a product and ensuring that it is complete and meets the needs of the customer.
These seven principles should work in concert to allow Lean software development teams to achieve the goal of quick and sustainable delivery of value to customers.
Why use Lean
The Lean strategy focuses on two very important business aspects: competitors and customers.
First, competitors become more challenging every day; an organization can’t stand still while everyone else is moving forward. It is do-or-die to continuously improve to meet and beat that competition.
Second, customers become more demanding every day. Everyone seems to want more features at less cost. Lean helps to meet demanding customers’ needs, while remaining on time and cost-competitive.
When to use lean
Most modern researchers agree that it is better to use Agile methodologies including Lean in evolving software development projects built by in-house teams. This also suits smaller and less complex development projects. The small team size allows Lean teams to remain quite effective and flexible, but unable to write large amounts of code over a short period of time.
Lean is, unfortunately, not the best solution for outsourcing, as it doesn’t always allow teams to be in direct contact with clients. This usually causes miscommunications and delays. In addition, Lean requires frequent feedback from end-users. Besides, not every client can provide a high level of trust to the outsourcing team.
What is NOT Lean product development
Despite being the zeitgeist, there are still many surprising misconceptions connected with Lean and its application. As a result, companies fail to produce great results because even though they may declare being lean, their behaviour is, in fact, anti-lean. Often encountered fallacies are:
1) Lean is not a tool. Although it may include many tools, Lean itself is not a tool. It is not a quick fix; you cannot just shout from the rooftops that you are a Lean company, when there is no payback in terms of increased employee morale, increased productivity, or increased customer satisfaction and quality. Lean is a total strategy, a way of thinking. It should be a corporate approach to integrate Lean practices throughout the organisation. A true Lean transformation must start at the very top of the company as a mindset for every employee.
2) Lean is all about reduction. Reduced costs and/or waste are a benefit, but never part of the initial focus – the value is the focus. Yes, Lean helps to find inefficiencies in your processes, and find better ways to do things so that they require less effort, less time and fewer resources. But it is important not to get carried away, as this may lead to the flip side of healthy reduction: penny-pinching, cutting investment, and layoffs.
Cost reductions made on the backs of staff layoffs and overwork may create the illusion of a short-term gain, but it actually hurts the ability to deliver sustainable value. Plus, respect for people is a key principle of Lean. So, if you hear about any so-called Lean programs that seem to care about the bottom line without caring for the people, don’t be fooled; that’s simply not Lean. Lean is not a head-count reduction system; true Lean companies don’t want employees to work harder, or faster; they only want employees to work more efficiently.
As for waste, firstly, reducing it to 0% is probably an unrealistic and impossible goal. Secondly, putting too much emphasis on reducing waste would mean superimposing a level of control and standardization on projects. So, any reductions should not occur in silos, but across all constituents.
3) Lean is rigid. People are often concerned that Lean efforts, including standardized work, will turn them into unthinking robots. But Lean is not about mindless conformity. On the contrary, it creates a baseline for mental freedom, as it reduces energy spent on routines, and enables empowerment to think about how the process could run better. A true Lean culture respects people, makes them accountable and engages them in continuous improvement.
In fact, Lean has never offered the perfect process guide. They don’t call it a “lean journey” without reason. Lean is a process search, where everyone finds their own ways. You have to start with what you have, and slowly, iteratively improve it. One of the reasons why only a few companies have been able to reproduce Toyota’s results is because they simply copy without actually building a culture of learning and experimentation. So, one of the steps to embark on a lean journey is to understand that there is no top-to-bottom example that will perfectly fit your environment, you need to find it yourself.
Risks
From the above, it is clear that Lean development offers a lot of benefits, and without a doubt can be called the most cost-effective model. Nevertheless, Lean is not a magic pill and has its drawbacks. Many researchers claim that most problems of Lean are related to its Agile nature. Here are a few examples:
- Team qualification. Lean projects are heavily dependent on the excellence of team members and their individual commitments. Lean presupposes fewer roles when compared with traditional software development methodologies like Waterfall. It means there is no one to back up if a mistake occurs. Also, profound knowledge is required because on-demand training may put the project at risk.
- Team discipline. Lean projects are flexible, with minimal restrictions and instructions. Without discipline, too much flexibility may lead to loss of focus on the initial objective, and inexperienced developers may turn the project into chaos. So for a Lean team, it is nice to have someone, ideally a skilled business analyst, who will back up the developers’ decisions with diligent process monitoring and ensure full understanding of the requirements.
Also, Lean development requires absolutely precise documentation. Otherwise, any poorly documented piece may be implemented incorrectly. - Strong customer relationship. In Lean, many factors depend on the customers’ preferences, which may cause problems. Customers may impose unrealistic requirements or change their demands often. To prevent such situations, the developers have to communicate their abilities to the customer prior to the project start.
Still, there are some other risks such as stakeholder opposition to the fast-delivery approach, teams resistant to changes, a lack of desire for continuous improvement, or simply an inability of individuals to take on responsibility.
But the highest risk is connected with incorrect Lean implementation, though the decision to implement it is already a great success. However, just because the team members can quote all Lean principles by rote doesn’t mean they change their behaviour and act Lean! You’ve probably witnessed people who pass a learning course but a few weeks later, there’s no evidence of that knowledge. This is because during learning, no real involvement happened. Benjamin Franklin famously put it, “Tell me and I forget, teach me and I may remember, involve me and I learn.” Charles Fred in Breakaway said, “Deliver value to your customers — fast beliefs. There is a minimum threshold of experience necessary for new behaviours to become a habit!”
He also suggests four phases of learning that need to be experienced to turn knowledge into a habit:
1) Introduction – the first acquaintance with the topic
2) Assimilation – deeper dive into the topic
3) Translation – practical application to the specific job
4) Accumulation of Experience – doing the job repeatedly until it becomes a habit
Unfortunately, many companies do not go further than step two, or best-case scenario, to step three. But without the right coaching and enabling learners in the new behaviour, a habit will not be formed and may affect the project.
Lean tools for product development
A3’s, Build-Measure-Learn, Constraints, Fast Feedback, Kanban, Lean Six Sigma, OODA, PDCA, Value Stream Maps, and many other buzzwords that title Lean tools.
Despite the variety of names, all of them rely on key Lean principles and consider the Japanese method of ‘‘Kaizen’‘ (or ‘continuous improvement’): applying small, daily changes that result in major improvements over time. Kaizen is all about baby steps, perhaps slow but gradual and consistent, that bring dramatic results in the future. Another huge hidden benefit of Kaizen is that it is about empowering people, about everybody’s ownership, engagement in the process and taking responsibility.
The tools also vary in their level of complexity, ranging from very simple (e.g. Check Sheets) to very sophisticated (e.g. Six Sigma); but the choice of tools is always situational. Some Lean tools suit one business more than another. To choose a tool, one needs to understand what is the problem or challenge they are trying to solve, and then use the right techniques at the right point. For instance, for trouble with workflow and eliminating waste, it is rational to use value-stream mapping. It is also OK to change the tool throughout the Lean product development process.
Here are short descriptions of some of them:
- Kanban – a highly visual system that can help determine what’s contributing to slow delivery speeds by limiting tasks that are being completed simultaneously. Whatever process you have, Kanban encourages optimization of the flow by putting limits on work in progress.
- A3 – a structured way to learn about a dilemma and explore options for improving the situation. The result is an A3-sized, one-page deep dive into a problem. The genius is that the restriction of size forces conciseness, providing a deeper level of understanding.
- Value stream mapping – a method of visualization of the development cycle as a whole. It allows you to create a detailed visualization of all steps in your work, to understand the current state and design for the future. Value-stream mapping can be used to improve any process with recurring steps – especially those with multiple handoffs. The idea is to map, on one page, the flow of product through the process. This helps to identify every step that does not add value, and then eliminate them. Value-stream mapping is often referred to as re-engineering.
- PDCA (Plan-Do-Check-Act) – a Lean product development framework for solving problems and managing change. It enables businesses to develop hypotheses about what needs to change, test these hypotheses in a continuous feedback loop, and gain valuable learning and knowledge from the results. It implies testing changes on a small scale, and only then implementing updates company-wide.
How Railsware utilizes other tools in Lean product development
The Lean development methodology is one of our core approaches here at Railsware. Over the years, it has helped us build a culture of continuous improvement and develop a series of successful products. However, we haven’t just relied on Lean tools to succeed. Instead of Lean Canvas, we use BRIDGeS, an ideation and decision-making framework crafted by Railsware.
With BRIDGeS, we are able to dive deeper into the product context than other Lean tools typically allow. At the very least, BRIDGeS does away with the need to use several tools at once to achieve one single aim: developing a viable product idea or solution. We have applied this approach to every one of our own products and have seen great results.
Find out more about how BRIDGeS works and what it looks like in practice with our Uber Case Study.
Wrapping Up
The lean methodology is also known for the introduction of different product management tools like Lean Canvas*. Both in the Japanese Toyota plant and in the field of software product development, where speed-to-market is the ultimate competitive advantage, the Lean process leads, to outstanding results. The process drives a culture of continuous improvement and its tools help to streamline your processes and reduce costs, common goals of every successful organization. Other tools like BRIDGeS — which have been built with the Lean philosophy in mind — can help you explore the value and viability of your product from the outset. Winston Churchill said, “To improve is to change; to be perfect is to change often.” For a continuously improving organization, these are certainly words to live by.
* Lean Canvas was designed by Ash Maurya, based on the Business Model Canvas designed by Alex Osterwalder, Strategyzer.com, licensed under CC BY SA 3.0.