It might be nice to begin with the observation that Agile, while born in the software development world, was nonetheless preceded by insights in manufacturing. Originating from process innovations at the Toyota Motor company in the 50s, today Lean is considered the (or at least a) ‘mother’ of Agile.
After its success in the manufacturing world, the Lean methodology was then adapted to what’s known as ‘Lean for IT’ – and the Agile manifesto followed partially from that concept in 2001. The Agile way of working differs from Lean approaches by introducing a preference for team-level autonomy and short feedback loops, but it also pays healthy tribute to Lean’s continuous improvement, its just-in-time production concept and its focus on eliminating waste.
While Agile approaches were initially wholly software-oriented, Lean-Agile ideas hold real promise regardless of whether you’re developing a product or a piece of code. Eliminating bureaucracy, increasing adaptiveness, and focusing on customer value are values that all carry over to different areas and with developments such as Scrum, modular architecture and eXtreme manufacturing, we’re seeing teams outside of software development adopting Agile ideas.
The home-grown Gladwell course Agile for Hardware was entirely developed with this development in mind.
When it comes to scaling either Agile or Lean – or leveraging the strengths of both simultaneously, such as with the Scaled Agile Framework – you face a lot of the same challenges. Neither methodology is ‘easier’ than the other.
Scaling up any kind of organizational change is inherently difficult: getting to understand the system, redesigning value streams and trying to spread the change all the way from work floor to management is never an easy task. While Lean has a more solid foundation for scaling up, Agile is constantly trying to improve, change and experiment with the way things are being done… it’s starting to shake these existing structures.