Skip to content
DevMeme
2924 of 7435
When the Team's Scrum is More of a Scrum-ish Suggestion
Agile Post #3230, on Jun 13, 2021 in TG

When the Team's Scrum is More of a Scrum-ish Suggestion

Why is this Agile meme funny?

Level 1: Hiding the Mess

Imagine your mom asks if you cleaned your room. You did pick up a few things, but mostly you just shoved all your toys and clothes under the bed and in the closet. Now the room looks clean at first glance. When she comes back and asks, “Did you clean it like I told you to?”, you grin and say, “Well yes, I did… but actually no.” You know you didn’t truly do it properly – you only did just enough to say you tried.

This meme is joking about a similar feeling, but in a workplace. The boss is asking a team if they’re following all the Scrum rules (a way to stay organized and make software smoothly). The team’s answer, “Well yes, but actually no,” is like admitting they only sort-of did what they were supposed to. It’s funny (and a bit cheeky) because it’s so honest: just like a kid hiding the mess instead of really cleaning, the team might be hiding the truth that they aren’t really doing things the proper way. The pirate’s silly shrugging expression in the picture makes the situation feel playful and easy to laugh at – we’ve all been in that spot where we say “yes...kind of” when we haven’t fully done what was asked.

Level 2: Scrum vs Scrum-But

Scrum is a popular framework within Agile project management, meant to help teams work better and adapt to change. In real Scrum, a software team works in short cycles called sprints (often 1-2 weeks long). There are defined Scrum rituals (also called ceremonies) that the team practices in each sprint, such as:

  • Daily Stand-up (Daily Scrum): a quick meeting each day (usually ~15 minutes) where every team member literally stands up and answers three questions: What did I do yesterday? What will I do today? What issues are blocking me? The idea is to synchronize the team’s efforts and surface any obstacles.
  • Sprint Planning: at the start of each sprint, the team plans which tasks or user stories they will complete in that sprint. They discuss the work and agree on a realistic goal for the sprint.
  • Sprint Review: at the end of the sprint, the team shows what they built to stakeholders (like a demo) to get feedback.
  • Sprint Retrospective: after the review, the team meets just among themselves to reflect on how the sprint went. They talk about what went well and what could be improved, then decide on at least one improvement to try in the next sprint. This is how the team continuously gets better.
  • (Backlog Refinement/Grooming is another activity during the sprint where the team and product owner prepare upcoming work, but it’s less formal in Scrum Guide.)

These rituals are essential parts of Scrum. If a team is truly “doing Scrum,” they’re doing all these things regularly, and following Scrum’s principles (like transparency, inspection, adaptation). The leadership’s question in the meme – “So, your team does Scrum?” – is basically asking, “Are you following all these Agile practices properly?”

The punchline answer, “Well yes, but actually no,” points to the concept of “Scrum-but.” This is a tongue-in-cheek term people in software use to describe a partial or modified Scrum implementation. The team says: “We do Scrum, but we don’t do [some important part].” For example: “We do Scrum, but we don’t really do retrospectives,” or “We’re agile, but we still have fixed scope and deadlines for every sprint.” It’s a playful way of admitting they aren’t following Scrum fully or correctly. It often means the team is skipping one or more rituals, or doing them in name only.

Why would a team skip rituals or do “Scrum-but”? There are many reasons (and most teams new to Agile have done this at some point): maybe they don’t see the value of a particular meeting, or they’re under pressure from management and feel they “don’t have time” for a retro or daily stand-up. Sometimes the company says “we’re Agile now,” but doesn’t really change its old habits. This leads to what some call water-Scrum-fall. That means the organization still does big upfront planning and big release launches (just like old-school waterfall methodology), but in the middle the development team is told to operate in sprints. It’s like trying to mix oil and water: you get a hybrid that has sprint cycles on paper, but still behaves like waterfall in planning and delivery. The result is that the team uses Scrum terms (“sprint,” “stand-up,” “Demo Day”) but doesn’t get the real benefits of Agile (like flexibility, frequent delivery, quick feedback loops).

Another term you might hear is “cargo cult Agile.” This is a metaphor from history: during WWII, some isolated Pacific islanders saw military cargo planes bringing supplies, and after the war ended, they built fake airstrips and wooden planes hoping to summon more cargo — they were copying the form without understanding the cause. In software, cargo cult Agile means a team is copying the form of Scrum (the meetings, the jargon, the boards) without understanding or embracing the principles behind it (like collaboration, customer feedback, adapting to change). For instance, they might religiously hold a 10 AM stand-up every day because “that’s what Agile teams do”, but the meeting is ineffective or people are just going through motions. They have the appearances of agility but not the substance.

