Blog by Railsware

Everything You Need to Know about Lean Software Development

lean software development
Lean Software Development (LSD) is a methodology that helps software development teams focus on delivering the values that matter most to customers, while simultaneously removing from the process anything that can waste time and resources.

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

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

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

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

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

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

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

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:

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

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.

Exit mobile version