A Modern Agile Tale: Everybody, Somebody, Anybody, and Nobody

A Modern Agile Tale: Everybody, Somebody, Anybody, and Nobody

In today’s fast-paced tech world, many teams have transitioned to Agile, inspired by the Agile Manifesto’s values and principles. But despite our sprints and ceremonies, the classic pitfalls of “Everybody, Somebody, Anybody, and Nobody” still surface — just with a modern twist.

This is a story about four people in an Agile team: Everybody, Somebody, Anybody, and Nobody. They’re all part of a sprint to deliver a critical feature, one that will “delight the customer” and demonstrate the team’s commitment to “responding to change over following a plan.”

Sprint Planning

The sprint begins. The feature to be delivered is a high-stakes priority, visible across the organization. The Product Owner explains the importance of the feature, emphasizing it aligns with “working software over comprehensive documentation.” Everybody is excited, knowing the potential impact. Everybody assumes Somebody will drive it, especially since Anybody has the technical chops, and surely Nobody would want the sprint to fail.

The Daily Standups

In true Agile fashion, the team gathers for daily standups. On the first day, Somebody notes, “I think Everybody knows this feature is critical, so surely Anybody will pick up the user stories.” Anybody mentions they’re working on a different task but could help if needed. Nobody volunteers to own the task because Everybody thinks it’s already covered.

By the third day, the task is lagging. Somebody expresses concern: “It’s just strange that Nobody has taken responsibility. Anybody here could start, and I thought Everybody was aware of its priority.”

Mid-Sprint Check-In

Halfway through the sprint, the Scrum Master notices the feature hasn’t progressed. Agile values emphasize “individuals and interactions over processes and tools,” so they arrange a quick team meeting to discuss the roadblock.

Somebody raises a point: “I assumed Anybody with the right technical skills would pick it up.”

Anybody counters, “I assumed Somebody would take the lead, given their familiarity with this type of work.”

Everybody agrees that the feature is essential, and Nobody wants the sprint to fail. However, Nobody accepts responsibility.

Sprint Review

At the end of the sprint, the feature isn’t complete. The Product Owner is disappointed. They ask, “What happened here? This was a priority!”

Somebody says, “I thought Everybody knew it was crucial.”

Anybody adds, “I assumed Somebody was working on it.”

Everybody is frustrated, and Nobody is surprised.

Retrospective: Applying Agile Principles

In the retrospective, the team reflects on their missed opportunity and revisits Agile’s core principles to make sure this doesn’t happen again. Here’s what they realize:

  1. Customer Collaboration over Contract Negotiation: They had customer input but assumed it was a collective responsibility rather than clarifying roles. Going forward, they decide that customer needs will prompt clear role assignments.
  2. Responding to Change over Following a Plan: They recognize they failed to adapt to the lack of ownership mid-sprint. Going forward, Everybody agrees to voice concerns early and suggest solutions when roles seem unclear.
  3. Individuals and Interactions over Processes and Tools: Despite standups, they realized they weren’t directly communicating about ownership. From now on, team members will clarify tasks directly rather than assuming who is responsible.
  4. Working Software over Comprehensive Documentation: While they valued working software, they see now that they overlooked the need for one person to own critical tasks, even with minimal documentation. This lesson reinforces that Agile doesn’t mean disregarding structure—it means using it flexibly.

The Moral of the Story

The team learned that “Agile” doesn’t mean operating without clarity or structure. In an Agile world, Everybody needs to take accountability. Somebody must speak up when things look unclear, Anybody can clarify, and Nobody should be left guessing.

In Agile, it’s not about assuming others know or will act. It’s about collaboration, open communication, and aligning each action to a shared vision.


This updated fable highlights how agile teams can still struggle with accountability if they rely on assumptions rather than clear, direct communication. It’s a reminder that Agile’s core is about more than just process—it’s about empowering teams to act collectively and decisively.

Dan Leeds

Improving delivery & results

2 周

Really interesting take, Peter Smulovics. Been thinking last few days about the primacy of principles over process too. You can have all the org structure and process of the frameworks, and still activate few or none of the intended principles that enable the benefit. But I like how you said it in that story better.

Peter Smulovics

Executive Director at Morgan Stanley, Microsoft MVP, Vice Chair of Technical Oversight Committee, Chair of Open Source Readiness, InnerSource, Emerging Technologies in The Linux Foundation, FSI Autism Hackathon organizer

2 周

Tag Dan Leeds

回复

要查看或添加评论,请登录