I recently bought the domain name scrxm.com, inspired by the awesome charity Fxck Cancer and a pet peeve of mine. I get annoyed when people use the words Scrum and Agile interchangeably, implying that Scrum is the only way to “do Agile.” To put a finer point on it, if someone you work with is using Scrum and Agile interchangeably, it’s a sign that they probably don’t know how to build software as part of an agile, high-performing team.

People focused on Scrum, and the certifications / training sold by various organizations with a vested interest in them, actively serve to hurt agility. Which is a shame, given that the goal should always be agility. Agility is “the ability to think and move quickly and easily”. Everything else, even the Agile Manifesto, is in service of that goal.

Now please don’t get me wrong. If you asked me to suggest a baseline process for a new team of 4-6 engineers, I’d probably recommend Scrum. Scrum is a simple framework for managing work – both in progress and to be done. It uses a set of roles and ceremonies that attempt to codify the conversations happening naturally within an effective, agile team. Understanding why those ceremonies exist, what they’re intended to accomplish, and how to modify them is crucial to understand – and you won’t see that on the fun training infographics.

Take daily standups, for example. Martin Fowler’s Bliki has 6,000 words full of advice for fixing these meetings. Google has 20,200,000 search results for “fixing daily standups.” If Scrum training told you everything you needed about those meetings, why is there so much advice available? Because the training doesn’t teach you “why” the meeting exists. The daily check-in is meant to serve to ensure, despite personality and communication types, that the team is talking each and every work day. That you can’t be agile if you aren’t talking to your teammates. (Individuals and interactions over processes and tools, right?)

A team might forego standups entirely if they’re communicating other ways, such as pair or mob programming. Teams may choose to do them at different times during the day, change the format to something like Slack or Microblogging, switch the frequency, or any other number of changes. But the important part is that they’re communicating and helping each other move the work forward. However that happens is agile, but not necessarily Scrum “by the book” as trained Scrum Masters like to say.

In fact, every efficient and productive team I’ve worked on has ignored the concept of sprints altogether; people are more focused without them, they communicate better.

– I Don’t Believe in Sprints