Part one of a three-part series on lean software development. In part one we explore the principles of lean management and how it applies to software development.  

Agile as a standard methodology in software development

Agile methodologies are widely used in small, mid-size and large companies internationally. It was introduced and implemented in the software development industry years ago because of the potential benefits it could bring to everyone in the software development process. Agile itself can be optimized and this is the place where lean management comes into play.

The Origin of Lean Management

Let’s start with the history of lean, which has its roots in the automotive industry process started by Henry Ford. He invented a process called “Flow Production”. Toyota started to adopt Ford’s idea in its assembly lines years later, and based on that, created the Toyota Production System. The concept applied to the manufactured products themselves as well as the whole production process. 

Over the years, lean management has continued to develop and today it’s based on the following principles: 

* Recognize the value desired by the customer

* Analyze the value stream for the product

* Continuous product flow

* Improve the process to optimize the number of steps and the amount of time needed to manufacture a product

Lean management can be used for many different types of businesses, one of which is software development.

We’ve already discussed the main principles that define lean management, and now let’s take a look at how it applies to software development. 

Lean software development principles

1. Eliminate waste

There can be a few major types of waste that lead to the misuse of time and money. This type of waste, in particular, is strongly undesirable for both team members working on the project, as well as the client. 

a) Bugs

Fixing bugs consumes the time of developers and testers that will need to return to the issue again. These can be prevented with good unit tests and behavior tests.

b) Unnecessary features

Unnecessary features do not bring any added value for the customer. The development should be limited to only what’s necessary and therefore valuable.

c) Ineffective handoffs

Passing undocumented requirements verbally, for example, can cause misunderstandings and a loss of important information.

d) Multitasking

When people are spread too thin, there is a much higher chance of losing focus, plus the additional time needed for switching tasks. There is no added value for the customer and it minimizes the work in progress.

e) Overcomplicated change-management process

Too many change approvals can bottleneck in the change-deployment process.

f) Untested code

Code that is untested cannot be deployed, which means that changes can’t be delivered to the customer. This is because there’s no feedback as to whether or not it meets the customers’ expectations.

g) Communication lags

Close collaboration eliminates the time wasted waiting for replies to questions. 

h) Unnecessary meetings

Time spent on meetings should be reduced only to what is truly necessary and to what adds value to the customer.

2. Make decisions as late as possible

Better choices are made when we have greater knowledge. Also, making decisions later in the development process can provide more suitable solutions for potential problems. 

As an example, let’s consider the choice of a database used for persisting the domain model or the framework used as an ORM in the project. This can also lead to reduced time of delivery because team members will only do what is necessary at the moment and shift their decisions over time.

3. Deliver as fast as possible

As an outcome of continuous delivery, a client can have new features being delivered more frequently and therefore give more feedback. This prevents refactorings that are related to requirement changes. Potential inconsistencies with requirements can be found in the early stages of development. Also, from the customer’s perspective, getting a usable product quickly is more profitable for their business.

4. Build knowledge

Building your knowledge base makes everyone an expert in the implemented domain, which significantly reduces the number of questions and answers needed to accomplish the ultimate goal. Also, technical skills can be shared among the team. 

For example, pair programming can be a great way of improving developers’ skills, as well as knowledge sharing sessions and code reviews. 

5. Improve quality

Better code means less effort in future development, less bugs and much happier clients. Improving the quality of code gives clients the ability to have a scalable product, which provides their business with much greater value. 

To achieve quality improvements many techniques are being utilized. Some of these include:

a) Test-driven development

Tests are being written during the development process, which reduces the number of bugs and makes code more compatible with requirements. Also good tests prevent bugs in the future while refactoring the code or adding new functionalities.

b) Pair programming

Pair programming is a great way of sharing knowledge, while also improving the code quality. Better quality means less refactoring in the future as well as less defects.

c) Frequent customer feedback

Consistent and frequent client feedback keeps the code compatible with project requirements. This means that the code being delivered will have fewer defects as a result.

d) Automation

Automation means that developers can spend less time on delivering the solution, and in turn provide more frequent deliveries. 

6. Improving the software creation process as a whole

The optimization of a value-stream is one of the basic lean principles.

The total product-creation time should be reduced as the project is being developed. To achieve this, the whole process has to be mapped to a value-stream and each step in the process has to be analyzed to determine how it can be optimized. As an example, the deployment segment can either be done manually or can be fully automated.

Lean or Agile?

Both lean and agile are being used to improve the quality of digital products. Lean focuses mostly on the elimination of waste and mapping the software creation process steps to value stream mapping for better optimization of the process itself. Agile is about evolving products to meet customer requirements better. These methodologies can go together with very good results. It is important to understand that they are rooted in similar values. They both evolved as they were applied in new industries. 

There is no strict definition of how lean and agile can be combined together but continuous process improvement represented by lean approach and agile development practices can lead to innovative solutions that deliver greater customer value. There is no doubt that it is worth considering how these two can be integrated into one very efficient hybrid methodology.

The differences between lean and agile are described in the second part of this series, where we also provide the definition of value-stream mapping. Part 3 will conclude the series with a real-life example.