Scrum Pitfalls

2025-04-20

There is no doubt using Agile, and specifically the Scrum framework, for software development has proven benefits above other ways of working such as Waterfall. Like everything in IT this however is not a hard truth that is always applicable. Let’s take a critical look at Scrum in practice, some common problems and looking ahead beyond Scrum and Agile.

Working as a IT consultant there are still pitfalls I come across that could be easily mitigated. Above all, Agile is not just a framework or process; it is a mindset that requires cultural changes when making the change from more traditional, waterfall-like, development to Agile/Scrum.

What is Agile about?

Before diving into the problems, let’s establish what Agile was supposed to solve. The Agile Manifesto, written in 2001, emerged from frustration with heavyweight, document-driven software processes that were failing projects left and right. The core values were simple:

The idea was revolutionary: instead of spending months planning every detail upfront (only to watch those plans crumble), teams would work in short cycles, get feedback quickly, and adapt based on what they learned. Scrum provided a specific framework for this: cross-functional teams, time-boxed sprints, regular ceremonies for inspection and adaptation, and clear roles with the Product Owner representing customer needs and the Scrum Master facilitating the process.

The theory was beautiful. The practice? Well, that’s where things get interesting.

What are common pitfalls and the solution?

Let’s take a look at some common pitfalls I’ve come across in my career and see what the solutions could be.

Overdosing on Meetings: Death By A Thousand Ceremonies

Sprint planning that stretches for hours. Daily standups that somehow take 35 minutes. Backlog grooming sessions that feel more like archaeological expeditions. Sprint reviews where stakeholders discover requirements they forgot to mention. Retrospectives that rehash the same issues sprint after sprint. Every developer has experienced the time drain and “distraction from coding” called “meetings”.

I once calculated at one client I’ve worked at that in a typical two-week sprint, I spent 16 hours in meetings. That’s two full working days of ceremony for 8 days of actual development time. When did we decide that talking about work was more important than doing it? The cruel irony? We’re so busy being “Agile” that we have no time to be agile.

This problem is also tightly coupled with the problem of treating Scrum as the formal events only and not changing the company (and development) culture altogether. If we think a Scrum meeting should take x amount of time then we are really good at filling up that time. Is it really productive and efficient? It depends.

Refinements can be quick 10 minute sessions where we go over some backlog items and work out the details collectively. Longer sessions can be wasteful, especially when priorities change during the course of the week.

Long and ineffective meetings can also originate from misinterpretations of Scrum by traditional managers taking on the role of Product Owner or Scrum Master.

Solution

The Agile solution to this problem is to experiment and reflect! Can we decrease the meeting time? Are we overcommitting to a Sprint every time and is it time to take on less backlog items, resulting on a more efficient Sprint Planning. Can we actually use the Daily Scrum to make a plan for the day instead of repeating the classical questions that become more like a mandatory burden than an actual useful tool.

Absent Product Owner

In Scrum theory, the Product Owner is crucial. The role represent the customer, prioritizes the backlog, defines acceptance criteria, and makes decisions about what gets built. They’re supposed to be available, engaged, and empowered to make product decisions.

The Product Owner can also be a proxy between the Development Team and a stakeholder from the business making decisions on requirements, scope and resources. As such, the PO is usually someone with business experience more so than software development experience and is not required, even discouraged, to be physically present during daily development. However, having a Product Owner act as a proxy also distances the developers from stakeholders and can slow down quick decision making. In an experienced, senior team with a high degree of ownership it should not be a problem for developers to align with stakeholders directly.

As a developer is doesn’t help if there’s a business person breathing down your neck on a daily basis. It could however lead to a situation where the PO is more focused on business processes than being available for the team. The PO should be present at all Scrum events, except the Daily Scrum, because the development team should hear about business decisions that can impact development as soon as possible. It is up to the PO to determine what’s really important and what not to keep noise for the development team low.

It is however also important to strike a balance here: without a clear centralized product direction, teams fill the vacuum. Developers start making product decisions (“I think users would want this…”). QA defines their own acceptance criteria. The Scrum Master starts prioritizing backlog items. Everyone becomes a part-time product owner, and nobody is accountable for the product direction.

