Agile Assumptions That Still Trip Up Organizations

Fifteen Years of the Same Mistakes

In 2011, agile coach Mike Cottmeyer published a list of twelve assumptions that agile methods make about your organization. The list was a warning: adopt these practices in the wrong context and you will fail. Fifteen years later, organizations keep making the same mistakes. They install Scrum or SAFe, skip the part where they check whether the preconditions exist and then declare that agile does not work.

Some of those assumptions have proven remarkably durable. Others deserve a fresh look. What follows is an assessment of which assumptions still hold, which have shifted and what practitioners should pay attention to today.

The Assumptions That Have Not Changed

Team stability remains non-negotiable

The most important assumption on the original list was that teams stay together over time. Nothing in the past fifteen years has weakened this one. Research from Google’s Project Aristotle and decades of team performance studies confirm that psychological safety, shared mental models and predictable velocity all require continuity. Organizations that treat people as interchangeable resources and shuffle them between projects every quarter will continue to get poor results from agile methods.

Stable teams also need people who can do more than one thing. Agile assumes team members are specializing generalists: T-shaped professionals who hold deep expertise in one area but can contribute across disciplines. When every person on the team is a narrow specialist, the only way to keep them busy is to split their time across projects. That destroys the team stability agile depends on.

Customer engagement still makes or breaks delivery

The assumption that a fully engaged customer or product owner participates in real-time decision-making is still the most frequently violated condition in practice. The pattern is consistent across industries: organizations appoint a product owner who has a day job, give them two hours a week for the team and then blame the developers when the product misses the mark. Lightweight documentation and iterative delivery only work when someone with authority is available to steer.

Dependencies kill predictability

Loose coupling between teams and minimal external dependencies remain critical. Scaling frameworks like SAFe attempt to manage cross-team dependencies through program increments and dependency boards, but the underlying problem persists. Every dependency outside the team’s control introduces delay and erodes accountability. The teams that deliver most reliably are the ones that own their entire value stream.

The Assumptions That Have Evolved

Co-location is no longer the default

The original list assumed team members would be in the same room. The global shift to remote and hybrid work has made this assumption largely obsolete as a hard requirement. Distributed teams can and do succeed with agile, provided they invest in the right tools and practices. What has not changed is the underlying need for frequent, rich communication. Teams that replace hallway conversations with nothing will fail regardless of methodology.

Products over projects is now mainstream

Cottmeyer noted that agile assumes teams deliver products rather than projects. In 2011, this was a minority position. Today, product-oriented thinking has become the dominant model in software organizations. The widespread adoption of product management roles and frameworks like "Escaping the Build Trap" have moved this from assumption to aspiration for most companies. The challenge has shifted from convincing organizations that product thinking matters to helping them restructure funding and governance models to support it.

The talent bar has shifted

The original assumption that agile requires "the top 10%" of talent deserves nuance. Modern agile practices, better tooling and more mature team facilitation techniques have made agile accessible to a wider range of professionals. What remains true is that self-organizing teams require people who can make decisions without waiting for instructions. The question is less about raw talent and more about mindset and willingness to operate with autonomy.

The Assumptions That Were Always Incomplete

Governance cannot be ignored

Agile methods deliberately avoid prescribing governance structures. Cottmeyer flagged this as an assumption of minimal process governance. In practice, regulated industries like banking and pharmaceuticals, public sector organizations and large enterprises cannot simply wish governance away. A bank adopting Scrum still needs audit trails, change approvals and regulatory compliance. The agile community has slowly recognized this gap. Approaches like disciplined agile delivery and enterprise Kanban now offer frameworks for integrating governance without abandoning agility.

Architecture needs upfront thought

The assumption that an established architecture exists was always a gap in agile methods. The answer is not to return to big upfront design. It is to acknowledge that architectural decisions carry long-term consequences that sprint-by-sprint refactoring cannot always fix. Modern practices like architecture decision records and evolutionary architecture provide middle ground between heavy upfront planning and no planning at all.

What This Means for Your Organization

The practical takeaway has not changed since 2011. Before adopting any agile framework, audit your organization against these assumptions. Where the conditions exist, the framework will likely work well. Where they do not, you face a choice: change the organization or change the practice. Pretending the gap does not exist is the only option guaranteed to fail.