The idea of eliminating waste from the production process was initially conceived by the car manufacturer Toyota. Anything that didn’t affect the final product’s value and delivery was simply removed from the overall process. 

Not long after, the Lean approach to manufacturing started to be used across a wide range of other trades.  In 2003, the software industry joined those ranks, thanks to Tom and Mary Poppendieck’s book “Implementing Lean Software Development.”

Today, this methodology is used by many software development companies as a new product development process to both quickly deliver new products and features, and improve and optimize existing products and processes.

Lean for software development vs. manufacturing

The main idea behind the Lean approach, both for manufacturing and software development, is the same ‒ holistic optimization aimed at waste reduction and faster product delivery with no loss of product quality – although the implementation of the approach in these two industries is quite different. 

When delivering a specific inventory unit, a manufacturer knows a lot about the future product. The main concept of the final product doesn’t change during the production, and a manufacturer mostly focuses on optimizing the production process.

In the software development world, a developed increment looks like a bunch of invalidated decisions that the team needs to verify on every step of the development.

Key principles of Lean Software Development methodology

The Lean methodology for software development is based on the same seven principles as the Lean development approach used for manufacturing. However, the implementation of these principles, as we mentioned before, will be different. Let’s take a closer look at these principles.

Principle 1. Eliminate waste 

Waste elimination is defined as the removal of anything that fails to add value to your development process and/or the final product. Here are the seven types of waste identified by Lean Software Development:

1. Software defects, or bugs. Bugs waste time. QAs spend time finding and describing them, and then engineers shift their focus to fixing them instead of contributing to more valuable product features. In addition to consuming precious time and resources, bugs can damage your business’ reputation, and therefore hurt your bottom line. For instance, if your website can’t process payments, customers will go to your competitors. This is why the best option is to prevent bugs from being introduced in the first place.
2. Hand-offs. In the development process, like in manufacturing, passing the work from one specialist, team, or department to another causes pauses and delays. For example, when a product manager prepares the scope of a feature, they spend a lot of time thinking through the specification, designs, and edge cases. When they hand this knowledge to engineers, they need to schedule meetings to address any questions to ensure that all the details are clear. The same hand-off process (and delay) happens when a feature goes from development to testing, and so on.
3. Waiting/Delays. This type of waste happens when a development team member encounters an obstacle and needs to wait to be unblocked, meaning they aren’t able to move forward on the highest priority task. Often they can’t complete the task until the design, documentation, or other open item is ready and approved, or a different decision is made; while waiting for a resolution, the team member will focus on another task with lower priority (and value) instead. This issue is closely related to the next type of waste (task switching).
4. Task switching. This waste occurs when developers need to jump from one context to another. This usually happens when there are blockers in the development process, or when one specialist tries to address multiple projects at the same time.
5. Repetitive processing of the same information, or a need to re-learn the same document or data. This happens when a team doesn’t have an effective knowledge-sharing approach and poorly documents its decisions and processes. When a new person joins the team, undocumented processes can be repeated. Repetition is also common during hand-offs. For instance, each time a new feature is ready to be tested, a developer explains to someone from the QA team how to deploy it to the staging server, instead of sharing this information once with the QA team and training them.
6. Extra or unnecessary features. These are features that don’t solve a customer issue, or generally have low priority. Such features should be developed after the tasks with more value and a higher priority, or shouldn’t be developed at all. It’s sometimes easier said than done, especially if an influential stakeholder insists on them. Imagine a high-profile customer wants you to add a special drag & drop gesture that is specific only to tablet devices; she uses the product on a tablet and believes it’s important, but in reality, you only have 0.005% of customers using a tablet, so this feature would go unnoticed and unused by the vast majority of end users. The team must have the courage to de-prioritize this type of request and persuade stakeholders to focus on what brings the most value.
7. Incomplete or partially completed work. There are many examples of this type of waste: unfinished/partially developed but never released features; hours spent in meetings without any actionable steps defined; bugs that are defined and discussed, but never fixed; a completed design for a full-featured module that is only partially implemented – none of these things bring value to the product or the process, and are therefore a waste of resources.

How to eliminate waste

