What is lean software development and is it underrated?

A while ago in the 20th century, Toyota managed to climb out of serious problems using a special approach to manufacturing. The method involved, among others, defining and ruthlessly cutting away anything that didn’t bring value into the product – as well as empowering the professionals involved. The system gained acceptance, and has been used across industries, until in 2003, Mary Poppendieck published a book called Lean Software Development: An Agile Toolkit, suggesting to apply the same principles to processes in and around programming. Ever since, the notion of lean development circulated across IT side by side with that of Agile. The practical use of these guidelines is said to have yielded impressive results. According to one research, a company achieved a 25% increase in productivity, and time to fix defects reduced by 65-80%. However, you’ll notice that the interest for Lean development practices is not constant; it has its spikes, flashes and explosions – as well as silent periods. Here, we will look at what Lean really is, why it is so mysteriously “underrated” at times and surfaces to the headlines at others.

The Lean practices recognition paradox

If you go and google something like “companies using Agile”, or “[famous company name] Agile”, you’ll be overwhelmed. Apart from dozens of success cases, everyone and their mother claims to use it, no matter what they understand by Agile practices.

With Lean, you’ll most likely get definitions, history… and silence. Although hyped in its own way, lean software development has not produced many brand associations, except maybe that of Spotify. In a more or less typical survey, 33.6% or respondents said they used Agile alone, 21.6% Agile + Lean, and only 2.7% used Lean as the principal development methodology. However, the term is officially surrounded with respect, and the authors of the concept are desired guests at numerous conferences. What gives?

The thing is, the Lean approach is defined not so much by external attributes (like Kanban boards) but by general principles. These are pretty much common sense, although often overlooked. Lean can be formulated as an attempt to bring more sanity into workflows. The most successful companies, being what they are, generally have their own business genius that leads them to similar views – only without them being branded as “lean”. If you search for whether Apple use Lean, the answers will be something like, “well, in a way they do”, because many of their principles sound like lean.

On the other hand, smaller companies often don’t believe lean is practicable. This is because the approach originally comes from manufacturing, and some of its precepts had to be forcibly “translated” into the realities of software world.

The why here is extremely important, and to address it, let’s have a look at the “classic” lean software development principles and try to digest them one by one.

The 7 principles of lean in practice

The authentic vision of lean software development is wrapped in these so-called 7 lean principles – and almost two dozen “tools” to accompany them. You’ll notice that some of these are obviously borrowed from lean manufacturing – but applied to software development, they are all the more interesting, especially when you consider how they allow to reduce cost of development.

Minimize waste

This comes from the original concept at Toyota, and “waste”, or muda in Japanese, is defined as anything in the process that does not bring the value to the product being created. That meeting that resulted in nothing? Waste. That time the development team had to wait for the task to reach them? Waste. Lean urges the executive to scrutinize the entire workflow and see what actions have been really necessary – cutting off anything else in the future.

While in physical production waste typically includes unnecessary transportation and storage, in IT things get more interesting. Here is the software industry’s version of types of muda:

1. Unnecessary code/functionality
2. Too many features envisioned too early
3. Delays in software development process
4. Unclear requirements
5. Managerial bureaucracy
6. Slow/ineffective communication
7. Partially done work
8. Work done using inadequately advanced tools

You can see that “unnecessary code” figures high on the list. This has sparkled confusion – for example, with prototypes, at which point do they start being waste, rather than useful “feedback collector bins”? This is individual for each project. However, writing the wrong product is obviously muda, so of course, early feedback is a must.

In classic Lean, the executive uses a method called Value Stream Mapping (VSM) to compare the actual process with the stripped-down, ideal one using conventional symbols and drawings. There is no “standard” way of doing this in the software industry, but some feel that ticketing systems and DevOps may solve the same task.

There is also the very curious point of overmanagement and ineffective communication. When there are delays along that chain, this leads to extra work. It was once calculated that when a bug is detected and reported after three weeks, it takes the developer 24 times as long to fix it as if it were addressed straight away. Also, ineffective communication tends to feed on itself, and resultless meetings produce more of their kind. If you take the average $42 per hour paid to a project manager alone, this can be dangerous. Of course, managers themselves are learning hard to ask the right questions and distribute the right tasks at the right time – but Lean lays even more pressure on them to do so.

Amplify learning

