Opinion
Scrum without magic
When a team decides to adopt Agile, and Scrum in particular, too often they have that attitude — that once they perform all the magic rituals everything will magically work. Then it doesn’t happen.
It is true that Scrum sometimes resembles a cult.
Even the meetings are conveniently named “ceremonies”, as though there are no meetings in Scrum but there are magic rituals instead. And countless Scrum coaches and consultants look and speak as cultists.
When a team decides to adopt Agile, and Scrum in particular, too often they have that attitude — that once they perform all the magic rituals everything will magically work. All the problems will disappear. And if they keep repeating the spells, performance will go through the roof as well.
Then it doesn’t happen. People become disillusioned and disappointed. They go and write countless articles on the Internet arguing that Scrum is a fraud and simply doesn’t work.
Well, Scrum is no magic. Despite all the terrifying words and charming coaches, Scrum itself has no power. It cannot solve any problems by itself.
So what?
I’m not a Scrum expert. I’m a software engineer. You don’t have to listen to me. But when I started having an interest in Agile, I became amazed at how many people only imitate Scrum, without any particular requirements or goals.
There’s a whole universe of Scrum: millions of articles, courses and books, thousands of talks, certifications and trainers. So many words — but so little action.
The framework
Let’s talk like engineers. Scrum is called “framework” for a reason. Like many frameworks, it doesn’t give you the code to solve your problem, it only gives you a structure. Then it is your task — as a Scrum Master, Team Leader or an engineer — to fill in the blanks.
How do you write that code? I have an idea. It may sound strange to many people, but here it is: instead of all the talking, do things. It really doesn’t matter how you call this or that or how beautiful your Burndown Chart is. What matters is if your input gives you the right output.
Sprint as a function
Input: tasks.
Output: an Iteration.
Sprint is the cornerstone of Agile. The most important function. It’s not just a word, or a ritual, or a mere two weeks period. Many teams just shove some tasks in the beginning, then, at the end of the two weeks, they pass what’s not finished to the next “Sprint”. This is not a Sprint, it’s only an imitation.
Every Sprint is supposed to start from a blank page. A good function is idempotent.
Also, Sprint doesn’t serve as a metric tool for a manager. A Sprint is only measured by results, by its output.
Sprint is a function, an action that should produce an Iteration — something that works that didn’t exist before. Something you can demonstrate.
If your work is not iterative — maybe you only solve unsorted bugs, or you’re building a satellite — then you shouldn’t attempt to divide your process into sprints.
“Ceremonies” as functions
They may be called ceremonies, but don’t be confused — in the end, they’re just meetings that, if run efficiently, can be functions and produce results.
If a meeting doesn’t produce output then it should be run differently or removed from people’s calendars. If a meeting is a ritual it’s just a waste of everybody’s time.
Importance of time
Usually, engineers don’t like too many meetings. Almost nobody likes a long meeting. If a meeting doesn’t have a clear goal it becomes a torture. If a meeting doesn’t produce any result, it feels pointless. If a pointless meeting repeats regularly, it feels like a ritual.
If your Scrum is made of rituals it is an imitation — shouldn’t be a surprise to anyone when people start complaining that it doesn’t work.
Standup
Input: Team members’ reports
Output: Plan for a day
Millions of words are written about standups. They usually focus on the “people” side of things — report to each other, don’t get distracted, stay within the timeframe. All these points are valid. But why exactly do we do that? So “everyone knows what everyone’s doing”. But why?
They should know in order to plan their day.
Backlog Refinement
Input: Requirements
Output: Clearly defined tasks, all written down
The Backlog Refinement takes raw requirements and converts them to clearly defined tasks.
Clearly defined — this is important. No questions should be needed after the meeting. Remember these tasks will go further through the pipeline and get back to you during the Sprint Planning.
It the Refinement is unproductive it will make the Planning unproductive.
Also, Planning Poker is not just a boring game. The “how” is not important. What is important is if you can quickly decide collectively how difficult the task is.
Estimations define the sprint, the sprint defines what you will be working on and how hard. If the Poker actually makes a difference, then everyone will be interested.
Sprint Planning
Input: Clearly defined, prioritised tasks
Output: Plan for a Sprint
The Sprint Planning takes what’s Backlog Refinement produced, divides it and converts to a Sprint.
The main thing about the Sprint Planning that it should be serious. When you plan the sprint and “commit”, it shouldn’t be just a symbolic gesture — you decide what you’re going to work on. This will be an increment you’re going to have to show to your co-workers.
Retrospective
Input: Team members’ thoughts about the sprint
Output: List of actions to implement
Once I worked in a team where Retro was a time when everyone shouted at one another and complained. In another team, Retro was always quiet as everything was apparently great for everyone.
In many teams, Retro is just for managers — the engineers just wait to go back to work.
The Retrospective should collect everyone’s opinion about the work process and produce a list of actions. And then these actions should be acted upon.
If the Retrospective doesn’t produce any improvement then it feels like a waste of time.
Demo
Sprint Demo exists to make sure you’ve produced an Iteration. If you don’t have anything to demonstrate, maybe it wasn’t a Sprint?
The circle
Think of Scrum as a flowchart of Lambda functions. As the process is iterative, they inevitably form a circle.
… Improvements -> Backlog Refinement -> Backlog -> Sprint Planning -> Sprint -> Standup -> -> Demo -> Retrospective -> Improvements …
It’s a data pipeline, really.
The right framework
Scrum doesn’t create a process for a team. As a framework, it can only help with the structure. It is on the team to write the “code”.
To make it work, we shouldn’t care about being cool or doing things right. We should care about the results.
Although there’s a lot of talk about how cool and fun it is to be agile, Agile really is about discipline. It was created as a framework to navigate through the chaos of ever-changing requirements.
Scrum doesn’t have to be fun. Well, it doesn’t have to be boring either. Best if it is just invisible. Most importantly, it should not distract people from working and should not add more chaos than there already is.
And yes, sometimes Scrum is just not the right choice for a team.