The result? Features that nobody asked for, requirements that change daily, and a team that’s building something but isn’t sure what or why. Planning poker sessions turn into philosophical debates:

“This feels like a 5 to me because of the database complexity…” “But we did something similar last sprint that was a 3…” “Are we counting the testing effort?” “What about the deployment automation?”

Meanwhile, the actual work often takes however long it takes, regardless of our collective finger-pointing at Fibonacci numbers. The real kicker? Management starts treating these estimates as commitments, and suddenly your thoughtful uncertainty becomes a personal failure.

Solution

It is up to the Scrum Master to coach the PO about the importance of being available at Scrum events and being available to the development team when needed. Pro-active behavior is also needed to update the team about new business decisions that could impact the project scope. It is the responsibility of everybody in the team to be critical about daily operations and this is where communication and a pro-active attitude shines. In this sense the Product Owner can offload the burden of business decisions from Developers, and Developers can focus 100% on the technical challenges that should be aligned with the business vision and Sprint Goal.

Adopting formal events and terminology only

This brings us to one of the most common failure modes: adopting Scrum’s ceremonies and vocabulary while ignoring its principles. Organizations love the structure that Scrum brings: it’s easy to implement, measure, and control. Sprint planning, daily standups, sprint reviews, retrospectives. User stories, acceptance criteria, definition of done. Story points, velocity, burndown charts. It feels productive. It looks organized. Management can point to all these activities and say, “See? We’re doing Agile!” But here’s what often gets lost: The ceremonies become rituals. We have standups because the methodology says we should, not because they’re helping us collaborate. We estimate stories because that’s what you do in Scrum, not because the estimates inform better decisions. The vocabulary becomes jargon. Everything becomes a “user story” even when there’s no clear user. Every task needs story points even when estimation adds no value. We have “epics” and “themes” because the tools expect them, not because they represent meaningful chunks of work.

The metrics become the mission. Teams focus on increasing velocity instead of delivering value. They worry about burndown charts instead of customer satisfaction. They optimize for story completion instead of working software. I’ve seen teams spend more time updating Jira than writing code, more time discussing process than solving problems. They have all the trappings of Agile without any of its benefits.

Solution

Once again it is a matter of taking a critical look at the benefits vs. downsides (trade offs) of Scrum events. Is a Sprint Review/Demo actually beneficial in our organisation? Or do we rather deploy to production often and get user feedback faster. Can the daily standup focus on a plan for the day and any issues that can be solved collectively or do we just go over the “What did I do yesterday? What will I do today? Are there any blockers or issues?” like a soulless robot that has to perform a status report to a higher entity.

Company politics and no agile culture

Agile often becomes a battlefield for organizational politics, with different groups weaponizing methodology for their own ends. The Agile Evangelists push for “pure” Scrum implementations, often backed by expensive consultants or recent certification programs. They see any deviation as failure and any criticism as resistance to change. The Traditionalists use Agile failures to advocate for returning to waterfall approaches. “See? This Agile thing doesn’t work. We need more upfront planning.”

The Empire Builders use Agile transformation as an opportunity to expand their influence. Suddenly every team needs a Scrum Master (who reports to them), every project needs an Agile coach (from their department), every decision goes through their “Center of Excellence.”

The Micromanagers love Agile’s transparency and use it as a sophisticated surveillance system. They want daily reports, detailed burndown charts, and explanations for any variance from the plan. Meanwhile, caught in the middle are the developers who just want to build good software. We become pawns in larger organizational games, with our day-to-day work constantly disrupted by changing processes, new tools, and competing visions of how we should work.

The original Agile principle of “individuals and interactions over processes and tools” gets lost in the political maneuvering around processes and tools.

Agile promises self-organizing teams, but many implementations become sophisticated micromanagement systems. Daily standups become status reports. Sprint planning becomes task assignment. Retrospectives become thinly veiled performance reviews.

The transparency that was meant to empower teams instead becomes a panopticon where every hour is accounted for, every impediment is escalated, and every deviation from the plan requires explanation. I’ve seen developers develop anxiety around standups, carefully crafting their updates to avoid follow-up questions or concerned looks from managers. That’s not psychological safety—that’s surveillance.