In the meme, the pirate captain image with the text “Well yes, but actually no” is a well-known meme format used to humorously admit a half-truth or contradiction. The top text asks if the team does Scrum, and the bottom text (the pirate’s answer) basically says: “We say we do (yes), but in reality we don’t really (no).” This encapsulates the AgilePainPoints that developers joke about: sometimes teams claim to be following an Agile methodology like Scrum just to satisfy management, even if in reality they’ve lapsed into old habits or never implemented it fully. The humor works on a basic level (the answer itself is funny because it flips from yes to no), and on a deeper level for IT folks who recognize the ScrumHumor: the team is likely doing “Scrum, but [something].”

So, to a junior developer or someone new to project management: the meme is poking fun at teams that pretend to practice Scrum but actually skip the rules when inconvenient. It’s like saying one thing and doing another, specifically about Agile process. The categories here (Agile, ProjectManagement) hint that this is common in software teams. Many new engineers encounter this: the company says “We’re Agile, we use Scrum,” but you might notice they ignore the sprint retrospective or the daily stand-up is run like a top-down status meeting. That contradiction can be confusing, and this meme is a lighthearted way of labeling it.

In summary, yes, the team might technically have Scrum ceremonies on their calendar – but no, they might not be truly following the Scrum principles or getting the value out of those rituals. If you’re new and a bit confused why something called “Agile” feels surprisingly rigid or chaotic, this meme is pointing out you’re not alone – sometimes what’s called Scrum isn’t real Scrum, and everyone on the team knows it.

Level 3: Cargo Cult Agile

This meme nails the classic “Scrum-but” scenario that many seasoned developers recognize all too well. It’s referencing when a team claims “Sure, we do Scrum!” — but in reality, they cherry-pick or halfheartedly perform the rituals. The pirate captain’s goofy grin and the caption “Well yes, but actually no” perfectly capture that awkward truth. It’s comedic because it’s painfully relatable: leadership is asking if the team follows Scrum by the book, and the team can only respond with a contradictory shrug. Why? Because they’re doing a cargo cult Agile routine — dutifully enacting the outward ceremonies of Scrum without the substance behind them.

In real-world software shops, this is hilariously (and tragically) common. Upper management rolls out an Agile transformation, expecting all the proper Scrum ceremonies: daily stand-ups, sprint planning, sprint reviews, retrospectives, the whole treasure chest. On paper, the team “does Scrum.” In practice, it’s more like Scrum in name only. This pattern is so prevalent it has nicknames: Scrum-but (“We do Scrum, but we skip X or Y”), water-Scrum-fall (Scrum sandwiched between old-school waterfall processes), or even agile theater (acting out agility without real change). The humor here comes from that shared industry secret: everyone nods about being Agile until you peek behind the curtain. At that point, you discover a Frankenstein’s monster of half-implemented practices and old habits.

Let’s be honest, many of us have sailed on this pirate ship:

  • We hold a “Daily Stand-up”, but it’s really just a 15-minute status report where everyone mechanically says, “Yesterday I worked on X, today I’ll work on Y,” and no one collaborates or addresses blockers. (It’s basically a mini status meeting in disguise, with everyone standing uncomfortably.)
  • We do Sprint Planning, but the scope for each sprint is pre-determined by a project manager months in advance. The team has about as much autonomy as a rowboat in a hurricane – the dates and scope are fixed, so planning is just for show.
  • We claim to do Retrospectives, but either we skip them “because we're too busy,” or we hold them and then ignore every improvement idea that comes up. The ritual happens, yet nothing changes (a ceremony without value).
  • We have a Scrum Master, but they’re basically a project admin they spend their time updating JIRA tickets and reporting status to leadership, instead of removing obstacles or coaching the team.
  • We supposedly work in “sprints” (time-boxed iterations), but due to a hard release deadline, the entire timeline is a big waterfall plan chopped into sprint-sized chunks. There’s no real iterative adaptation – it’s just waterfall with extra steps.

Each bullet above is a “Well yes, but actually no” in practice. Agile says “respond to change over following a plan,” but our plan is etched in stone. Scrum theory says the Product Owner decides the backlog, but in our case, the CEO or a client bypasses the process regularly. We do stand-ups every day, but developers just recite yesterday’s work like pirates reading a scripted parrot speech, with no meaningful teamwork happening. It’s pseudo-Agile at its finest. The meme gets a laugh because anyone who’s lived through an “Agile” adoption gone wrong will recognize that forced grin while telling leadership everything is just fine.

Underneath the humor is a sting of truth: organizations often treat Scrum as a checklist or process compliance fiction. Leadership might be more interested in saying “we do Scrum” to impress stakeholders (or tick a box on a management scorecard) than actually empowering teams or changing old waterfall habits. The result is a kind of Agile cargo cult – teams perform rituals they learned from Scrum training (stand-ups, post-it notes, burndown charts) hoping to magically get the benefits (faster delivery, higher quality), yet they ignore the principles that make those practices effective. It’s like building wooden airplanes and expecting cargo to drop from the sky. Trade-offs and pressures lead smart people to these patterns: deadlines loom, so they cut the “fluff” (which sadly often means the actual agile parts like retros or backlog refinement) and keep only the visible meetings. Over time it devolves into what experienced folks sarcastically dub “Scrumfall” – the worst of both worlds.

