Even though the year is still young and still cold, I have already presented two training courses. One on microservices for a transportation company. And one on agile for teachers at a high school who want to adopt agile techniques to their classes. Although the topics were quite different, attendees at both courses had a similar background in doing agile: Scrum.
For those of you who know me a little bit. It shouldn’t be a big surprise that I’m not very keen on Scrum. Or to put it more precisely, I don’t dislike Scrum. I merely resent the way many consultancy firms are implementing it at clients. And I certainly don’t appreciate the firmness and strictness at which many organizations use Scrum in projects.
One path leading to the truth
To many, Scrum has become the one path leading to the truth. A strict process with ceremonies to follow in full obedience. Scrum has become a goal, and not a means to a goal. I’ve seen many organizations who have completely stopped thinking once Scrum was in place. Imagining Scrum will solve all issues. Which it doesn’t.
Let me give you an example. Most Scrum teams start a new sprint with a sprint planning meeting. A typical Scrum ceremony. During this meeting the team establishes a list of items, often called stories, that they can handle during the sprint. Although I need to write a post about this inefficient event some other time, I will now focus on what comes after sprint planning. Refinement.
The whole team
During refinements, teams try to get a common understanding of the stories they will be working on during the upcoming sprint. They go through all the stories and add as many details to them as they need to start work. In the past twenty years, I’ve witnessed many teams working according to Scrum or Scrum-like procedures. Many of these teams start refinements right after the sprint planning meeting. And as it so happens, the full team is present at the sprint planning meeting, and so the full team stays around for refinements as well.
This might be a good idea. As said, doing refinements creates a common understanding about the stories the team will work on. So far so good. But the thing is, what will happen is that the full team will join in discussion on every individual story. With twenty or so stories to go and seven to ten people in the room, your refinement session will take up quite some time. Often between two to four hours. With the whole team. On a two week sprint. Recognizable?
Ok, refinements do create a common understanding about all twenty stories. However, in real-life those stories are never worked on by the whole team. Only two or three members of the team will actually work on a particular story. So while ten people spend twenty minutes discussing a single item, only three of them will actually analyze, built and tested it. Not very efficient is it?
Even worse. From teams around the world I’ve had complaints about refinements sessions. They’re boring. They last too long. If you only work on three to four stories in a sprint, participating in the design in fact of sixteen more can be quite a challenge. Not my words, but those of people in many Scrum teams.
Timing
There’s another drawback to refinements at the start of a sprint. Timing. Let me explain that. Doing the design of your stories at the start of a sprint may seem just-in-time, but you could in fact be even more just-in-time. If you don’t start on a particular story until the third week of a sprint, there’s still a waiting period.
And it could get worse. As you all know, we are not very good at estimation in software development. Not in the large, but not even in the small. Want proof? Think back of all the sprints where there was still work left when the sprint was over. Stories that you didn’t finish. Or worse, stories you didn’t even start on. You’ve been there. For sure.
As a consequence these unfinished stories are moved to one of the following sprints. The period in time between the design and implementation of such stories grows. In the end, these stories might event not be implemented at all. Still you have already done the refinement of those stories.
As an example, I audited a project project in Brussels, Belgium a few years ago. When I got there they had already finished thirteen monthly sprints. Everyone of these sprints had ended with unfinished stories remaining. Some of the stories had been on the sprint backlogs for over four months. Expensive stories.
YAGNI
At this point you might think that there’s no other way of doing refinements. You’re already doing refinements at the start of your sprints. That seems efficient. And by the way, this is what Scrum says it should be.
Yet, there is one thing you could do. And that is too look more closely at the YAGNI principle. I you are new to this acronym, it stands for You Aren’t Gonna Need It. In my opinion, YAGNI is best established when you try to maximize the amount of work not done. That is, only do the work now that you need to do to take the next step. Defer all other work. Take all decisions as late as possible.
Sounds contra-intuitive? Actually, looking only at the work that need to be done now, has some advantages. First of all. If you defer decisions to a later moment, chances are that you gain a lot of insights on the topic in the meantime. This allows you to make better decisions. Secondly. When you defer work to a moment when you actually need it to be done, you can be sure that you will work on stuff that is still required. It might be changes, but it wasn’t dropped in the meantime.
Abolishing refinements
So let’s rethink what the best moment is to do the design of your stories. Is that really at the beginning of a sprint by the whole team? Stories are not realized by the whole team. Only by two or three team members. Also, stories are not realized immediately after refinements. On average a week (or two) later. Or even worse, in a later sprint.
For these reasons, I have abolished refinements in my projects. The best moment to do the design of a single story is right before you start writing code to it. Not two weeks or two sprints before, but rather half an hour before. In my projects, when members of the team pick up the next story, they organize a design session and elaborate only on the story at hand. Just in time.
Usually these design sessions are held right after a daily stand-up meeting. Everyone who needs to be there, is already present. The product owner, the analyst, the UI designer, the developers, the tester. Depending on the size of the story, these design sessions take about thirty minutes to an hour. They end with a common understanding of that single story. Sometimes there’s a domain model, a REST interface, a page mock-up or a use case scenario. With just-in-time design sessions, there’s no need any more for refinements at the start of a sprint. Just get rid of them. Don’t be bothered by what you think is the correct procedure according to whatever process. Stop doing refinements. Organize your design sessions on any day in any sprint when you need to design. Continuously.