• Do not elaborate detailed plans in advance. Delay planning until the last moment possible. Many details will become obsolete over time, especially when you receive new information about the subject. 
• Plan minimal valuable software increments. Tie these increments to your release plans and then analyze the results. Measure the success of each release and adjust your plans based on the received results.
• Do not plan the ideal system. Design the minimum feature set that will generate revenue and the architecture that is adaptable to future changes.
• Prevent defects from the beginning. Avoid the need to create complex test suites to find any bugs. 
• Allocate dedicated periods to focus on one context only. It’s virtually impossible to be engaged in one and only project or activity, and switching between tasks is inevitable. People need approximately 20 minutes to regain focus after a distraction. To eliminate waste caused by task switching, plan activities in such a way that allows enough time to dive deep into a particular context without distractions. 
• Frequently communicate with other specialists to share knowledge or plan  general activities. For instance, a PdM can scope the feature together with developers or, instead of one big hand-off, do it more often and in smaller portions.
• Avoid extra work that can’t be completed. For example, avoid having meetings that won’t produce any results because nobody is ready to take action yet. Don’t design a huge feature if you suspect you won’t have enough resources to implement everything outlined.

Principle 2. Building in quality

Introducing effective quality management from the beginning of the process ensures that high standards are maintained during the entire development. Gaining constant feedback from your customers helps make certain you meet your client’s quality expectations.  

How to build in quality

• Refactor regularly to keep your code clear and structured. Often, less code is the key to maintaining simplicity and readability. 
• Practice Pair Programming. By writing code together, engineers may employ more effective solutions and create higher-quality code from the start. 
• Consider quality when making decisions. The most expensive bugs are those found later in the development cycle. Minimize the cost by introducing low-level unit tests, then go up in the test pyramid and implement functional tests to assess software increments against the business goals. 
• Automate UI testing. Automated testing is a must for all refactoring as failed tests will immediately warn about the negative impact of the introduced changes.
• Don’t treat code reviews as a quality check. Use a code review process to make sure that the added code follows best practices such as simplicity, correct design patterns, and adaptability.

Principle 3. Create knowledge 

Lean manufacturing allows factories to create a pipeline production where everything is standardized and simplified so that modification and re-learning are rarely needed. 

Unfortunately, you can’t apply this to software development as learning is vital to the process. Engineers need to learn and improve the product every step of the way. Having the right knowledge (both technical and business) helps to make better data-driven decisions.

How to create knowledge

• Learn from each incremental release. Track your key metrics and use data analysis from multiple sources. Don’t be misled by vanity metrics, though; you may have a steady number of sign-ups and feel confident as a result, but is that the whole story? Do those users come back reliably to use your product? Do they buy it? Do you know which features they use? By answering these questions, you’ll get valuable information that allows you to learn and improve the development process. 
• Make knowledge available when it’s needed. If you share information too early, the subject of the knowledge may change; if it’s too late, it’s of no use and will probably be ignored.Imagine it’s the beginning of a project. You conduct research about payment systems, and call a meeting with the development team to discuss integrating the system you chose. A few months later, you know more about the system you’re building, and it appears that the payment system you chose won’t meet your needs after all. It would have been better to wait until your research was complete before beginning development. Or on the other hand, let’s assume that you learned how to embed a billing page into your product, but decided to keep this information to yourself. Later you realize that the team is building a billing page and so you share your knowledge, but at this point it’s not helpful, because they’ve already built one.
• Improve knowledge transfer with effective communication. Use visual representations of information when you communicate something; graphs, mockups, and trend analyses can be very effective communication tools. Present the right level of details, and keep your audience in mind. For instance, managers want to see the big picture, while engineers want to know the technical details.  

Principle 4. Postponing commitment 

You can reduce the cost of change by making decisions at the last minute. Delaying decisions until the last possible moment allows you to collect more data and information so you can make the most informed decisions possible.

How to postpone commitment

• Don’t set decisions in stone – make them reversible. Determine if there are several potential paths forward, and make it possible to switch to another one if needed. 
• Schedule decisions that can’t be reversed for the latest date and time possible. Take your time and gain as much knowledge as possible so you can avoid costly and time-consuming changes. 
• Avoid any designs and code that are tough to modify. By keeping your product flexible, it’s easier to adapt to market needs.
• Choose modular architecture when possible. Modular architecture isn’t as rigid as a monolithic one and can help you make rapid changes.

