This is the fourth (and possibly final!) installment of my series of posts discussing why Agile may not be working for you or your organization. Part One focused on the role of culture and training; Part Two focused on the importance of continual improvement and evangelism; and Part Three focused on lack of knowledge, lack of commitment, and lack of demonstrable progress as contributing factors. In this installment, we’re going to talk about what you can do when you encounter situations where Agile (or “agile”) approaches aren’t working — small things that you can do to influence and support the transition of your teams, organization, and culture.
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.
There comes a time in every Product Manager’s life when they face adversity and challenges above and beyond the day-to-day administrivia that we struggle with every day. And it’s in these moments, at these times, that we find out what we really believe in, and what we’re really willing to do to stand our ground and push through the barriers before us. This is especially true in organizations going through a transition period — whether it’s growth, changes in ownership or management, or even shifting patterns from front-loaded development practices toward more agile approaches to product development. And it’s not only our values that come to the front when these things happen — it’s the organization’s values that stand out — often in stark contrast to the espoused positions that sound good when things are going smoothly.
What is it that drives these vast differences in behavior, and what can we do to bring the two closer together, especially in times of struggle?
Many companies struggle with the challenges of reconciling the need for strategic planning and the desire to execute in an “agile” or Agile fashion. Generally speaking, this is because they’re stuck with the perspective that a “roadmap” must be a set of promises regarding what’s to be delivered, and not merely a strategy that will and must change over time. Being “agile” requires that we accept the unknowns in the world — and what’s more unknown than what the market is going to look like in 2 years? Therein lies the folly in trying to perform traditional roadmap planning and expecting to be able to be “agile” in your execution. But, there are some easy ways to change your perspective on roadmaps and maintain the balance between strategy and execution.
The single most powerful tool that Product Managers have to make products that amaze and delight their users is to figure out what problems their customers have that they don’t even realize are causing them pain. Most people didn’t understand the benefits of 1,000 songs in their pocket when Apple first introduced the iPod back in the day, but MP3 players have now merged with our cell-phones and morphed into online streaming services to provide an ever-present library of whatever music strikes our fancy at the time. Sure, they weren’t the first, nor were they the fanciest, but Jobs and Co. tapped into something important — the latent need for us to have our music with us, wherever we were, in a package small enough to slip into our pocket.
There’s a lot of truth to be found in the classic mis-attributed (and possibly entirely fabricated) “Henry Ford” quote, “If I’d asked people what they’d wanted, they’d have said a faster horse.” People know what their obvious pains are, what the problems are that they experience every day — but most people only examine those pains at a very superficial layer. Someone who tells you they want a better way to manage the password on their work computer, for example, might never consider how much simpler it could be to simply add a biometric fingerprint scanner to their desk that would save them both time and effort. Customers focus on their current pain, and want that solved immediately — and they’re satisfied when you do so for them. But they’re amazed when you discover a problem that they didn’t even know they had, and deliver that solution from the word “go”.
It’s the difference between evolution and revolution, between iteration and innovation.
It seems that lately Agile (and Scrum in particular) have become the latest targets of non-stop complaints and criticism in the Product Management and Development worlds. I’ve read articles that talk about how “Agile is destroying the business” or where “Scrum is a career-limiting methodology that only creates generalists.” Neither of these are necessary conclusions from the data provided, nor are they necessarily a reflection of weaknesses of the Agile principles or of a specific methodology — more often than not, they’re a reflection of a certain culture or work environment that itself is fighting against the fundamental tenets of Agile and Scrum.
If you’re one of those people for whom either Agile or Scrum doesn’t seem to be working, here are some hard questions to ask yourself and your organization — “The fault…is not in our stars. It is ourselves…”
In the world today, it’s no longer efficient or effective for a Product Manager in any company to devote months of time, effort, and expense in designing and developing new products or new product features. The market moves faster than that, and even in traditionally slower markets like B2B customers are increasingly exposed to the world of apps and SaaS solutions — which sets expectations for how technology as a whole works. These expectations bleed into the workplace, and workers who previously simply accepted technology as part of the drudgery of their jobs are increasingly vocal about solutions that no longer meet their needs. Combining those expectations with an open market where initial costs to launch products are constantly decreasing through the use of cloud solutions and free open-source technologies, and any company or Product Manager who sits on their laurels and continues to work in a business-as-usual world will find themselves significantly challenged as the market and their users change around them.
Fortunately, there are many approaches that even an old-school Product Manager can adopt to increase their throughput on validating new ideas, testing new solutions, and generally ensuring that they’re being proactive in their market approach and not simply reactive to the changes happening around them. The key component of any such approach is to accept uncertainty, and to test your ideas, problems, and solutions as quickly, cheaply, and often as possible — with the understanding that many of these ideas might fail. However, without testing new ideas, you’ll either invest too much time, money, and effort into the wrong things…or you’ll never bring those challenging and inventive ideas to market, since you’ll never have the data to convince those who are unsure of the direction you wish to pursue.
Thus, your focus should be on failing fast, failing cheap, and failing often.