The senior engineers and Scrum veterans reading this meme are likely smirking (or groaning) because they’ve been in the stand-up circle when the team basically lies through omission. The pirate captain’s face in the meme might as well be a team lead or Scrum Master giving a half-truth smile to an executive: “Yes, of course we follow the Scrum framework” – while internally thinking, “If you consider our hodgepodge version as Scrum...”. It’s funny in the same way gallows humor is: we laugh so we don’t cry about how common this is. Everyone knows the system is broken, but admitting it outright would be walking the plank in front of leadership. So instead you get this meme-worthy answer that’s both affirmative and negating at once.

Why is fixing this so hard? Because true Scrum (and Agile in general) asks for a cultural shift, not just a new meeting schedule. It requires trust, letting teams self-organize, and a tolerance for adjusting plans – things that rigid organizations or control-freak bosses struggle with. It’s much easier to declare “we’re Agile now” and continue micromanaging than to actually relinquish old habits. The result: pseudo-Scrum everywhere. The meme’s comedic punch comes from exposing that disconnect in one absurd exchange. It resonates with developers who have sat through what was supposed to be an Agile ceremony but felt like a pointless formality. It’s the wink-nudge acknowledgment that “Yeah, we say we do Scrum… but actually, not so much.”

Description

This is a two-panel meme using the 'Well yes, but actually no' format, which features the Pirate Captain from the Aardman Animations film 'The Pirates! In an Adventure with Scientists!'. The top panel has the text 'SO, YOUR TEAM DOES SCRUM?'. The bottom panel shows the Pirate Captain with a hesitant, smiling expression, and the caption reads 'Well yes, but actually no'. The meme humorously captures the common corporate phenomenon where a team claims to follow the Agile Scrum framework, but in reality, only adopts a few ceremonies or practices while ignoring the core principles. This is often referred to as 'Scrum-but' or 'cargo cult Agile,' a situation highly familiar to senior engineers who have experienced numerous half-hearted or misguided attempts at process implementation

Comments

11
Anonymous ★ Top Pick Our team's Agile transformation is complete. We've replaced our unpredictable, chaotic waterfall process with an unpredictable, chaotic two-week sprint process
  1. Anonymous ★ Top Pick

    Our team's Agile transformation is complete. We've replaced our unpredictable, chaotic waterfall process with an unpredictable, chaotic two-week sprint process

  2. Anonymous

    We practice “Scrum-ish”: daily stand-ups for optics, story points converted back to man-months, and a burndown chart stapled to a Gantt - Agile theater so convincing even Jira gave it a Tony

  3. Anonymous

    It's called Scrum because after 15 years of 'transformation', we're still doing waterfall with daily standups, but now we have a certified Scrum Master to blame when the two-week 'sprint' takes three months and the retrospective action items from 2019 are still in the backlog

  4. Anonymous

    When management mandates 'agile transformation' but still demands fixed-scope waterfall commitments six months out, requires 47-page design documents before any code, and measures success by Jira ticket velocity rather than delivered value - congratulations, you're doing Scrum! Well, technically no, you're doing what seasoned engineers call 'Scrumfall': all the ceremonies of agile with none of the actual flexibility, all the overhead of waterfall with none of the predictability. It's the worst of both worlds, wrapped in a daily standup that somehow takes 45 minutes

  5. Anonymous

    We “do Scrum”: standups are status theater, story points map to hours, sprint planning just confirms the Gantt chart, and retros are performance reviews - agile, but actually waterfall in a hoodie

  6. Anonymous

    Classic 'ScrumBut': we do daily standups, but actually they're hour-long blame sessions with no action items

  7. Anonymous

    We ‘do Scrum’: daily status with 20 people, hour-based estimates, velocity as a KPI, retros via Google Form, and releases gated by a quarterly CAB - textbook Water‑Scrum‑Fall

  8. @VladislavSmolyanoy 5y

    Failing to plan is planning to fail

  9. @Assarbad 5y

    So true! I've never encountered a team that did actual Scrum. But lots of teams claiming to do it, and then conceding when asked that they merely let themselves be inspired by a number if Scrum ideas. Personally I also lean more towards Kanban, because Scrum IMO can never work if a manager can pull "the manager card" and kill your sprint in an instant. IMO Scrum requires much more far reaching support from parts of the company outside the actual Scrum team. Often that support can not be gained. And Scrum without the firm timeboxing is no Scrum at all. The timeboxing is meant to protect devs from arbitrary interruptions/changes of/to a sprint.

  10. @nameToString 5y

    Muxo texto

  11. @slnt_opp 5y

    Maybe we gotta admit that 9 to 1 scrum isn't practically implementable?

Use J and K for navigation