Here’s an example. Imagine you don’t know where to provide extra customization options for your customers, like choosing date/time format, the first day of the week, and metric/imperial systems. You have some data that shows customers’ demand for this, but the development team says it’s a lot of extra effort. The best option would be not to make the decision right away. Release the app or increment with a minimum of features and then monitor how hot the demand for extra customization is. 

Principle 5. Fast delivery 

When you have an abundance of time and resources, creating a long-term plan is not a problem. You can dedicate time to meetings, create milestones, and set a development pace that allows engineers to build and build. 

In theory, it sounds great. In practice, it too often leads to disaster. Engineers create overly complex pieces of software filled with unnecessary features and a backlog of unfixed bugs. This approach to development doesn’t allow your teams to adapt to rapidly changing requirements and certainly won’t allow you to enter the market with a viable product before your competitors, especially if they employ the lean development process.  

The faster you release your product, the quicker you receive customer feedback for the next iteration. But do not release something just for the sake of speed. If your release doesn’t help you learn and doesn’t solve the customer’s issue, it’s useless. 

How to speed up the delivery process

• Aim to get your increment to a product ready for delivery as soon as possible. Cut corners, deprioritize non-essential work, and avoid perfectionism.
• Encourage engineers to organize themselves around the iteration’s goal, which means that everyone knows what should be done at the end of a sprint and works to fulfill it.
• Use a Kanban board to visualize task planning. Kanban boards are easy to perceive and follow. As a bonus, they allow you to spot bottlenecks that may appear during the development process.
• If you have to create heavy documentation, such as SRS and traceability matrices, write documentation in the format of executable tests. This way, you kill two birds with one stone.
• Minimize the number of items in progress for everyone, focus on completing tasks end to end.
• Keep iterations small and do not plan scope for 100% of the team’s capacity. Leave ~20% extra time.
• Refactor legacy code so that it becomes tolerant to change. At the same time, keep a balance as refactoring can take too long (if not forever). Refactor code to the extent that  it meets the business needs. 
• Employ Continuous Integration and Continuous Delivery approaches. Check on the code regularly to identify issues at the early stages. 

Here’s how it works. Imagine you are improving the first-time setup experience of your product. The setup is a wizard-like feature, and it has many flaws. The correct setup is crucial for your product, and you want to support customers as much as possible.

You designed the whole new experience, which is also a wizard-like feature, but it has a different UI, layout, and set of steps.

Your team implements it screen by screen, and after the first screen is ready, you can release it. But you shouldn’t. This is an example of useless increment. It doesn’t make sense on its own – it’s too interconnected with other steps. The customers would just receive an awful mixed experience, and you won’t learn if you improved something or not.

A better strategy, in this case, would be to release version 1 of the end-to-end experience instead. Start with, for example, redesigning the old wizard. Then rearrange the content of the steps. Then update the layouts. The point is that each release is an independent feature, customers can use it in full, and you can come to a conclusion as to whether you are going in the right direction.

Principle 6. Empower teams

When focusing all the decision power on one position, other team members will have less desire to take responsibility. 

The Lean techniques in software development requires you to empower employees with the freedom to make essential decisions based on their judgment, knowledge, and experience. Such freedom allows the most knowledgeable people in a given domain to make decisions and take responsibility. 

How to empower teams

• Respect every team member. Engineers aren’t just resources to be used when needed and discarded when they’re not. When delegating authority and enabling developers to make decisions, you motivate them as they get a higher purpose that is more meaningful than just a completion of another task. 
• Regularly communicate the goals of the product. Make sure all team members are on the same page to keep the team participants engaged.
• Appreciate learning and self-improvement. Encourage people to share their experience with others, openly express their opinion, and make their own decisions. 

Here’s an example to comprehend the idea. Imagine you know that you need to deliver the first version of the product in two months. You have a pretty clear idea of what scope to include and which feature to cut from the v1. And you have a certain vision of the infrastructural needs to cover and the technical debt to pay.

Do not just ask the team to implement it your way. You may have all the expertise to make the decision on the scope and all the experience needed. But don’t work solo.

