Over the last twenty years I have worked with organizations in banking, energy, public services, industry and technology. They used different frameworks, different consultants and different budgets, and they had different ambitions. Yet the same ten mistakes keep coming back. None of them are about Scrum ceremonies or Jira settings. They are about how work, decisions and accountability are actually organized.
Each of these pitfalls quietly works against an Agile way of working. Usually there is no open resistance. It happens by default: the old operating model stays in place, and the Agile vocabulary gets added on top.
The examples below are composite situations drawn from recurring patterns. They are not descriptions of specific clients.
1 No dedicated team members
The pitfall: Work is still allocated to individuals instead of flowing into a team.
On paper there is a team. In practice, people are spread across three or four initiatives at 20–40% each, and their line managers hand them tasks directly. The team becomes a reporting unit rather than a unit of delivery. Nobody shares ownership of the outcome, because everyone is optimizing their own slice of the work.
Example: A “Scrum team” of eight people has only two members working on the product full time. The others join the Daily when they can. Sprint commitments are negotiated person by person (“Can you give me two days next week?”), so the Sprint Goal is effectively the sum of individual favors.
What to do instead: Bring the work to stable, dedicated teams rather than assembling people around each piece of work. Make the team the unit of capacity and accountability. Partial allocation should be the visible exception, not the default.
2 No transparency: no single place for all work in progress
The pitfall: Work is scattered across multiple backlogs, multiple tools, private to-do lists and hidden Excel sheets.
If you cannot see all the work, you cannot prioritize it, limit it or finish it. Hidden work is still work. It consumes capacity, creates interruptions and explains why “the team is always late” even though the official backlog looks manageable.
Example: A team’s Jira board shows twelve items in progress. A short exercise putting all actual work on a wall reveals 41: support tickets in ServiceNow, compliance requests by e-mail, a manager’s Excel tracker of “small favors”, and three side projects that predate the transformation.
What to do instead: Create one visible flow of work per team, and one portfolio view across teams, that includes everything: projects, run, support, improvement and requests. Then limit work in progress. Transparency is the precondition for every other Agile mechanism.
3 No customer in the loop
The pitfall: Everyone avoids talking with the customer.
Agile is customer-centric by nature. The customer pays for the development and is the only one who can confirm whether it creates value. Yet many organizations shield teams from customers behind layers of proxies: business analysts, requirement documents, steering committees and account managers. Feedback arrives months later, filtered and politically softened, or never.
Example: An internal IT team builds a new claims-handling tool for twelve months without meeting a single claims handler. At go-live, users keep their old spreadsheet in parallel because the new tool needs seven clicks for something they used to do in two. One afternoon of observation in the first month would have revealed this.
What to do instead: Put real users and paying customers into the cadence: Sprint Reviews with actual users, regular field visits, usability sessions and direct feedback channels. If a team cannot name its customer, that is the first problem to solve.
4 Work is sequential, not iterative and incremental
The pitfall: The waterfall survives inside sprints.
Sprints are introduced, but the work inside them still follows analysis, then design, then build, then test, then release. Sprint 1 is “requirements”, Sprint 2–5 is “development”, Sprint 6 is “testing”. This is a phased plan cut into two-week slices. Nothing usable exists until the end, so nothing can be learned along the way.
Example: A team reports 100% sprint completion for five sprints in a row. In Sprint 6, integration testing begins and uncovers that the core data model does not fit the downstream system. Every “completed” sprint was only completed on paper.
What to do instead: Slice work vertically, so that each increment is a thin but working piece of value that can be shown, tested and used. Ask in every Sprint Review: “What can a user do now that they could not do two weeks ago?”
5 Teams are not end-to-end
The pitfall: Teams are organized by component, technology layer or function, not by value stream.
A front-end team, a back-end team, a database team, a test team and an operations team each have their own backlog and their own priorities. Delivering a single customer feature requires coordinating all of them. The real work becomes managing handoffs, and lead time is dominated by waiting.
Example: Changing a field on a customer-facing form requires tickets in four teams. Each team estimates its part at half a day. The change still takes seven weeks, because each team schedules it into a different sprint.
What to do instead: Design teams around customer outcomes or value streams, with the skills needed to deliver end-to-end. Where full end-to-end is not yet possible, make dependencies explicit and treat reducing them as an organizational design task, not a coordination task.
6 No self-organizing teams
The pitfall: Teams are told what to do and how to do it.
Self-organization does not mean the absence of management. It means that the people closest to the work decide how the work gets done, within clear boundaries. When managers keep assigning tasks, estimating on behalf of the team and approving every technical choice, the team learns that initiative is not expected. Over time, it stops offering it.
Example: A team lead runs the Sprint Planning alone and distributes tasks by name. During the Retrospective, the team suggests pairing on a difficult module. The suggestion is declined because “it halves productivity”. The next Retrospective is silent.
What to do instead: Define the boundaries explicitly: what the team decides, what it decides after consultation, and what is decided for it. Then respect those boundaries, especially when the team makes a choice a manager would not have made. Self-organization is a capability that grows when it is used.
7 Product Owners are not empowered
The pitfall: The Product Owner is a backlog administrator, not a decision-maker.
The Product Owner role only works if the person can actually decide what gets built and in what order. In many organizations, the PO is a junior business analyst or a project manager with a new title. Every meaningful priority still goes to a committee, a sponsor or several stakeholders who each believe their request is the top priority.
Example: A PO’s backlog is reordered three times in one month by different directors. The PO’s main activity becomes collecting signatures for prioritization decisions. Sprint Reviews turn into negotiations, and the team no longer knows what “done” is supposed to achieve.
What to do instead: Give the PO a clear mandate: budget or capacity, decision rights over ordering, and direct access to customers and sponsors. Stakeholders influence the backlog, but one accountable person decides. If nobody can be given that authority, the organization is not yet ready for the role.
8 Development is limited to the “development phase”
The pitfall: Agile is applied only to the build phase of a project, not to the full lifecycle of the solution.
Many organizations put Agile inside a traditional project shell. Business cases, budgets and scope are fixed up front, often a year in advance. Teams “do Agile” during development. After go-live, the solution is handed over to operations and the team is dissolved. Learning stops exactly when real usage begins.
Example: A digital onboarding platform is built in Scrum, delivered on time and celebrated. Six months later, conversion is 30% below target, but there is no team or budget left to iterate, because “the project is closed”. Improvements must wait for next year’s project portfolio cycle.
What to do instead: Treat solution development as a full cycle: discovery, delivery, operation and continuous improvement, carried by long-lived product teams. Fund products and capacity, not projects and scope. Measure outcomes after go-live, not only outputs before it.
9 Developers carry the burden when the problem is outside the team’s boundary
The pitfall: When an impediment sits outside the team, the organization still expects the team to absorb it through extra effort, extra support and extra pressure.
Many blockers are systemic: slow approvals, missing environments, unclear architecture decisions, external dependencies, procurement delays, conflicting priorities between departments. None of these can be solved inside a team. Yet the usual response is to push harder on the developers through overtime, escalation calls, “war rooms” and status drills, instead of having leadership remove the obstacle.
Example: A team waits three weeks for a test environment owned by another department. Management’s response is a daily escalation call with the developers to “track progress”. The developers spend an hour a day explaining a blockage they cannot fix. The environment request still sits in a queue nobody in the call controls.
What to do instead: Make it explicit that impediments outside the team’s boundary belong to leadership. Keep a visible impediment backlog at management level, with owners and dates. A good indicator of a healthy transformation is how fast systemic impediments are removed, not how much effort teams put into working around them.
10 The transformation depends on one strong leader
The pitfall: The transformation works while a strong sponsor is in place, and falls apart when that person moves on.
Strong leadership is often what starts a transformation. But if the new way of working is held together by one person’s conviction, authority and attention, it has not been institutionalized. When the leader leaves, old structures, incentives and reporting lines reassert themselves, sometimes within months.
Example: A division head champions Agile for three years. Teams are stable, Product Owners are empowered, and quarterly planning is shared. Her successor reintroduces detailed monthly reporting per person and project-based funding “for transparency”. Within two quarters, teams are reallocated, and the most experienced Scrum Masters leave.
What to do instead: Anchor the change in structures rather than people: governance, funding models, role definitions, decision rights, career paths and performance criteria. Build a leadership coalition, not a single champion. Ask early: “If our sponsor left tomorrow, what would keep this in place?”
The common thread
Read the ten pitfalls together and a pattern appears. Agile fails less often because teams are doing Scrum “wrong” than because the organization around them keeps operating on different assumptions: individual allocation, hidden work, fixed scope, functional silos, top-down decisions and personal sponsorship.
In other words, these are operating-model problems, not framework problems. Introducing a framework changes the vocabulary. Changing how work flows, who decides and how accountability is carried changes the organization.
This is the distinction at the heart of the AO Method: diagnose the system first, then decide which practices fit, rather than installing a framework and hoping the organization adapts to it.
A quick self-check
Take five minutes with your leadership team and answer honestly:
- Are most of our team members dedicated to one team?
- Can we see all work in progress in one place?
- When did our teams last speak directly with a real customer?
- Does every increment produce something usable?
- Can our teams deliver a customer feature without waiting for other teams?
- Do teams decide how they do their work?
- Can our Product Owners say “no” and be backed up?
- Do teams keep improving the solution after go-live?
- Who removes impediments that sit outside the team, and how fast?
- Would our way of working survive the departure of its main sponsor?
If you answered “no” or “not really” to three or more, the issue is probably not your teams. It is the system they work in.
If you recognize your organization in several of these pitfalls and want to understand what is holding your system back, get in touch with Menschgeist. We start with diagnosis, not prescription.
Discover more from Menschgeist
Subscribe to get the latest posts sent to your email.