Software development goes with agile the way Batman goes with Robin. At least 71 percent of US tech companies have incorporated it, and a whopping 86 percent of developers use it in their daily work. As a result, the demand for scrum masters and agile coaches has steadily increased.
Although the expectations for the roles are widely divergent per hiring company, there’s a general understanding that the scrum master and agile coach exist to make sure that scrum processes are maintained.
I disagree. It’s not the processes that matter, but the context and principles behind agile. And those principles aren’t bad!
In this article, I’ll outline how agile is incorrectly interpreted and why the processes are irrelevant if the foundation behind them is lacking.
It feels like only yesterday that the word “agile” indicated some sort of nirvana state that every self-respecting tech company wanted to achieve — or claimed to already have achieved. Scrum was the poster child of agility, and collecting certificates with cool abbreviations seemed to be the simplest way to climb the agile career ladder. You could hardly call yourself a product person without muttering “well-versed in agile methodologies” under your breath.
But those days have ended. If you’re active on LinkedIn, you may have noticed influential product people collectively ganging up against agile.
Agile is the process of breaking down a project into short developmental cycles called sprints. After each iteration, the product team delivers a working product to customers to get feedback and make changes accordingly.
Interpreted and executed correctly, this is hard to argue with. Agile is closely aligned with the principles of lean. The aim is to ship small increments of value quickly, so you can gather feedback and adjust the course if necessary.
When building customer-facing products with low switching costs, you can’t risk spending months before launching a big, heavy product without testing it in the market. No matter how much market research or customer discovery you do upfront, you’re going to need to ship something quickly to see the real-world response and validate your assumptions.
So what went wrong with agile in the past 30 years?
For one, agile became associated with a singular focus on product/dev team collaboration to ship as many features as quickly as possible, without making sure these are the right things to ship. Today, “outcome over output” is a popular credo, which involves prioritizing things that actually move the needle for your customer and feature minimalism, over “mindlessly” churning out features.
Alongside this, when people think of agile, they think of scrum (or even worse: SAFe), and when they think of scrum, they think of inflexible, heavy-handed processes.
Everything comes in waves, and the enthusiasm for agile and scrum had to decline at some point. However, agile and scrum certainly do care about customer outcomes. Frameworks for fast collaboration are created to enable fast shipping in small increments, so you can gather real-life feedback early on and sunset the features that didn’t make an impact.
I’ve come across my fair share of unhappy scrum teams. Their complaints can be categorized in the following buckets:
None of these can be solved by strictly following a process, no matter how great the process. You can try tweaking inefficiencies in scrum team collaboration, create even more space to voice unhappiness, or have another workshop with sticky notes. None of these things will address the root cause.
Most companies that came to me with such symptoms suffered from the same root cause problem: A lack of a clear goal and strategy on the company and product level.
I don’t mean a strategy that is reiterated once per year during the company offsite, but one that’s lived every day.
If it’s not clear who the product is for, what core-value it brings, and how it’s differentiated in the market, it’s difficult to create a coherent strategy. These are tough questions to answer, and they will require continuous effort and iteration from the entire team.
Remember the following three principles:
Without company and/or team-goals (ideally specific, measurable, achievable, relevant, and time-bound), your team isn’t able to work toward anything bigger than themselves. They’re not really a team, but a group of individuals working on stuff. Without a sense of purpose, it will feel like they’re working through a never-ending stack of paperwork.
And in the worst case, If your team isn’t running in the same direction, they’ll be pulling the company apart:
Without a clear overarching goal, you’ll inevitably end up building a bloated product that does a lot of things poorly, but isn’t great at anything in particular. You’ll also create a lot of overhead for your tech teams, maintaining a wealth of systems, components or services that no one truly needs.
You can’t have relevant metrics without a strategy and goals, since metrics are the objective mirror and measure of how you are progressing toward your goals. There are two important sides to this coin:
I’m a big fan of the outcome-driven innovation and Jobs-to-be-Done frameworks, which focus on the customer’s “job” — the thing they’re really trying to do — rather than your solution.
It’s essential to dig deep into the problem-space before diving into solutions, thereby resisting the powerful urge to whip up half-baked solutions. The problem-space becomes the product person’s primary home, but even the developers are asked to participate in building a deep understanding of the target customer’s inner world and the problems they face.
But no matter how much upfront research you do, you never really know how customers will behave under real-world circumstances. That’s where the principles of shipping frequently and quickly, in small increments of “customer value,” start collecting feedback. You might recognize this as…. agile!
Now let’s have a look and see how those unhappy scrum team symptoms can be mapped to solutions involving goals and strategy:
I suspect that there’s a good reason why companies try to address “unhappy scrum team” symptoms with a bandaid, by focusing harder on “agile processes,” rather than digging into the root cause. The latter is much more difficult.
As mentioned earlier, a coherent strategy and goal-setting requires aligning on who the product is for, what core-value it brings, and how it’s differentiated in the market. These are tough questions to answer for most tech companies.
But although it’s hard work, not addressing it will cost you in the long run.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Brian Peterson discusses how he creates empowered teams by establishing a shared vision across teams, organizations, and the company.
Instead of making an entire upfront investment, the pilot project aims to test something on a reduced scale to assess whether it works.
Steve Shah talks about how problem-solution fit is taking the time to put yourself in the buyer’s shoes and understand their life.
A well written PRD is one of the most concrete ways you can crystallize your work and provide value for your team.
Learn more →
