Unless you’ve been out of the picture for the last ten years or so, you’ve probably heard of terms like lean, agile, and scum in reference to software product development. In fact, because of the frenzy of blogging these buzzwords flooded the InfoSpace to the extent that they seem to become an eyesore.

No wonder, as speed-to-market is now the core competitive advantage for any organisation. To survive, companies need to be utmostly efficient in terms of resources allocation, waste elimination and value creation. This is where Lean proves useful.

Lean is a vision-driven philosophy for building products faster with less waste. It improves traditional product development processes by eliminating the communication silos and creating the culture of continuous improvements within the organisation. In its turn, it leads to empowering people and bigger effectiveness.

Many companies still centre their strategy around capacity, but its optimization leads only to keeping everything and everyone busy. This means that you can’t deal with emergencies when they crop up and taking too many shortcuts will result in failure in the long term. Besides, staying busy doesn’t equal delivering value, chalk and cheese, in fact.

As for Lean, it focuses on flow optimization. And improving flow means resetting your beliefs about what’s important. It is about the courage and common sense to drop the in-progress tasks when necessary for the sake of starting a new, value-creating activity.

Emergence and adoption of Lean

Both Lean and Agile emerged in software development in response to the shortcomings of existing plan-driven methods like Waterfall.

But unlike Agile, Lean derived from the manufacturing world, more precisely from Toyota Production System, back in the 1950s. At that time Japan was trying to restore after the second world war and to survive Toyota company worked out an approach to managing work, which centred around value creation and waste elimination. Later it was coined as Lean manufacturing, promoted and described by western authors who researched the reason why Japan automotive industry was outperforming the US.

In software development, Lean was brought by Mary and Tom Poppendieck, who in 2003 in their book Lean Software Development, an Agile Toolkit, formulated and described Lean values and practices, and later also laid out seven key principles:

  1. Eliminate waste. Value is at the heart of Lean. Waste is anything that doesn’t help to create it. But waste can also be useful, it is called the necessary waste. Useful, in the meaning that it contributes to process support, though is not value-added. For example, some process formalities, a team must go through. Unnecessary waste is something you need to eliminate immediately when detected.

Most common unnecessary wastes in software development are:

And that’s just to name a few.

  1. Build quality in. Quality assurance focus is not on reporting and fixing bugs but on preventing defects from occurring. TDD, continuous integration, refactoring - these and other techniques are used by Lean teams to ensure the best possible quality is delivered to the customer.
  2. Create knowledge. Software development in its essence is knowledge-creating headway. But Lean software development teams keep learning all the time and all the way around. Iterative way of work helps them reflect on the written code and incorporate lessons-learnt at the next iterations. To ensure that learning is amplified Lean teams often use paired programming, code reviews, wiki, project documentation, sharing sessions, cross-team applicable metrics and more.
  3. Delay commitment. Well, this sounds counterintuitive, as the business-like approach presupposes fast decision-making. But this Lean principle is not about procrastination, it is more the addition to the previous principle, as keeping the option open for a longer time gives you more time to learn and gain knowledge for even better decisions.
  4. Deliver fast. Making big complex plans way ahead of time and creating monolithic systems packed with unnecessary features proved to be a non-working for modern software development. As they are change-intolerant, read lethal for ever-changing business context. Lean offers an absolutely different model of MVP (minimum viable product), which states: build quickly, include little functionality and launch a product to the market as fast as you can, then, study the reaction. Such approach allows to ditch all non-value added activities and build software fast, as decisions are based on the feedback from real-world customers. Of course, fast delivery is a great competitive advantage, but speed should never be gained at the expense of quality.
  5. Respect people. People, in this case, are both the customers and the development team. Respect to customers is revealed through the creation of user-friendly software and immediate reaction to their feedback. With the team, it is important to truly empower the people, rather than control them, lead by example, create a favourable working environment for everyone.
  6. Optimize the whole value stream. It is important to optimize the whole development cycle, not just sub-processes. In this case, sub- would mean under- and can lead to product failure.

Why lean development is beneficial for software

Lean principles allow us to enjoy many benefits. For software product development, one cannot overemphasize, the importance of:

What is anti-lean

Although Lean is a buzzword and there are tons of information about its practices, tools and its overall implementation, many companies fail and act actually anti-lean. This mainly happens because of the following mistakes:

  1. Treating Lean as a tool. PDCA, A3’s, Kanban, Lean Six Sigma, etc. Yes, Lean has many tools for all intents and purposes. But treating it as a product development tool means not correctly understanding its nature and not using its potential fully. It is a philosophy, a strategy that should be applied and preached all over the organisation, and only such attitude and implementation can lead to product development success with Lean.
  2. Lack of Kaizen mindset. Kaizen, Japanese for ‘continuous improvement’, is an inherent part of Lean. It refers to small, daily activities (yes, not grandiose or drastic) that will result in major improvements over time. It also presupposes having all employees participating and making suggestions to improve the business. These are the key strengths of Kaizen and the main risks to Lean, at the same time.

    Because, firstly, it is hard to get happy and motivated with small, sometimes practically invisible results. We usually want it all and now. But the art of baby steps, the ability to get satisfied with intermediary results and derive pleasure from them for future motivation is something that can pay off a hundredfold in the long run. And secondly, Kaizen should be a part of company culture, not just efforts or practices of teams or, worse, certain individuals. That is not just going to work this way.

  3. Concentrating on cost/head reduction. Eliminating waste, including financial and human, is the front-page task of Lean. But it’s a huge mistake to make it a goal and turn Lean from efficiency, value-based philosophy to cost- and head-cutting system. Savings is cherry on top, but never the target.
  4. Expecting business-ready models. With reference to companies that are applying Lean for their software development, a term ‘embark on a Lean journey’ is used. And it’s for a reason. Firstly, Lean is a way, not a destination, an alive system, not a crystalised solution. All lean principles, to be followed, point at the need for open thinking. One simply can’t make the right choices, learn and deliver fast, if they sink in formalized routine and recklessly apply prescriptions.

    Secondly, ‘to embark on’ means ‘to start’ and indicates the constant search of your way of doing things. In fact, Lean has never offered rigid guidelines. As practice shows, only adaptation to your unique business context, a constant search for optimal process arrangement, and iterative refining can result in a successful journey.

Lean is complex and simple at the same time. But building a product in a lean way just means what it sounds like - trimming the fat, not allocating resources before it’s been proven reasonable, not building an entire app before validating the need for it, building fewer features, getting feedback on them, and then developing the rest with that in mind. In essence, don’t overcommit before you validate and validate as frequently as possible. As simple as that. But the complexity lies in the fact that there is no A-to-Z recipe of successful Lean implementation. So be ready to find your way and let it Lean!

data-width="" data-numposts="5">