Many of the frustrations experienced by developers, testers and technical leads do not come from agile itself. They come from myths about agile, accumulated over two decades of misapplication, half-read Scrum Guides, and certification courses attended by people who never write a line of code.

The Agile Manifesto was written by practitioners, for practitioners. Most myths about agile are born the moment the practitioners leave the room.

Working in an agile team looks simple from a distance. Short iterations, daily standups, a backlog and a board. Clean, lightweight and empowering. From the inside, it looks different.

Here are ten of the most persistent myths, as experienced from inside the team.

Myth 1: “We don’t need to plan because we’re agile”

Agile does not eliminate planning. It changes when and how deeply you plan. The Agile Manifesto values “responding to change over following a plan,” but this is a priority statement, not a ban on planning. The full sentence in the manifesto is easy to forget for anyone who skipped the fine print.

Failing to plan is planning to fail. Agile replaced the 300-page specification, not the act of thinking ahead.

Sprint planning exists precisely because the team must commit to a goal within the iteration. Refinement sessions exist because unplanned work consumes more time than planned work. Without planning, a sprint quickly becomes a collection of unrelated tasks pointed at by whoever spoke loudest in the last standup.

For the individual contributor, the absence of planning is not freedom. It is noise. Good planning is what protects the engineer’s focus from the chaos of the outside world.

Myth 2: “Story points measure my productivity”

Story points were invented as a relative estimation tool, to help teams forecast how much work they could complete in an iteration. They were deliberately made abstract, to avoid the trap of equating time with effort with output. “If I am to put new flooring in my living room, which is roughly twice the size of my bedroom, it will probably take roughly twice the time” is a good estimate. But it is only as good as it gets if you haven’t ever put on new flooring before. And it no longer applies if the living room is squared with no obstacles on the walls, compared to the bedroom with 10 different corners to and through-floor piping.

Unfortunately, someone, somewhere, decided to put them in a report, together with the LoC production measurement.

Suddenly, a team with a velocity of 40 points is “twice as productive” as a team with 20. No matter how professional the team tries to be, when the bonus depends on the velocity, there will be a shift in mindset. Sprint reviews become regular performance reviews. The abstraction that was supposed to enable honest planning now feeds a dashboard that nobody believes but everybody fears.

Story points measure complexity relative to a team’s own baseline. They do not, and cannot, measure value, quality, or individual output.

Two different teams cannot compare their velocities any more than two soccer player can compare their performance on the field by comparing pull-ups. Using velocity as a productivity metric does not just misuse the tool. It breaks it.

Myth 3: “The daily standup is my status report to management”

The classic 09:00 standup has a comfortable ritual quality. Everyone gets 30 seconds to say what they did yesterday, what they will do today, and whether anything is blocking them. The Scrum Master takes notes as the three what‘s are mentioned. What is less comfortable is who those notes are for.

The daily standup in Scrum is not a reporting mechanism. It is a synchronization mechanism, designed for the team to coordinate among itself; who will review the pending pull requests? Are the testers waiting or choked? But, when the stand-upbecomes a report to management, the dynamic shifts entirely. Engineers subconsciously optimize for sounding busy and in control. Problems are minimized to avoid scrutiny and questions about the team’s skills. Blockers go unreported because reporting a blocker means admitting you are unable to do your part.

A standup that feels like a status report to management is a standup that no longer serves the team.

Eventually, the standup that used to surface impediments now obscures them, and the manager who receives the report believes the team is making steady progress, right up to the moment it misses the sprint goal.

Myth 4: “Agile means no documentation”

The Agile Manifesto favors working software over comprehensive documentation. Emphasis on “comprehensive.”

This is not a mandate to delete the wiki, stop writing commit messages, or skip the API spec. It is a directive to produce documentation that earns its place, documentation that remains useful beyond the sprint in which it was written.

In regulated industries, this myth is catastrophically expensive. An FDA submission, an automotive safety case, a certification body review: none of these survive without documentation. But even outside regulated contexts, the lack of a Technical File means no CE, and no CE means the product cannot be legally sold in Europe at all – a huge blow to company revenue. A team that abandons documentation entirely will spends six months later reverse-engineering what the system actually does, because the three engineers who built it have moved on.

The opposite of comprehensive documentation is not zero documentation. It is the right documentation at the right level of detail.

For the individual contributor, this myth usually arrives as a vague permission slip. “We’re agile, so we don’t do big specs.” What replaces the spec is rarely defined. The result is tribal knowledge, and tribal knowledge is a dangerous bus-factor.

Myth 5: “Every sprint end is a mini-crisis”

A well-functioning sprint ends quietly; the increment is ready and the review is a demonstration, not a negotiation. The retrospective remains honest, and the next sprint starts with clear goals.

In practice, many teams approach the last two days of every sprint at full emergency pace. Unfinished work is jammed through review with insufficient testing and half-completed backlog items are marked “done.”

This is not a consequence of agile. It is a consequence of overcommitment, undone refinement, and the silent pressure to always show velocity trending upward.

Sustainable pace is one of the twelve Agile Manifesto principles, and it is one of the most ignored.

The individual contributor experiences this as chronic stress dressed in iteration-shaped packaging. Two weeks of pressure (because somehow, everyone believes Scrum mandates two-week springts), a brief exhale on retrospective day, then the cycle restarts.