Solution

Maybe, just maybe, we should drop Scrum altogether and just focus on software development again? Especially at informal companies and startups I’ve experienced a more productive development team just by having: - fast and pro-active communication - focus on delivering features that bring business value (developers talk to stakeholders) - an experienced Tech Lead or CTO that helps developers focus on the business vision and oversee architectural decisions These ofcourse depend on the size of the company and get harder to implement when company with growth. Luckily the focus becomes more on this productive development culture with trends like DevOps, Developer Experience and Platform Engineering.

Scrum Master as a management role

The Scrum Master role is supposed to be about servant leadership—coaching the team, removing impediments, and facilitating the Scrum process. They’re not supposed to be managers in the traditional sense. But in many organizations, the Scrum Master becomes a thinly disguised project manager or team lead. They assign tasks, track individual performance, escalate issues to upper management, and become the person responsible for “making sure the team delivers.

This creates several problems: - Psychological safety disappears. - When your Scrum Master is evaluating your performance, you’re not going to be honest about impediments, concerns, or mistakes in standups. - The daily standup becomes a status report to your boss, not a team coordination meeting. - Process becomes policy. Instead of helping the team adapt Scrum to their needs, the Scrum Master becomes the process police. “That’s not how we do standups.” “You need to update your story points.” “This doesn’t follow our definition of done.” - Impediment escalation becomes blame assignment. When developers raise impediments, instead of helping solve them, the Scrum Master asks, “Why didn’t you anticipate this?” or “What are you going to do about it?” - Team autonomy erodes. The self-organizing team concept dies when someone is organizing the team for them. Decisions get escalated to the Scrum Master instead of being made collectively.

I’ve worked with Scrum Masters who had one-on-ones with team members, gave performance reviews, and made decisions about who worked on which stories. At that point, just call them what they are: managers. But don’t pretend it’s Scrum.

Solution

This is where a professional Agile Coach might come in. By going beyond a specific team they can facilitate cultural change, company-wide. They ensure the proper training is given and higher levels at the company, orchestrating a “trickling-down” effect of Agile culture. The real problem are often the employees that have been working at the company for decades and “doing the same thing for years, so why change?”. My experience is that with the right coaches, change management agents, lead devs or even external hires this can change over time. It might take some time, but the benefits of change far outweight the risk of keeping things the same.

Cross-team alignment

Scrum works well for individual teams, but most real software systems require coordination across multiple teams. This is where the methodology often breaks down. Sprint boundaries don’t align. Team A is in week one of their sprint while Team B is in week two. Dependencies get discovered mid-sprint, but the other team can’t help because they’re committed to different work.

Competing priorities. Each team has its own Product Owner with its own roadmap. What’s critical for the frontend team conflicts with what’s important for the platform team. There’s no mechanism for resolving these conflicts at the Scrum team level.

Integration nightmares. Teams work in isolation, building features that need to work together. But integration testing happens later (if at all), and suddenly the carefully planned sprint commitments fall apart when nothing actually works together.

Different velocities and cadences. The mobile team ships every two weeks, the backend team ships monthly, and the infrastructure team works in quarterly cycles. Coordinating releases becomes an exercise in frustration. Communication gaps. Teams rely on other teams’ “interfaces” or “contracts,” but these are often poorly defined or change without notice. The daily standup doesn’t help when your impediment is in another team’s backlog.

Solution

I’ve seen organizations try to solve this with “Scrum of Scrums” meetings, dependencies tracked in elaborate spreadsheets, and cross-team coordination roles. But these solutions often add more process overhead without solving the fundamental problem: Scrum assumes team independence that rarely exists in practice. Product Increment meetings and roadmaps might help adding a light-weight layer on top of multiple development teams. Both to align their visions and to identify and plan dependencies. It also helps to physically put teams with dependencies together in the office to facilitate team alignment and communication.

