In the series “Back to Front” our consultant Eoghain looks at the latest developments, releases and news in technologies from (you guessed it) the Back-end to the Front.  In the latest installment, Eoghain talks us through lean principles. 

Agile Methodologies: Lean

Part 1: Lean principles

In this blog, I’d like to continue to look at development methodologies that fall under the umbrella of Agile. Over the last few weeks I’ve examined Mob programming and TDD and now I want to look at a much broader methodology that was brought in to software development from the Japanese manufacturing sector (specifically Toyota).

Lean as a methodology is multifaceted with a primary focus on efficiency. It breaks down into a number of principles:

  • Eliminate waste
  • Amplify learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole


The first principle “Eliminate waste” is pretty self explanatory on the surface, but the key here is identifying areas of waste. In this context, waste can be defined as anything that doesn’t bring value to the customer or end user and this comes in a number of forms.

  • Partially done work – which is abandoned in development due to being irrelevant or obsolete due to changes in the spec
  • Extra processes – keeping things as simple as possible reduces workload, speeds up development process
  • Extra features – by examining exactly what the project needs and ignoring features that aren’t necessary, you can create a highly functional project that is free of bloat
  • Task switching – by keeping your team working on specific tasks and avoiding changing their tasks frequently, you create an environment where everyone knows what their role is. This reduces any learning curve to a minimum and speeds up the development process
  • Waiting – this follows on from task switching; if everyone knows what their tasks are you can eliminate the need for other teams to complete their tasks in order for your team to proceed with their work, less waiting means delivering as fast as possible
  • Motion – Minimising the amount of travel needed to complete projects such as management travelling between locations where teams are based would reduce time and cost
  • Defects – By keeping things simple and particularly by implementing TDD and clean code standards, you reduce the overall risk of bugs, this ultimately increases the efficiency of development by reducing time spent on correcting issues and tracking down bugs
  • Management activities – Awareness that over management or micromanagement of teams can often create backlogs, tension on the team, increase workload and slow down progress. Management’s role is to define the project and guide, to keep things on track. Essentially a focus on the overall outcome rather than each individual team’s contribution

The second principle “Amplify learning”, works extremely well in terms of software development since learning is a constant necessity. New iterations of languages and frameworks are constantly evolving, as are best practices. In the context of Lean, learning can be thought of as not just the accumulation of skills but also the development process itself. As iterations of code progress, errors or ways of streamlining the code base emerge and this should be shared amongst teams so that the same roadblocks and bottlenecks are avoided.

The third principle is “Decide as late as possible”; this would seem counterintuitive at first glance but essentially this should also be considered to be making sure you have the details hammered out. Essentially the project should be fully defined and designed and ready for coding to begin. Changes should be avoided and a focus on only what is absolutely necessary for the core functionality of the project should be adhered to. Deciding as late as possible also gives you the ability to make final decisions based purely on solid information and facts, rather than assumptions about customer requirements. The more complex a project, the more this principle applies.

The fourth principle, “Deliver as fast as possible” is very straight forward. In terms of technology in general, the pace of change is rapid and to keep relevant, software products often need to drive ahead with new technologies and features that define the market. The faster you can create new iterations incorporating the features most needed by the customer the more likely your software will be adopted. I like to think of this as the quick and the dead, if you don’t respond quickly your project might as well be dead.

One of the most vital (in my mind) principles of Lean is “Empower the team”; this principle relates to overall management dynamics and has the emphasis on trusting people to do their jobs rather than micromanaging. The manager becomes an active listener, using information gleaned to find ways to facilitate the development process, helping team members to overcome issues they have been facing either by leveraging their own experience or through others who may have experienced similar issues. I like to think of this as defining the manager’s role as that of a leader rather than as a boss (i.e. that they direct the team via participation rather than telling them what to do).

The sixth principle “Build integrity in” essentially amounts to aspects we have seen in Test Driven Development before, i.e. that the entire product is functional as a whole, that individual components function well together, balancing flexibility, maintainability, responsiveness and efficiency is the key here. Another aspect of this principle is that there is constant and clear communication between the developers and the customer at every stage of the process (This lends itself well to other Agile methodologies such as Scrum where the customer is one of the key stakeholders and is actively involved in the process). Excellent user experience is also a consideration for the customer to perceive the integrity of the product; user adoption simply won’t happen if the experience is clunky and unintuitive.

The final principle is to “See the whole”, this is perhaps the most difficult principle to apply, especially on a large software project that is spread across teams. Each and every team must be 100% aware of how their modules will interact and work as part of the whole finished product, errors must be prevented by tackling the root causes early in the process, constant communication is necessary through every stage of the process. In this particular case other Agile methodologies such as Scrum are very beneficial for keeping teams appraised of progress and focussed on progressing at the right pace, while also addressing issues as they emerge.

In my next blog, I will look at the practical side of Lean, how the principles are applied and the techniques that lead to success.

If you have any input on this topic, would like to get in contact about future topics or would like to discuss open roles drop me a line at or connect with me on LinkedIn Check out my previous articles here