Used properly, Agile is a terrific tool. Breaking large software projects into smaller, actionable pieces provides a great way for IT teams to reduce delivery risk. But when a company is faced with an urgency for change, or a desperate need to get things back on track, its decision-makers can become vulnerable to the myth that Agile adoption can solve everything.
Agile can stop being a helpful tool when the Agile “tail” begins to wag the company, leading decision-makers to veto projects that don’t fit neatly within the organization’s transformed parameters. At best, blind adherence to a framework’s rules will create a stilted bureaucracy that demoralizes team members, one in which meetings and ceremonies are conducted for no greater purpose. At worst, Agile myopia can conceal bigger problems such as a lack of leadership and creative risk-taking.
In the absence of a structured approach to risk management, Agile practices can obfuscate larger, underlying issues such as tech debt, occlude overarching product vision, and lead product teams to focus only on quick wins. In short, nebulous risk management obscures big-picture, creative solutions. In an Agile ecosystem, the biggest risk faced by product leaders hinges on an old truism: Sometimes it’s easy to lose sight of the forest when you focus too much on the trees.
Product managers should foster a tolerance for risk-taking by championing larger initiatives that don’t dovetail with an Agile framework: Advocate for creativity and a clear and bold product vision to preempt the potentially inert bureaucracy that can accrete in a risk-averse environment.
It’s easy and tempting to put Agile on autopilot, only doing what a particular framework says. Striving for something better requires using your own initiative to put in more work, invest more time, and encourage more effort from leadership at every level.
Uprooting Tech Debt: Think Big
One of the first casualties of the Agile veto occurs when larger initiatives like technical debt are ignored. Technical debt is an immense and ongoing project that can’t be solved in a single sprint or handled in one user story. To make matters more difficult, tech debt is a problem nobody really likes to address: It can be difficult to explain the rationale for addressing tech debt to business stakeholders who want to see immediate returns. Developers are often uncomfortable estimating it; after all, identifying technical debt may give the impression that they did their jobs poorly. What’s more, product teams often don’t have a well-suited place for it on their roadmap.
On several projects I’ve worked on—many in e-commerce—core business activities such as payments, order fulfillment, or shipping were saddled with technical debt that prevented the implementation of better solutions. Burdened with a creaky infrastructure, at least two of my clients chose to ignore the problem until the systems failed, causing downtime and lost revenue. Once a system fails, whether it’s a piece of software or a car’s brake pads, the total cost of repair goes up exponentially.
So why does this happen? In part because the desire for a predictable roadmap and smooth Agile process creates a bias toward Agile-suited activities and precludes serious discussions of bigger issues. Letting devotion to Agile determine business objectives, rather than using Agile as a tool to make business objectives run smoothly, has deleterious effects on companies.
Felling the Trees: Creative Destruction
In my experience, companies see creativity as synonymous with risk. Certainly they want the benefits that come from creativity, but doing something new might end in failure. An aggressively risk-averse form of Agile, when allowed to influence business decisions, exacerbates this problem.
For instance, I’ve been confronted several times with subpar e-commerce funnels. Often, these funnels are weighed down with either design debt or technical debt and created for an audience or persona that has changed significantly since the product was first released. In these cases, the proper way forward would be to acknowledge the situation based on the data, and launch a major UX project to research new personas, craft a new approach, and rebuild the funnel—in short, to create an entirely new funnel. Instead, what typically happens is minor tweaks here and there, with a focus on iterative improvements to an existing (extinct) funnel. This comes from the misguided search for efficiency where none can be had, for tasks that neatly fit into a sprint, and for small projects that provide quick wins.
Sometimes small iterations aren’t the right approach to solving a problem. In the software industry, increments work well—until a disruptor comes along. If you find yourself still making incremental changes to a pager when Apple has already opened an iPhone factory next door, you’re focusing so hard on the trees that you’ve lost sight of the forest.
An Agile Risk Management Framework: The Path Forward
The only antidote to anti-risk bias is to cultivate proper leadership that carves out space for creative risk management, using Agile as a tool to minimize unnecessary risk, not eliminate it.
For product managers, our job is to demonstrate leadership at the team level, and support leadership at the organizational level: Work with stakeholders, product teams, and tech teams to make sure they understand and are aligned with the strategies discussed below, which will keep your product team from veering into a culture of total risk aversion.
Keep a Clear Product Vision
Knowing and accepting that risk aversion can emerge in an Agile age is already a huge first step toward preventing it from taking root. The next step is to solve problems caused by a lack of leadership and ownership: A product vision must be guided by someone who nurtures it, defends it, and sells it internally within the organization, pushing back against rigidity and the impulse to water down a bold strategy.
Ideally, the person who owns the product vision should be someone in the C-suite, perhaps a founder, who takes responsibility for keeping the focus on what you’re making and why—not just how. But a product presence at the executive level is still a relatively new development. The next best case is having a vice president or Head of Product who has sufficient autonomy and authority to go against the current. If a ready-made champion of product vision does not exist at your company, you may have to put in some work to cultivate such an ally.
Use performance metrics that make the case for your priorities: A well-defined set of KPIs can incentivize action over inertia. The people you’re trying to win over have busy schedules, so these metrics, much like data visualizations, should be few, simple, concise, and clear to anyone reviewing them in the first 30 seconds. Once you have your ally, the strong performance metrics you have provided will also serve to arm the product leader in their efforts.
Manage Data to Promote Large Initiatives
A good engineering team already understands the dangers of leaving technical debt unaddressed. But when they’re armed only with technical information, their voices can be silenced or minimized by business teams that focus too narrowly on the bottom line.
This is another instance in which having actionable data readily available is vital. The product manager, as someone with a foot in both engineering and business, can serve as a conduit of information, empowering the engineering team to make its case. For example, if a KPI shows the need to improve test coverage over a given critical system, or an OKR proves usability issues have to be resolved within 30 days, these focus the discussion on technical debt. Buffeted by a need to improve these metrics, the engineering team can advocate for a technical debt project with decision-makers. Likewise, naysayers have a much harder time putting such projects on the back burner, a popular tactic for ignoring large but delayable initiatives.
Nurture Creativity in a Risk-averse Environment
Creativity on a team doesn’t just happen, and disruption doesn’t come out of nowhere. Creativity needs to be nurtured and monitored by a senior decision-maker. One way this can happen is on a personal level, by making a deliberate choice to carve out more time for more discussion with a more diverse set of people. I’ve personally had instances where someone from the customer-service team or an intern in operations proposed some truly innovative solutions that surprised both product and tech. But you’ll never hear those ideas if you don’t make the time to have one-on-one conversations—despite your framework’s sometimes rigid timeboxes.
Creativity can also be nurtured at a planning level. Spend the extra time and effort to structure epics with higher-level goals to ensure that people aren’t constrained, even if that creates more testing and delivery challenges later.
Embracing Deliberate Change
There’s never a perfect time for change. In uncertain times, the dangers presented by the risk of failure become more acute, and companies want to stick with what they know. And in times of plenty, institutional momentum weighs against embracing creativity, as risk is perceived to be unnecessary, and companies want to stick with what works—even if it doesn’t actually work all that well.
Sometimes it can take a crisis to tip this balance, as the status quo fails to deliver and the risk of change is overshadowed by the promise of opportunity as a way forward. But you should not wait for a state of desperation to make consequential decisions. Instead, embrace risk as a part of the development process in good times and bad, in order to take advantage of opportunity with focus, resources, and deliberation. A product manager who acts as a champion of risk, and thinks big, can seize the opportunities that come from venturing outside the Agile ecosystem—leading the way on creative efforts and providing a view of the whole forest.