There’s more to being Agile than just blindly following the rules and processes of any specific methodology. One of the core components of effective Agile practice is internalizing the concept of continuous improvement. As I’ve touched on in other articles, Agile is a direct descendant of the concepts originating in the lean manufacturing movements of the late 1940s and early 1950s. And the single most important part of this ancestry is the focus on empowering and entrusting the people who do the work with setting their own destiny and with challenging each other to improve their practices on a regular basis.
Most companies out there put a huge push on efficiency and running “lean” — doing the most possible with the least amount of overhead. And in most cases, that’s a very noble goal — after all, overhead in the form of people and positions is generally the highest cost that companies face. Reducing the number of people needed to achieve the same goals allows the revenue side of the equation to exceed the costs — which is almost every company’s end goal, to achieve a sustainable business model that makes money for the owners of the business. The problem with this is that it’s often taken too far — the drive to be “lean” winds up causing more headaches and issues than it creates an environment conducive to success. This issue isn’t only of concern to Product Managers, it affects every part of the business, from sales to marketing to support to development. And because of that, we’re often in a unique position to see they dysfunctions that trying to drive too lean causes throughout the company. It’s up to us to be aware of the risks and raise them as we start to see red flags, before they damage the ability of the organization as a whole to compete in an increasingly competitive marketplace.
One of the many challenges that Product Managers face in trying to move organizations toward a more agile approach to product development is that some stakeholders simply don’t see the value in the shift. They believe that, since their way has worked for them for so long that there’s no need to change — after all, it can’t be broken if it works, right? But the simple fact is, the bad old ways of product development are dying, as markets and customers move faster and have more options available to them to solve their problems every single day. There’s not a single industry that isn’t facing high-investment newcomers who are able to move fast and adjust — and leave they’re slow-moving, waterfall-based competition in the dust.
A common question posed to Product Managers in organizations interested in or transitioning into Agile is, “How do we know that we’re Agile?” Because agility is a cultural value, there’s no pre-determined checklist of things that one can step through and certify your company as 100% Organic Agile. There are, however, indicators that we look at to determine whether or not the company, a team, or even an individual, is thinking and acting in an Agile way. Here are a few key indicators that you can use to weigh your assessment of how agile you, your team, or your company are…
A very common topic of discussion amongst Product Managers in general, and Agile practitioners in particular, involves the comparison of different forms of process and project management. By far the most prominent and popular of these are Kanban and Scrum. And, much to my own personal dismay, often these discussions wind up devolving into some form of “religious war” between fanatical fundamentalists on either side — insisting simply and without substance that their way is the best way.
The simple fact is that one is not necessarily better than the other — when, how, and where you use either of these approaches depends greatly on what problems you’re trying to solve, what kind of culture you have or want to have, and how the people you have doing the actual work want to manage themselves. To say, in broad strokes, that either Kanban or Scrum is objectively “better” than the other misses the point entirely. Both are equally good and equally bad, depending on the circumstances.
With Agile development and Lean practices so popular nowadays, sometimes the history behind these practices and philosophies is overlooked or skipped over entirely. Unfortunately, when people miss the underpinnings upon which these concepts are based, they also tend to distort and remake those principles into something that only barely resembles the original concepts behind them.
Most of what we consider to be modern “Agile” and “Lean” approaches to product design, development, and implementation all stem from a variety of manufacturing principles that coalesced into the Toyota Production System in the late 1940s. This process was a vast departure from the Western approach to production lines — the interchangeable parts an always-moving production line, in which people were just another cog in the wheel. Rather, the TPS system focused on several principles designed to implement systemic processes to allow people to provide feedback into the work being done and how it might be improved. The development of these principles, and their application in the “Toyota” way slowly built between the 40s into the 70s, where it became more broadly adopted under the guise of “just-in-time manufacturing.”
Many books have been written on the TPS process (with all apologies to Office Space fans), and I would encourage people interested in the history to do some research — but for this article I wanted to focus on what the TPS system views as “waste” and how each is specifically defined, because when we talk about Agile and Lean trying to eliminate “waste”, we probably really mean one of these three things:
- Muda = “Waste” or failures of people or processes to efficiently deliver product.
- Mura = “Unevenness”, or failures related to unpredictable or inconsistent outputs.
- Muri = “Overburden”, or failures of standardization to create efficient process.