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.