Regular alignment by Tech Leads also helps align on a technology level without directly needing a dedicated (Software) Architect role. Tech Leads are often more in touch with the daily technical operations and details compared to traditional architects that are great in documenting and planning high level systems and overviews, but they might not take “lower level” aspects into account, leading to frustrated developers. I’m a big fan of Architecture Decision Records (ADR), that are often found in teams with a high degree of ownership which is the result of the ability to have the freedom to take that ownership. This ofcourse is a trust and company culture aspect that needs to be there in the first place.

No multi-disciplinary team

Scrum calls for cross-functional teams that can deliver working software independently. In practice, many Scrum teams are just developers with occasional appearances from other disciplines.

Some common pitfalls in such teams are:

The Designer Bottleneck: One UX designer supports three development teams. Design work gets done in isolated phases, then handed off to developers who discover it’s technically infeasible or doesn’t match user needs discovered during implementation.

The QA Afterthought: Testing happens at the end of the sprint (if there’s time). Bugs discovered in sprint review get pushed to the next sprint’s backlog. The team commits to features they haven’t actually tested.

The DevOps Dependency Deployment, monitoring, and infrastructure changes require tickets to another team. Features sit “development complete” waiting for environments, database changes, or deployment pipeline updates.

The Product Knowledge Gap Developers make assumptions about user needs because the Product Owner isn’t available for daily questions. Business analysts create detailed requirements documents that defeat the purpose of iterative development.

The Skills Mismatch The team has three senior backend developers and one junior frontend developer. Every story with UI work becomes a bottleneck. Sprint planning becomes an exercise in creative work distribution to avoid idle time. Without true cross-functional teams, Agile becomes a series of handoffs between specialists. The quick feedback loops and collaborative problem-solving that make Agile effective disappear, replaced by the same silos that Agile was supposed to eliminate.

Solution

What stops a team from taking ownership is a combination of: 1. lack of freedom to take that ownership (company culture) 2. lack of experience in the team (junior vs. senior) 3. lack of technical leadership (tech lead alignment) 4. lack of knowledge sharing across teams (Guild meetings) 5. lack of budget to hire expertise

It speaks for itself that a team that has more dependencies is less efficient. In the same way that microservices are most often perceived as easier to manage because they are smaller and better isolated. To solve this challenge it is good to take a look at one of the “lacks” above and see how you can overcome them one by one.

Conclusion: Scrum and Agile are like training wheels for Developer Culture

As developers, we have more power than we often realize. We can push back on counterproductive practices. We can suggest experiments. We can measure what actually matters. The next time someone says “that’s not very Agile,” we can ask: “What outcome are we trying to achieve, and is this process helping us get there?”

Agile was supposed to liberate us from rigid, bureaucratic processes. Let’s not let it become one itself. The goal isn’t to be perfectly Agile, it’s to build great software with great people in a sustainable way. Sometimes the most Agile thing you can do is question Agile itself.

Adopting efficiency related practices can help here. DevEx (Developer Experience) is a growing practice that focuses on improving the efficiency of developers by using tools and measurements to get rid of bottlenecks. Those bottlenecks are most often also the things that developers hate and prevent them from having fun in building and delivering software. For example: would you rather open a portal (like Backstage) and instantly find what backend services are talking to which, how to authenticate to them, what the dependencies are, get clear instructions how to run a service locally, etc vs. talking to an architect, another developer, clone some repository you’ve finally found, go through piles of code to figure at what it does, and finally find the relevant insight to be able to do your work?

Documentation might seem a “Waterfall” like practice but documentation in itself is needed as long as it’s practical, up-to-date, effective (short and succient) and widely available (internally).

In this age of DevOps (or is it DevSecFinBizOps?) we focus more on building teams with a high degree of ownership, from analysis, implementation, testing and deployment. “You Build It, You Own It”: If something goes wrong the team is aware of all the technical details, dependencies, software runtime paths, etc. This helps speed up both feature delivery, problem/issue analysis and even developer career satisfaction.

In the end, the lack of efficieny, work pleasure and speed of business value delivery is a complex topic with multiple intertwined aspects. Most often it starts with changing the business culture to facilitate change in the right direction. What that direction is also highly depends on the specific company and market they are operating in. It is a bit of a cliche but like software development itself, the operational processes associated with it do not have one right solution.

In the end: “It Depends” and “It’s about Trade-offs” is still more valid than ever.