Skip to main content

February 1, 2021

6 Common Agile Product Development Mistakes (and How to Avoid Them)

If your product team has gone agile, you’re in good company.

Product giants like Apple, Microsoft, and IBM are using agile product development to achieve greater speed, adaptability, and user value. It’s not just the big wigs, either: A whopping 95% of organizations have adopted agile in at least some of their teams, according to KnowledgeHut’s 2020 State of Agile Report.

But agile is easier said than done. According to that same report, 84% of agile teams “acknowledge that their organizations are below a high level of competencies.” Most teams struggle with issues like stakeholder resistance, inconsistent practices, and spillover from legacy methods.

Let’s be clear: Agile is a great method for the modern product team. But just because it’s popular doesn’t mean it’s easy. Making agile work takes a surprising amount of structure and commitment.

1. Too many cooks in the kitchen

Agile teams shouldn’t be an army; they should be a hyperfocused task force.

In agile, you have to keep teams small. Small teams allow you to easily align the entire squad on each and every sprint. And because agile product development is all about making steady, incremental updates rather than huge product overhauls, the horsepower of a huge team isn’t necessary.

If you try agile with a too-large team, two things tends to happen: First, your team becomes inefficient. The more people you add, the more difficult it becomes to ensure everyone’s duties match their bandwidth and abilities. Second, when you notice that things have become inefficient, you implement processes in an attempt to keep everyone organized and aligned. But adding processes is distinctly unagile. It adds barriers between developers and the real priority: building customer value.

How to avoid it? Stick to Jeff Bezos’ two pizzas rule: If you can’t feed your agile team with two pizzas, it’s too large (that works out to between five and nine people, depending on appetite). If you have more employees than that, don’t stick all of them on the same agile team. Create multiple teams, each with a narrow scope.

2. Relying on assumptions about the customer

The single most important aspect of agile is delivering frequent value to the customer. If you fall back on outdated assumptions about your users, you risk misunderstanding what’s really most valuable to them and delivering the wrong things. To deliver deep value, you need equally deep understanding.

The first principle of agile reads, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Delivering value to users means solving their problems, improving their processes, and helping them accomplish their goals as quickly and easily as possible.

To deliver deep value, you need equally deep understanding.

Too many product teams make the mistake of operating based on assumptions and outdated knowledge about their users. It’s not enough to design for user personas and discuss changes in terms of user stories. If you’re serious about continuously delivering customer value, you have to be just as serious about deeply understanding your user’s problems, processes, and goals.

How to avoid it? Conduct user research. The best way to understand your users is to regularly observe and speak to them firsthand — and it’s not as hard as most PMs think. And since agile is incremental and fast-moving, staying up to date is key. Consider continuous research, a low-effort method that helps you gain user insights in real time.

3. Lack of documentation and knowledge sharing

In agile product development, quick and informal is the name of the game. But don’t be fooled: You still need to share knowledge and document in order to stay resilient and plugged into the organization at large.

You may have heard about the “just enough” mentality when it comes to documentation in agile. It encourages agile teams to cut down on the excessive documentation of their legacy method in order to focus on the actual task at hand: building and delivering valuable software. As Jim Highsmith, one of the originators of agile, says, “We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.”

But there’s a fine line between “just enough” and “not enough,” and many agile teams fall on the wrong side. Documentation is important; it helps you loop in key stakeholders who can’t attend your daily stand-ups. It also helps you stay connected to business teams (like sales and customer support) that possess valuable customer knowledge. And unless you record and share institutional knowledge, nearly half (42%) of it is siloed in individual employees. That’s a big loss when team members walk out the door.

How to avoid it? Establish a single source of truth. This should be a universally accessible resource that is regularly updated with key data and knowledge. It will help unify the entire organization, ensure all decisions are based on the same set of data, and protect your team’s knowledge as people come and go.

4. Poor communication within development teams