Myth 6: “Self-organizing means management has no responsibility”

Self-organization is one of the most misunderstood concepts in agile. It means the team decides how to accomplish the work, not that the team operates without support, context, or accountability from the people above them in the organization.

A self-organizing team still needs a clear product vision. It still needs organizational impediments removed, and it still needs someone to handle the politics that prevent it from accessing the right infrastructure, the right stakeholders, the right decisions.

Handing a team a backlog and calling it empowerment is not self-organization. It is abandonment in agile clothing.

For the individual contributor, this myth manifests as a team that gets blamed for every failure but consulted on none of the decisions that caused them. The “self-organizing” label becomes a way to transfer responsibility downward without transferring authority. Engineers are expected to solve problems they were never empowered to prevent.

Myth 7: “Everyone should be able to do everything”

Cross-functional teams do not mean interchangeable team members. The cross-functional team model ensures the team collectively possesses all the skills needed to deliver. It does not require each person to possess all of those skills individually.

Somewhere along the way, this became “we’re a team of full-stack engineers,” then “everyone should also know DevOps,” then “why can’t the developers handle the UX research?”

Specialization is not a violation of agile principles. It is how complex systems get built.

The individual contributor who has spent five years becoming a genuinely skilled embedded developer should not be apologizing for not knowing CSS. The team needs both. Building a team of generalists who are mediocre at everything solves a coordination problem by creating a quality problem.

T-shaped skills remain the honest model: breadth across disciplines, depth in at least one. That is not a limitation. That is what good engineering looks like.

Myth 8: “Anyone can add work to the sprint”

The sprint backlog is owned by the team. This is explicit in the Scrum Guide. Once the sprint goal is set and the sprint has started, changes that would endanger the sprint goal need to be negotiated with the Product Owner, not unilaterally injected by whoever has the next escalation.

In practice, engineers in many organizations spend a significant fraction of every sprint on work that was never in the sprint plan. Critical bugs, urgent customer requests and senior stakeholder requests framed as “just a quick thing.”

Each unplanned addition to the sprint is an implicit decision to remove something else. That trade-off is almost never made explicit.

The individual contributor absorbs every one of these injections, causing the sprint goal quietly shifts. Commitments become impossible to honor, and the excuse “we work agile” arrives. The team’s reputation for unreliability is established not by failure to estimate correctly, but by an organizational culture that treats the sprint as a suggestion.

The Modelithe method is very explicit in the consequences of adding work; In fact, no-one can add work at all. The wording is deliberately chosen to be “increase scope” – because that is what happens when the sprint backlog is increased without simultaneously deprioritizing something else.

Myth 9: “Velocity must always increase”

Velocity is a planning tool. Nothing else. It describes the team’s historical throughput so the team can make reasonable forecasts. A stable velocity is exactly what a mature team should have, assuming no change is made to the team’s composition.

Management, encountering velocity as a number on a chart, often draws the same conclusion they would from a sales graph: up is good, flat is stagnation, down requires a corrective conversation.

A stable velocity is a signal that the team is estimating accurately and delivering consistently. It is a good thing.

Pushing for ever-increasing velocity produces exactly the predictable results; estimates inflate and sprint commitments are sandbagged. Sooner or later, technical debt accumulates as corners are cut to maintain the appearance of progress. Eventually, the team looks faster on paper while becoming slower in practice.

For the individual contributor, the velocity-growth myth transforms a neutral planning instrument into a treadmill: running faster to stay in place, while the codebase gradually becomes harder to change.

Myth 10: “Shipped in the sprint means done”

Done has a definition. In well-functioning teams, it is written down and agreed upon before the sprint starts. It typically includes: coded, reviewed, tested, integrated, documented to the appropriate level, and deployable.

“Done” does not mean “merged and deployed to staging while two test cases are still failing and the reviewer had one comment we said we’d fix next sprint.”

An organization that repeatedly ships incomplete work and calls it done is not moving faster. It is borrowing time from its future self, at a high interest rate.

This myth does not just create technical debt. It creates trust debt. Stakeholders who have been shown a “done” feature in a sprint review, only to discover it does not work under realistic conditions, stop believing sprint reviews.

The individual contributor who feels pressure to call something done when it is not is being put in an impossible position. The solution is not individual courage alone. It is a shared definition of done, enforced consistently, with enough organizational support to mean it.

The common thread

Each of these myth started as a reasonable simplification of something genuinely complex, and was then institutionalized by organizations more interested in the appearance of agility than its substance.

Agile is not a delivery method. It is a mindset shaped by first principles: short feedback loops, working software, sustainable pace, and trust in the people closest to the work. When that mindset is replaced by theater, the individual contributor is the first to notice. And usually the last to be asked.

The Agile Manifesto was written in 2001 by seventeen experienced practitioners, not by a committee of process consultants. Its four values and twelve principles are still worth reading in full, slowly, with the specific dysfunction of your current organization in mind.

The Modelithe method builds on these principles, allowing the individual teams to chose how these are to be implemented on a team level; Kanban, Scrum, or something in-between. But Modelithe does not allow the teams to opt out from the core principles: ownership, accountability and transparency.

Now take a moment to reflect on your own team. How many of these myths are operating today, not as explicit policies, but as the unspoken rules everyone follows without question?