Scrum is the most broadly used agile framework nowadays. My observations confirm that. Whenever there is a question at meetups or conferences about the method the audience uses, Scrum collects the most risen hands. During job interviews I have a chance to learn the same. But what I also notice is that people sometimes don’t really understand the why or how. They just follow some ceremonies, that are often flawed, without any deeper understanding. Actually, I am guilty of doing the same. So here I share a list of things that people confuse, consciously or not, and provide some explanation.
Scrum is not a Silver Bullet
I used to play in some metal bands in the past. I stopped, for numerous reasons, but later wanted to get back to playing. I was a Scrum practitioner, Scrum was working for me (or to be more specific – it was better than waterfall, which I had experienced before), so I wanted to apply it to band forming. It was really funny. Band mates were confused to say the least! And you know what? It didn’t work. Surprise, surprise.
You may laugh (I can hear that!), but I learned that you have to be pragmatic with such choices. You need to learn other approaches and be open to new ideas. Mastering only one is dangerous, because if all you have is a hammer, everything looks like a nail.
Some teams and companies use Scrum because of its popularity and accessibility. It’s easier to read 16 pages of Scrum Guide than books about Lean, Kanban or others. Besides, it’s effortless to get certified Scrum Masters (or to get certification yourself), to be trained by certified Scrum trainers and so on. It’s safe and seems to be easy.
Yet sometimes (or maybe – in most cases) Scrum is not the right choice, and definitely not the only viable possibility. In order to choose well you need to learn what other solutions are available, get the best parts from them, and use them wisely. And not be afraid to modify your process.
Scrum is not a Religion
Recently I attended an agile community meetup and there was a really awkward moment for me. I was listening to the speaker and suddenly he asked the audience about the Agile Manifesto. People started to recite the whole content in unison, like a prayer in a church.
It was not the first time I have faced a religious approach to agile. I was also guilty of acting like a Scrum priest at times. I was questioning how scrummy this or that practice is, and whether we are doing Scrum or “Scrumbut”. Hey, I was a Scrum Master after all! This produced funny situations, for instance when priorities changed, we wouldn’t adjust the sprint backlog, because this is forbidden in Scrum. Stakeholders were really happy with that…
The bad news is that nobody pays you for using pure Scrum (unless you’re a Scrum trainer). Companies pay for doing a great job. So instead preaching about the sacredness and greatness of Scrum, think about what may work for you and your team. Don’t be a zealot.
Scrum is not only a Set of Practices
Really, doing standups will not make your business tick. Nor planning sessions, backlogs or product owners. They may help, but that’s not the whole story. Implementing practices without building the right culture and living agile values is destined to fail, or at least to not make a real impact. And that’s the hard part, because changing how people think is not an easy task.
Scrum is a product that supports agile values and principles, it has its own principles as well. Those principles and values are something you should be looking at and striving to embed in your environment, rather than obsessing over Planning Poker cards. Practices are just practices.
Scrum is not a Process or Methodology
Yes, I know this may be considered a religious dispute, but my point here is not about names, but rather the understanding about what is and what is not a part of a Scrum framework.
Maybe I was unlucky, but whenever I was taught Scrum, there have also been User Stories, Planning Poker and other practices that are not actually part of the framework. At the time I was too green to distinguish what really was a part of Scrum and what wasn’t.
If this picture is taught to fresh adopters of Scrum it may also mislead them. Because they were told to implement Scrum as a whole, otherwise there’s no guarantee of success, they’re afraid to change User Stories to something else. Story points, tasks, Planning Poker and release planning are NOT a part of Scrum. There are a bunch of other practices to use instead if you need them. Do you?
The message I want to send is that you should not blindly use any framework, methodology or process without really understanding your problem and what other options you have to solve it. Use each new or trendy idea as an inspiration rather than a prescribed solution for your problem, because the chances are very high that it wasn’t developed to help you with your challenges.
Do you agree with all of this? Would you add something to the list?