Within agile teams, swift, flexible communication is key. But that isn’t always easy, especially during the COVID-19 pandemic.

If you’re going agile, you’d better like the people on your team—or at least be able to communicate effectively with them. The agile principles encourage tight-knit collaboration, constant feedback, and lots of trust. When you’re moving at such a high velocity, fluent communication is essential to staying on the same page.

Agile teams run into trouble when they don’t have a quick, reliable way to keep one another in the loop. If a developer isn’t sure what they’re supposed to be doing, even for a few hours, an entire sprint can be derailed. And since shifting to remote work, seamless communication has been an ever-bigger challenge.

How to avoid it? Embrace asynchronous communication. It’s flexible, casual, and great for distributed teams. In fact, some believe async communications could unlock a new-and-improved 21st-century version of agile product development. It allows you to stay connected from home while avoiding unnecessary meetings and Zoom fatigue.

5. Last-minute changes to sprint goals

Your agile team should embrace flexibility and adaptability, but there’s a limit: Once you enter a sprint, the sprint goal shouldn’t be altered.

A sprint goal is just what it sounds like: the task your team is trying to accomplish, such as fixing a bug or developing a new feature, that’s agreed upon before starting a sprint. Once your team takes off, the path may very well change, but the final destination should be locked in place so the team stays aligned while they’re heads-down.

Your agile team should embrace flexibility and adaptability, but there’s a limit.

It may be tempting to change the sprint goal as you discover new customer requirements along the way, but practice caution: it’s not an economical use of time. Switching around goals when developers are already working toward a solution kills momentum, forces backtracking, and results in wasted work.

How to avoid it? If you really think changing sprint goals is necessary, ask yourself: Is this an economically sensible change? Remember, the ultimate goal is to deliver customer value as quickly as possible, so the executive decision always comes down to whether a change will accelerate or delay customer value.

6. Stale product backlogs

When they let their product backlogs become stale, agile teams can fall into a trap of building the wrong thing. Instead, ensure that you have a healthy, up-to-date backlog of what to tackle next.

A product backlog keeps agile teams on track. It’s a living, breathing to-do list of priorities that changes in response to shifting customer requirements. A healthy product backlog is a critical part of the agile process. It’s where you prioritize which new features and fixes you’ll tackle next.

The mistake occurs when agile teams let their product backlogs go stale. They create a long list of priorities and then mark them off one by one, without regularly readjusting. It’s completely normal for user requirements to change as your product, users, and market evolve. If your product backlog isn’t evolving as well, you may not be paying enough attention. As a result, you might be spending your time and resources building the thing that was most valuable six months ago, not the thing that’s most valuable right now.

How to avoid it? Always be prioritizing. Product owners should regularly consult with customers, stakeholders, and their own teams to determine what’s most important and feasible to tackle next. If your product backlog becomes unwieldy, sort ideas into “near term,” “long term,” or “out of scope” to stay organized.

Agile product development is still the most customer-centric approach

No matter how many potential mistakes are out there, agile still stands out as the best option for development teams that want to build the most lovable, valuable products possible.

Like most things, achieving great agile product development is about striking a balance. Loosen up too much and you can start losing alignment with your team and the organization at large. Button things down too tight and you won’t be practicing agile at all. Strike a balance and you’ll be primed to deliver consistent, high-value updates to your users.

Does your product team strive to put your customers first? If so, check out Is Your Product Team Really Customer-Centric? to learn how you can even more customer-driven decisions.

About the author

Ryan Glasgow

Product guy. Early team member at Weebly (acquired by Square) & Vurb (acquired by Snapchat); UCSD alum. I started Sprig to help businesses identify and measure the unmet needs of their customers.

Ryan Glasgow headshot

Share on

Get the best content on UX research, design, and product management delivered to your inbox every week.

Launch a Sprig and get insights within hours.

Make every product decision research-informed. Get started with Sprig and conduct high-impact research with your users across the product lifecycle.