Exactly what it sounds – and suddenly of more importance to IT than to manufacturing. We all like it for a reason when senior developers transfer knowledge to team members, for example. In essence, the very process of software development is learning, especially when you work incrementally and iteratively (i.e. nearly always). Lean presupposes reinforcing this learning – and organizations have come up with a number of ways to do so. These include:

• Less documentation and more feedback to learn from
• Pair programming
• Code reviews
• Use of OSS (open-source software) to stimulate best practices
• Commented code // with a “fine art” of writing meaningful comments
• Meetings for knowledge transfer
• Tools to manage requirements or user stories

The usefulness of these is not disputed. To name just one example, code reviews have once allowed a 14% increase in team productivity – and accounted for 90% less bugs.

Decide ALAP

Yes, you read that right, ALAP for As Late As Possible. Also called “defer commitment”, this actually means sidestepping the familiar danger of waterfall model: deciding the features early on, providing extensive documentation and specs, to find out later this was not what was needed – or requires rework. Letting the MVP stay flexible and adjustable for as long as possible is important – provided that the requirements that do exist already are clear.

Deliver ASAP

This is commonly understood as at least two things. First, the minimum viable product that allows the customer a bird’s-eye view of the system to be built. Second, shorter iterations that allow the team to move forward smartly, without performing too much work “in the dark” – i.e., without immediate feedback. The 2-week sprints practiced in Scrum actually embody this principle, allowing to deliver fast.

Build Quality In (or is it, “Build Integrity In”?)

The basic idea is, low quality is actually more expensive than high quality, so making everything hi-fi from the very start is definitely not a “waste” of time. In software development, this principle is achieved with test-driven development (tests before code), an emphasis on refactoring and integration testing, as well as automation and constant mining for customer’s feedback.

This very point is sometimes called “build integrity in” in the community, implying integrity is the chief aspect of software quality. Managing the code base is vital here.

Optimize the whole

The most widely understood principle. It generally refers to the different levels of processes in the organization, with the precept of WYMIWYG (what you measure is what you get). At the same time, having only “local” metrics (e.g. for individual processes and team members) is recognized as ineffective – with the term of “suboptimization” applied. No customer is interested in how many seconds it takes a developer to write a line of code; every customer is interested in getting what they want and fast.

Wait, isn’t that Agile?

It is only natural to note remarkable similarities between the tools and practices of Lean, on the one hand, and Agile, on the other. For example, shorter iterations are desirable regardless if you follow this or that approach; pair programming is many an organization favorite hobby horse… Some people who learn about Lean practices ask themselves: “wait, I have heard something like that in the Agile community”.

Thing is, the two approaches are not entirely different – but definitely not the same. At the core of Lean is the clear straight path from MVP to the final deliverable – without any “waste”. The soul of Agile is flexibility and quick reaction. Sometimes these two visions coincide, sometimes they contradict. For example, we have seen that prototypes are in the grey zone between “waste” and “necessary non-value added” and “value”, according to Lean.

Both approaches solve their own clusters of problems that intersect like in a Venn diagram. Perhaps this is the answer to why more organizations use something in between Lean and Agile, depending on the project at hand, than just Lean. In some successful cases, executives outsource parts of development processes to teams they know to deliver faster than in-house teams do, while themselves focusing on their own Lean or Agile culture.

Implementing lean… worth it?

Lean is not underrated, but rather under-hyped – which doesn’t mean you should not attempt to try it at home. Observing the principles of Lean without fanaticism is what an uninitiated observed would simply call “good business sense”. Consider this checklist to see where to move to get closer to Lean:

1. You have something like VSM and can name at least 3 muda in your current organization
2. Average team member does not have to spend more than an hour daily at meetings
3. The teams are aware of what the customer really wants
4. Feedback comes in less than 1.5 days
5. Iterations are sufficiently short to be safe
6. You know your MVP provides the customer with overall experience
7. Documentation is not overprioritized
8. Team members can track their own progress on tasks and knowledge acquisition
9. There is no waiting gap between development and testing; regression testing feedback can be answered immediately
10. Refactoring is not victim to “higher priorities”

None of these are without benefits, are they? Giving lean practices a try is totally worth it – even if you don’t start saying “we use Lean practices” instead of “we are agile”, this will still bring pragmatic benefits in both short term and the long run.