I’ve talked before about the dangers of a “cargo cult” mentality when it comes to Agile practices, but in this instance I’m going to take a Devil’s Advocate position, at least it will appear that way. All too often, people and companies start their Agile transitions with training about the “theory” of Agile — what it means, how it should work, what glorious and wonderful benefits are, and to attempt to indoctrinate people into concepts that may be entirely foreign to them and how they’ve done their work in the past. The problem is, nobody really cares about theory — and all too often the theoretical underpinnings are lost as soon as people get back to their desk and start their next day of work. Here, however, I’m going to propose a plan to implement Agile practices without the theory, and without creating a “cargo cult” mentality where you’re just going through the motions without understanding why…
For the second installment of my “10 Questions With…” I reached out to one of my mentors in the PM/Consulting space, Rich Mironov. I met Rich many years ago at ProductCamp Seattle, where he was giving a presentation about the struggles and challenges of the role that really spoke deeply to me and where I was in my career. Over the years, when he’s passed through town I’ve tried to maintain a connection, bouncing ideas off of him and mining his depths of experience for pearls of wisdom to help me grow as a Product Manager. I’m happy to present his 10 questions here, and for those of you who don’t know him, here’s a quick bio:
Rich is a 30-year product management veteran based in San Francisco. He’s an unrepentant blogger at www.mironov.com, author of The Art of Product Management, and coach/consultant to product management teams and startup executives. On occasion, he parachutes into software companies as interim VP Products. He thinks a lot about the strategic and organizational challenges of running product management teams.
Everyone in tech has seen the word, repeated ad nauseum as the “silver bullet” for everything from go-to-market timing to quality to product discovery. But like many terms bandied about by those both within and on the periphery of Product Management, the term “iteration” often comes with connotations or meanings attached to it that aren’t really quite right — almost to the point where the word itself begins to lose its meaning and becomes a “cargo cult” phrase without any real “there” there. In this post, I want to explore what I think are five common myths about iteration that if busted will let us renew the meaning of the word and make it something worthwhile in our profession.
Many people are aware of the famous quote from Peter Drucker, “What gets measured, gets managed.” But what people don’t often consider is that what’s being measured and managed might actually not matter at all at the end of the day. When we measure things that don’t actually drive us to improve, we’re just acting like a cargo cult — going through the motions and expecting something magical to happen that never will. Instead of just picking some popular or standard metric, we should instead make sure that we understand what direction our measurements are going to give us, and what change they’re going to drive in our behavior or in our products. Only by being thoughtful and deliberate in our choices will we find the right metrics to use and rely on in our choices.
Here are a few things to watch out for and to take into account when considering what metrics we want to put into place…
For a term that’s so well-established in our profession and so widely used, it always surprises me when people abuse and misuse the concept of Minimum Viable Product (or “MVP”). It seems like such a fundamentally simple and clear concept, but often in practice it gets all wrapped up around the axles of internal struggles, until it no longer bears any resemblance to the basics of the concept itself. And when we abuse such a basic concept, bending it to our own purposes rather than using it for the purpose it was conceived for, we wind up watering down the meaning of the term and missing the entire point of engaging in the process of defining and building that MVP in the first place. We create MVPs to confirm a set of hypotheses, to ensure that the problems we’re trying to solve are real and valuable, and to make sure that the technology behind the solution functions as expected. At least, that’s the theory…here are some common missteps that Product Managers make that change their efforts from an actual MVP into something else.
There seems to be a lot of discussion these days about whether or not Agile still works, and whether or not Scrum in particular is “dead” or at the very least dying. The common thread that I see in these discussions is usually something to the effect of “why do we need set iterations” or “user stories suck as requirements documents” or comments in a similar vein about some fundamental part of the Scrum methodology. But, what many of these people forget — on both sides of the coin — is that if we are to truly embrace Scrum as an Agile methodology, it requires us to focus on one measure of success — actual, demonstrable results.
If you’ve been on the job market in the past several years, you’ve undoubtedly come across the phrase “bias toward action” in one or more job descriptions or company overviews, or even during a call with a recruiter. It’s become something of a buzzword, and in the way that many buzzwords do, has a meaninglessness to it that often causes us to shrug it off as just another “thing that ‘they’ say”. The problem is that having an “bias toward action” can also be code for “completely unstructured” or “constant fire drills”, so rather than shrug it off we should dig deeper to uncover the real meaning behind the term for that particular organization.