How Enterprises Misinterpret Agile Principles and Rush to Do Too Much
The agile methodology isn't just about doing more in less time. Instead, focus on doing less to achieve more.
- By Andrea Fryrear
- August 31, 2020
When you ask for a definition of agile, chances are you'll hear about speed, efficiency, and productivity. It's fair to expect all those things from an agile system. However, there's a little-known agile principle that holds the real key to achieving all of that. It goes like this: "Simplicity -- maximizing the amount of work not done -- is essential."
Yes, you read that right. There's a line in the Agile Manifesto that tells us to do less. More explicitly, it calls on agile practitioners to increase the amount of work they choose not to do. This may seem counterintuitive for a system that touts its ability to increase a team's output 300 percent, but this increased output isn't a product of speed but of focus.
When we focus on less, we paradoxically achieve more.
This is a core tenet of agility that enterprises gloss over all too often, racing instead to push their agile teams to do too much and endangering the success of their agile efforts in the process.
Conflating Efficiency and Effectiveness
At the core of this "race to more" attitude is a confusion between output and outcomes. Said another way, we get caught up in the amount of work we do without worrying about whether it was the right work in the first place.
We can spend 50 hours a week churning out a ton of output, but it might never achieve our desired outcomes. If we write 20 new blog posts but have no system in place to drive traffic to those pages, we've created lots of output that's unlikely to provide good outcomes, regardless of how awesome those posts might be.
One of my favorite examples of the focus on outcomes over outputs comes from CoSchedule, a SaaS product designed to help marketers manage their work. As I share in my recent book Mastering Marketing Agility, the CoSchedule team is all about finding projects that are likely to deliver 10x returns on their time. They aren't concerned with work that might provide a 10 percent return.
In their search for 10x projects, they deliberately choose not to do certain things, including going back and correcting errors in published content.
As an English major, this practice initially appalled me, but if you've ever run a large, content-heavy web presence you can see why this attitude is actually a major productivity gain. Correcting an error on a page requires you to log into the content management system, find the page, search through an article (which, in CoSchedule's case, is likely over 3,000 words long), find the error, make the change, publish the page, and double-check to make sure you didn't break anything in the process.
It's not like it's going to take all afternoon, but the time spent on this kind of task isn't being spent on something that could exponentially increase the outcomes for the team. This isn't just hypothetical, either. CoSchedule has earned 434 percent more page views, 1,222 percent more email subscribers, and 9,360 percent more marketing-qualified leads in the years since they began taking this kind of approach.
It's not about the volume of work you do. You could go fix 100 grammatical errors in your posts this week and feel very productive. It's about the outcomes your activities produce. To get the most bang for your buck, you have to eliminate non-value-adding activities from your to-do list.
Finding the Work Worth Doing
This begs the question of how to find that work. What we have to remember is that the Pareto principle tells us that 80 percent of the value from our marketing work comes from 20 percent of the activities that we do. Our goal as agile marketers is to find out what that 20 percent is and get it done as quickly as possible.
There are two ways we can do this: one is through the use of a ruthlessly prioritized backlog, the other is by regularly releasing minimum viable projects (MVPs).
Agile teams use their backlog, a prioritized to-do list, to drive their work. Work items that make it to the top of the list get done right away. Items that are lower priority aren't going to be tackled yet.
This ensures that a small number of high-value items are being processed by the team and that they're given permission to completely ignore everything else. Their leaders apply their strategic organizational knowledge to put work at the top of the queue that's going to deliver value to both the business and their audience, and the team puts their heads down and gets it done.
Release Early, Iterate Often
The second agile tool that helps us do the right work at the right time is the idea of MVP. Traditionally this stands for minimum viable product, but because in marketing we aren't usually creating a product, we can revise it to stand for minimum viable project. You can even adjust it to MVC -- minimum viable campaign. Whatever you call it, the concept is the same: release early and often.
When we plan our work, we do so at the moment of maximum ignorance. We pull together deadlines and requirements and key performance indicators before we've done any work at all. Then, historically, we go off and work in isolation for 6-8 months, then present a fully baked campaign. The best-case scenario is that we get instant signoff from our internal stakeholders and can go to market right away. Worst case is we get all kinds of change requests and spend another month (or more) making adjustments.
Only after dozens of weeks and countless hours have been poured into the project or campaign do we put it in front of our audience. More times than we'd like to admit, it falls totally flat. In the worst cases, it blows up in our face.
Instead, we need to find the minimally viable piece of that campaign and get it in front of a real audience as fast as possible. In this way we test the messaging, the visuals, and the call to action and find out much more quickly whether this is a 10x project or a 10 percent time waster.
To be clear, MVP doesn't mean off-brand, low-quality schlock. The V stands for viable -- it's not something we're ashamed to show. It's just not a massive investment with no opportunity for improvement and iteration.
Do Less to Achieve More
Doing more is not a sign of real effectiveness, and it shouldn't be the goal of business agility. Instead we should consider efficiency and productivity as byproducts of the ability to focus on high-value work until it's done.
Until enterprises understand that agile isn't just about doing more in less time, they won't enjoy the greatest benefits that agile ways of working have to offer.