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.
Running Too Lean Can be More Harmful than Helpful
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.
What is the Value of Agility?
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.
What Does an Agile Culture Look Like?
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…
Which is better – Kanban or Scrum?
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.