Article :: Scrum vs ScrumAnd vs ScrumBut: Which one are you doing?

The 2015 State of Scrum Report tells us that Scrum is currently the most adopted agile practice.

In-spite of the massive popularity of this framework we see that organizations rarely use vanilla Scrum… using instead ScrumAnd or even ScrumBut.

ScrumAnd is basically everything that you put on top of the framework… and this is perfectly natural and shows the (agile) maturity of the organization.

ScrumBut is all that you supposedly should do… but in fact you aren’t doing: Retrospectives, Reviews, etc.

When you learn Scrum you have three different stages towards mastery: Shu Ha Ri.

Shu is when you learn the basics. In this stage you’ll learn “Vanilla” Scrum staying strictly in the Scrum Framework.

You get to the Ha stage is when you feel confident enough to start to make changes to the process. It’s in this stage that you make a very important decision:

Follow the path of ScrumAnd;

Or choose the path of ScrumBut.

If you go for ScrumAnd (choosing to put add-ons on top of the scrum framework) you’ll probably reach (someday) the Ri stage: Going beyond Scrum

On the other hand, if you choose ScrumBut (modifying the framework) you’ll almost for sure never reach the Ri stage… and probably get to the (wrong) idea that scrum doesn’t work.

Although add-ons and modifications seem quite similar… they are very different. An add-on is keeping everything you have and simply add more stuff on top. Modifications is changing what you already have… ending up with something completely different from what you had.

ScrumAnd usually goes like this: “We do Scrum… And…”

Here you have some examples of what ScrumAnd can be:

  • Estimations in points… or maybe #NoEstimates at all;
  • Sprint zero;
  • Grooming / Refinement sessions;
  • Prioritization sessions;
  • XP Practices;
  • We limit WIP (Work in Progress);
  • We do swarming (Hyperproductivity pattern);
  • We develop and test story by story (instead of having mini waterfalls inside the sprint);
  • We have all the team testing when needed (usually by the end of the sprint);
  • Our team members have t-shaped skills (cross-functional);
  • Our sprints start on Mondays and finish on Fridays (except for Bank Holidays);
  • All our teams are aligned (sprint wise)… so we all start and finish at the same days;
  • Our team size is 7+-2;
  • We invite everyone in the department to assist to our sprint reviews;
  • We release often and during the sprint without (a lot of) effort;
  • The Scrum Master is trying to be unnecessary (putting himself out of his job) coaching the team to be autonomous and self-organized;
  • We have 80% test / code coverage (unit tests wise);
  • We do code reviews (or we work with pull requests).

ScrumBut typically goes like this: “We do Scrum… But…”

Here are a few examples of what ScrumBut can be:

  • Our team members think of “my” sprint / tasks / user stories / story points instead of “our” sprint / tasks / user stories / story points;
  • We have a waterfall inside the sprint (testing only start after all the coding is “done”);
  • We have QAs / testers working outside the team / sprint;
  • QAs don’t speak to developers whenever they find bugs (processes and tools over individuals and interactions);
  • The team works for the KPIs and not for the (potential) value delivered;
  • The team can’t implement (technically) a user story without the dev lead or architect;
  • The Product Owner is a “chicken” (isn’t allowed to speak on dailies and can’t attend retrospectives);
  • We use 6 to 12 weeks sprints to “avoid pain” / “disguise problems” (e.g. releases, manual regression testing, deploys to test environments, etc.);
  • After a sprint we “stop” for 1 week of acceptance tests / bugfixing / stabilization (nonconsecutive sprints);
  • Team members arrive late to scrum ceremonies;
  • We have daily scrums away from the physical / virtual board;
  • We do BDUF (big design up front) instead of favoring emerging architectures and the lean and XP concepts of LRM (Last responsible moment), YAGNI (You aren’t gonna need it) and JIT (Just in time);
  • We have only one person on our development team;
  • In groomings / refinement sessions the Scrum Master assigns user stories to developers (command & control vs self-organization);
  • In sprint plannings we focus more in having everybody busy (due to specializations) instead of focusing on the maximum value we can deliver (output)… so we cherry pick / choose the user stories that go in the sprint taking (mostly) in consideration the favorite skills / comfort zone of each developer;
  • We don’t have a Scrum Master… and not even a Product Owner;
  • We stopped doing important things (e.g. visiting customers) because “that’s not scrum”;
  • Our team is not cross functional;
  • We have partially allocated team members (e.g. developers);
  • We have horizontal and not vertical user stories so we can’t deliver working software (increments) by the end of the sprint;
  • We split user stories between development and testing;
  • Each user story has an estimate for backend, frontend, integration and testing.

For final remarks, I believe that you shouldn’t aim for effectiveness (ScrumBut) but for efficiency (ScrumAnd).

There is nothing “wrong” in modifying the scrum framework… you just shouldn’t (probably) call it scrum! And (at least) make sure that you are doing it for the right reasons!

For what it matters… don’t forget that your goal is to make (awesome) software… and not to (just) do scrum.