There are a lot of buzzwords thrown around in the business world, but two of the most common terms—”lean manufacturing” and “agile”—are also the most misunderstood. MindTools describes the meanings behind these two words as core to how administrators view their teams. Right now, everybody seems like they want to construct a lean business in pursuit of becoming as agile as possible. Unfortunately, in development, the lean vs. agile relationship really works the other way around.
Getting agile, growing lean
In short, to be “lean” is to be without extraneous parts—without inefficiency or waste. It’s too often assumed the way to become agile is to simply strip away the outer layers of a business, from its expenses to its roster of employees. In reality, the cuts that can transform a bloated business into a lean one need to be holistic, affecting budgeting and organizational processes from the bottom to the top. With that more difficult and worthwhile goal in mind, however, a new problem presents itself: How can you know what to throw away and what to keep?
That’s where agility comes in. Agility is a property of companies that prioritize meaningful personal interactions between employees and customers, which focus on adaptive, reactive decision-making processes that can quickly find even nonlinear solutions to complex problems. The Agile Manifesto, first released more than 15 years ago by a host of respected figures in software development, lays out the ideas behind this paradigm.
As mentioned, many first assume that a business can achieve the goal of becoming agile by going through the austerity process of becoming lean; if we cut away the layers, then we’ll be left with only the most efficient parts remaining. However, without an accurate means of identifying which parts need to go, the quest to become a leaner company can amount to little more than self-amputation of useful limbs.
Who wins out?
In reality, the most effective companies first focus on the type of agile development philosophies that can help them succeed. In this paradigm, the best, most agile strategies will naturally highlight the least agile parts of a company. So, if you implement the agile principle that face-to-face conversation is the most effective way to convey information within a development team, it should become immediately apparent which aspects of your company contribute to that goal and which don’t. By narrowing the definition of the organization’s goals, you can make achieving them far simpler.
Crucially, this does not necessarily mean you’re just constructing a list of people and processes to cut—lean does not equal small and without unnecessary parts. If resources are used in unnecessary, non-agile ways, those resources might be more effective when reinvested elsewhere rather than saved for short-term gains to the bottom line.
Another one of the core principles of agile development is that technical excellence is a key to building the most effective companies—that’s always a good maxim to consider. Also, bear in mind that agile companies can quickly react to changing circumstances, which means they don’t tend to maintain only a bare minimum of resources on hand. While a company might prove leaner with a smaller QA department, it’s not very agile to create flawed development processes that will just end up costing you time and money in the future.
There’s simply no lean vs. agile debate—they’re extensions of the same overall approach to improving your business’s effectiveness. In general, being lean is about eliminating things that don’t have direct value to your company, while agility is all about knowing where that direct value comes from. You can’t achieve one without the other—if you cut without wisdom or add new parts and innovations without restraint, you’ll ultimately miss the benefits of both the lean manufacturing and the agile development paradigms.
In an ever more competitive business world, that’s not a risk many can afford to take.