Describe the problem, namely the limited time frame and the necessity to have version 1 in 2 months. Make sure that the team understands the problem. Ask their opinion, what they would include and what they would omit. You may go back and forth explaining the business value of some of the features. Make sure you understand why people suggest what they suggest. First, you are very likely to be surprised by the new ideas. Second, you’ll hear more about the risks you may not have considered. Third, now you have an engaged team. If you come to an agreement with them on the version1 scope together, people will be more committed to delivering it because it’s their decision too.

Principle 7. Oppose sub-optimization

When trying to break down each issue into separate parts to fix and optimize, you can cause delays and clashes with the Lean software development ethos. Instead of focusing on pieces of the system, any optimization and decision which takes place should take the whole system into account. 

How to oppose sub-optimization

• Don’t close your eyes to any type of flaws. If something goes wrong, don’t ignore it. Stop the process, analyze it, fix it, and create solutions to avoid repeating the mistakes.
• Simplify before automation. If the process is too complex, its automation will take too much time. What’s more, after automation, such a process would be very hard to alter. So, analyze the process, simplify it to the bare minimum, and only then start automating. 
• Keep the balance between minimum and valuable. Your product should have minimum features to be delivered quickly while also having enough value to meet your business objectives. 

Here’s a vivid example. You improve the UX of the user’s permission table. You believe that if you show permissions hierarchically, this will help. You tried several examples and it looks good. But think of the system in general, is this the only place where the permissions are displayed? What permissions will be added in the near future? Does the hierarchical view still make sense? Often, the ideas that work locally (e.g. at one screen) won’t work if you try to scale them to the whole system so it is important to look for better solutions.

Lean software development is about the process that allows you to make corrections on every step of the development flow. When set up appropriately, it becomes a self-organized and self-correcting process.

Lean software development tools and processes

The Lean software development process identifies five activities that allow you to apply it effectively. Here’s what you need to do:

Identify value

Value is always associated with a customer. These are the benefits that your product offers. Your main benefits will always be a part of your value proposition. For example, the ability to reach a huge segment of international guests is a value that Airbnb provides to its hosts. Once you identify your values, you’ll be able to clearly see potential waste in the work process.

Map the value stream

This is basically analyzing if a feature (or even part of the development process) maps onto some product value or adds useless bloat instead. An example of such bloat are the features in the product you commonly use that you never knew about or those that irritate you, like ordering pizza from a banking app or video calls within IDE. 

Create flow

Flow, in this sense, is a software development process that you use. It should be optimized according to Lean principles. Items (or work in progress) should not be piled up between the stages, and there should not be bottlenecks. Watch your queues, remove obstacles, and aim for continuous flow.

For instance, development shouldn’t be blocked by a lack of design resources. Releases to production shouldn’t be blocked by a lack of quality assurance engineers, etc. The system should be balanced, and the Kanban board helps to identify these issues visualizing the workload at different stages. 

Establish pull

Instead of managers pushing the scope onto the development team, the team picks issues one by one when it’s the right time to do so. Kanban, again, is a perfect tool for that because the issues are prioritized in the backlog and engineers pull them from there. 

Another benefit of the pulling concept is that you don’t implement something in advance “just in case,” but rather address the issues right in time. For instance, you shouldn’t optimize the system’s performance when it’s still too early. Or plan for international customers while you’re still in a local market. Nevertheless, keep in mind that all Lean systems should be easily adaptable once the necessity appears. 

The same principle of pulling the development applies to end customers. Let them pull the features from you. Carefully monitor the demand and the feedback and deliver the benefits they need, instead of creating random features and aggressively marketing them.

Seek perfection

The development process is never perfect, and it should be constantly reviewed and optimized. Analyze it in terms of focusing on value at every stage (less time, resources, better quality, etc.) and tighten the flow. The goal is not to create a perfect process, which is impossible, but rather to always be in a state of continuous improvement.

Now that you know the main tools and processes of the Lean methodology let’s clear up some confusing points.

Is there a difference between Agile and Lean software development?

Lean and Agile principles may seem pretty similar ‒ they focus on customers, work with small iterations, and validate the outcome before proceeding to the next iteration. Yet, the Lean development approach is a part of the Agile methodology, even though the classic Lean approach appeared much earlier than Agile.

