In the final article in our series on lean software development, we explore how these principles apply in an example from an actual project.

Software development can be optimized in many ways. In general, the goal is to increase the efficiency of the time and effort spent throughout the development process. This can be achieved by eliminating waste and optimizing the processes a whole. I will give examples of how lean management principles can be applied in a real project. As an example, I will use the software development process developed and used in Airtrade, a travel technology company. Airtrade has been a client of Algoteque’s since 2016 and has been on the aviation market since 1989. 

There are two development teams in the company. One team is responsible for the backend API, which communicates with external flight search engines and the second team is responsible for the front-end part of the application.

The following description of how to use lean management principles to improve workflow is based on the API Team experiences of which I belong to.

Lean approach helped us improve our work

There are improvements that have been implemented throughout the development process and since the team has grown. It’s difficult to mention all of the changes implemented, but in my opinion, some of which added the most value are: 

Waste elimination

1. The deployment process is fully automated. It starts with the user story with the new functionality/bug description. JIRA is used for the user stories’ state management. After the developer finishes the code, the approval part takes place. Usually, the code needs one acceptation but in more complex stories it can be two. The code review is followed by the acceptance tests when the change has already been deployed to test environments. The next part of the process may be either bouncing the story back to development or moving to integration tests, depending on the test results. The consequence of the acceptance approval is the deployment to the integration environment followed by integration tests. When this is completed the story is being marked as done and the change is being released.
2. Requirement handoffs are usually done verbally. The documentation is prepared in a form which does not always contain all the information. We try to work closely and communicate quite often which keeps the information flow ongoing.
3. We find what could be improved in our next iterations. There is an action list with improvement details and its assignment to a person.
4. The code refactoring is an ongoing process. There is a lot of legacy code which is being replaced with new implementations. The reason for this is because usually new functionalities and the old domain model don’t always meet the requirements. The goal is to:
   – Make the code as simple as possible to be easily understandable
   – Keep the domain model clean without unnecessary redundancies but at the same time flexible, so it can be easily extended.
   – Achieve performance growth where possible
   
5. The meetings are reduced to only those which are really necessary. Knowledge is being passed directly while implementing the story.
6. We try to keep the stories as small as possible to increase our chances of finishing the sprint. In complex functionalities stories are being grouped in epics and released as the epic implementation is finished. In the case of big epics, there is always a fixed group of developers dedicated exclusively to the epic, not involved in any other task (although this is not always possible because of the defects from live or staged environment which have higher priority than the epic) to minimize the work in progress and multitasking.
7. Each new requested feature is always analyzed as to whether it can be implemented and how much effort it requires. There always has to be a good reason behind a user story before it moves into development.

Building knowledge

Developers participate in knowledge sharing sessions that are organized for the team, where we get to discuss anything new is being introduced into the project, like new technologies, tools or internally created libraries.

Quick delivery

Changes are being released every two weeks which results in frequent feedback from the business end. This allows us, the developers, to react quickly to any changes, if necessary.

Quality improvements

Usually, this goes together with code refactoring targeted to meet new requirements but despite that, we want to keep the code up-to-date with new technologies. Last year we significantly increased the API performance, related to caching flight search results and simplified the code which makes it easier to develop.

Future plans

The software creation process is in continuous evolution. There are a lot of areas where improvements could be made. Future possible improvements are:

1. Better unit test coverage

Initially, the definition of done was formulated in a way that made developers responsible for writing unit tests as well as behavior tests for newly created functionalities. 

2. Adding behavior tests

We have very few behavior tests in the project at the moment. The main reason for this is the lack of predictability of the flight search engine. In practice, this is hard to achieve with the test implementations we currently have. The flight search results are requested from external systems of which we do not have access to. The responses can vary between calls and are time-dependent, so there’s no way they can be predicted and automatic result verification is impossible at the moment. We do not have any stubs for the flight search engine and this is a broad area for improvements.

3. Increase team velocity by extending its capacity

It happens that the team’s bottleneck is when it comes to testing capacity, especially when testers are being involved in regression tests of large epics.

4. Optimizing the process as a whole

A value-stream map could be created for our process. Currently, we do not have this type of effort analysis and do not spend much time investigating it.

Improving our work in a controlled and measurable way

In the first part of the series, I described the history of lean management as well as its principles. The second article in the series presented the definition of a value-stream map, which was an introduction to real-life examples in this article. 

Lean principles can be very effective when it comes to software development and the whole creation process from wish list to release. They can be applied selectively depending on the needs, their effectiveness can be measured and a value-stream map can be created in accordance with the measures. This is what makes it such a great method of making improvements in our everyday work, in a controlled and measurable way.