One of the common challenges that Product Managers have in advocating for more agile product definition and development practices is a rather ironic one — those in power and authority often feel that iteration “doesn’t work” because they feel that once something is “done” it won’t ever be revisited. The irony here is that it’s the very people with the direct authority to make sure that things are revisited and revised who make this objection. And it comes from a very true place — in traditional product approaches, you built something and then moved on. And in a randomized environment without a coherent strategy, it’s often the case that iterations do in fact never get revisited.
This, however, is not a failure of the process but rather of the surrounding business culture and the people who hold positions of power, authority, and influence. Overcoming this objection is one of the major achievements that a Product Manager can have in moving from traditional, waterfall-oriented product approaches and toward a customer-centric, agile approach.
Understanding the Objection
When dealing with an objection like this, we first have to assess where the objection comes from. If someone is stating an objection, they are either basing it on a subjective assessment of the situation, or an objective assessment. Both of these may be valid or invalid, but neither of them should be approached without doing a little bit of research — put your user-centered design cap hat on, and place yourself in the position of the person making the objection!
Chances are, whether it’s a subjective or an objective assessment, it’s based on past experience and an inability or unwillingness to comprehend a future in which things come out differently than they have before. This is a common bias that’s surprisingly difficult to challenge directly, so instead we have to try to suss out where it’s coming from and what angles of weakness such a belief may have.
The source of the objection is going to have a massive impact on how to best approach it and defuse it. If it’s a bad experience with a previous team or with current teams who tried and failed, that’s going to require a lot more finesse and detailed work than if it’s some bad outcome that happened five years ago at a different company on a different product with a different team.
The Elephant in the Room — Lack of Understanding
Ultimately, though, it’s highly likely to be the case that the fundamental, root cause of any objection to iterative development is actually a lack of understanding of how it works. Unsurprisingly, the vast majority of organizations that I’ve worked with who were transitioning to agile practices focused almost solely on training the development teams on the day-to-day processes of whatever methodology they’ve chosen (usually Scrum). They tend to completely ignore the other effects that agile practices have on the organization as a whole (as I discussed here), and fail miserably at informing upper-level management how it’s going to change what they do and how they do it.
Thus, without any concept of what iterations mean, how they really work, or what the overall benefits are — is it any wonder that upper management is hesitant to see the value in “small pieces” of work over large efforts that they view as having greater ROI? It’s a fundamental change in how projects are rationalized, how they’re understood, and — most importantly — how they’re focused on the customer over anything else.
Skeletons in the Closet — Lack of Clear Vision & Strategy
The other major cause of frustration or objection to an iterative approach is the (often-unspoken) understanding that the company doesn’t actually have a clear vision of the product or its market strategy. This often winds up causing immediate discomfort when iterative development begins in such an organization, as the first iteration that meets a customer need gets shipped, then something else becomes more important — the lack of strategy causes the very behavior that the management team is concerned about, even though it’s something almost entirely within their own power to control.
This eventually develops into a self-fulfilling prophecy, where management feels like they can’t create a product strategy because priorities are constantly shifting — which they blame on the iterative approach itself. The fact that things are done in such small efforts, in such a compartmentalized fashion, leads (in their opinion) to constant randomization, “to keep the teams busy” — or some other similar justification.
Getting Change to Happen — Proof and Strategy
Now that we’ve called out the elephant in the room and pulled those big, dusty skeletons out of the closet, what the hell do we do with them? Simple — we create a strategy and we demonstrate success in achieving it through iterative work. Now, this requires that you find some project that’s not hugely high-profile, and that will require several iterations to work through. Then, you document and deliver a vision statement for that effort, covering the full amount of work that’s going to be done. You make it clear how the process is working, what you learn each iteration that you didn’t know before, and ultimately push through to completion. When you do this, it’s almost guaranteed that you’ll have a compelling story to tell about what you did, how you did it, and — most importantly — that it worked. You then apply the same approach to a slightly larger project — getting more people involved in your process and your success, and ramp it up from there. Taking such a grassroots approach is nearly guaranteed to work — even if the objections and the beliefs persist in the minds of the management team, the success that you’ve demonstrated, and the community you’ve built around it makes a more agile approach nearly unstoppable.