The Lean approach is aimed at minimizing risks and wastes while maximizing customer value. Its main focus is on the process rather than the product. Agile, on the other hand, is focused on the product and aims to minimize time to deliver product increments and make the product (and processes to some extent) more adaptable to quick changes. Agile helps to embrace changes seamlessly whenever it’s necessary. 

Advantages and disadvantages of the Lean approach

Before implementing any new development approach, you need to find out all the advantages it can bring and also the limitations it has. Let’s start with the advantages of Lean software development:

• Cost reduction. When removing wasteful activities, your team can save resources such as time, money, and human efforts. What is more, building high-quality products allows you to reduce support and maintenance costs.
• High-value product. The Lean methodology for software development entails focusing all efforts and resources on bringing value to the end customers.
• High-demand product. When the team amplifies constant learning, developers can get feedback early in the development cycle and tailor the product to the needs of the end-users.
• Self-organizing and self-sufficient team. By following the principles of Lean software development, you provide each team member with the ability to make decisions without needing to wait for orders or permission from stakeholders.

Now, it’s time to provide an unbiased review of the limitations and drawbacks of the Lean approach:

• Complex hiring process. The increased autonomy means you need to create experienced teams or at least hire enough experienced members for each team. The hiring process should not only be focused on developers with high expertise but on product-oriented engineers and T-shaped specialists who can contribute to the product development as a whole.
• No decision in advance. It feels safer to make complicated decisions in advance. All stakeholders get engaged in the process, all thoughts are weighted, all decisions are well-considered and made carefully. Often, such a decision-making process is required by company legal processes. Conversely, the Lean approach demands a team to make decisions at the last possible moment (preferably reversible decisions), which leads to hesitation and an uncomfortable pace for many people involved. 
• Restructuring of the company. Yet, this is not a direct drawback of the Lean approach, restructuring is often required as some team members may resist the innovations. To become Lean, all team members should be ready to change their working habits and learn new things. 

How to make the Lean approach work for your company

If you have never used the Lean approach before, it may be challenging to figure out where to begin. We recommend you start with the 5S rule:

1. Sort. Check the codebase and documentation, and define what is unnecessary. In other words, if it’s not being used, it’s useless and can be eliminated. 
2. Systematize. Establish common layouts and structures, crafting a logical project organization that is easy to use and that matches the programming language and your company’s development best practices.
3. Shine. Keep everything around you clean and neat. This concerns your workspace, code, architecture, processes, etc. Avoid mess and letting things pile up.  
4. Standardize. Streamline the recurring activities, whether they are the automatic creation of calendar events, meeting agenda templates or regression testing, etc. Agree on the standards and apply them everywhere (code formatting rules, presentation formats, reports structure, or the framework for a product discovery process)
5. Sustain. Ensure that the culture is adopted and people’s behavior is consistent. Analyze whether there are any obstacles to embrace new cultural norms, and constantly remove them.

Utilize a good decision-making framework

Making smart decisions about what to include or leave out of the development process is central to the LEAN approach. To eliminate waste, you must ensure that all of your ideas have been thoroughly examined and screened before implementation. To empower your team, you must provide them with opportunities to get involved in the idea generation and decision-making process.

The best way to achieve both aims at once is to run a collaboration session. We recommend using BRIDGeS — a decision-making and ideation framework for multi-context analysis — during these sessions. In addition to empowering your team to devise solutions to complex problems, the framework supports proper screening and selection of the chosen solution. This in-depth approach ensures that you only focus on the most essential features and processes from the beginning.

Find out more about the advantages of BRIDGeS and how to run a successful session with your team. And make sure to compare BRIDGeS to other decision-making frameworks we’ve tried and tested, on our blog.

Recap

Organizations that use the lean approach should remember that its main focus is to streamline the software development process by removing activities that don’t bring value.

Non-essential meetings and multi-level requirements for approvals only slow down the process, forcing teams to lose motivation and idle around instead of working towards finishing the current iteration. 

The trick to Lean software development is, of course, building an experienced and competent team that you fully trust. They will need to have much more autonomy than with other development methods for this approach to work, but frameworks like BRIDGeS can help organizations leverage the knowledge and experience of those team members.