ROUTINES REDUCE FRICTION AND GETS THINGS DONE
It is always a good idea to remove as much friction as possible. And with friction I mean the resistance to get things done, to start and to keep doing it. There are many ways to do that, and one of them is to have routines. But what does that have to do with Scrum?
Routines are learned behaviour. An order of operations that you don’t have to invent every time. You just know what to do next. This speeds up things, and it consumes less energy. Scrum is actually a set of routines that removes friction.
Scrum is a well-defined process. It has several pieces that build a pipeline of work. Each piece defines what, and to an extent how, you should do things. In other words, it makes sure that you do the same thing, the same way, every time. Now, if this isn’t a routine, I don’t know what is.
Let’s take the user story as an example
You could describe what you want to develop in just any way you want. And then you discuss with the developers what you mean. But by adding a pattern to how you describe it, you add clarity, and you add certainty. We can rely on that information we need is always present.
As a {stakeholder} I want to {do this to solve the problem} so that {this problem described here goes away}.
In each user story you can expect to always know who you are solving the problem for, which is kind of important since you will solve a problem differently depending on who you are solving it for. A person that uses the system occasionally will have to get as much help as possible to do it right, while a power user, that has the system as her main tool, is much more interested in a streamlined process.
By having the routine to always use the user story template, you know that you always have this information available. The author knows to put it there, and the developer always have it.
Likewise, you will always get information about what the problem is and what the solution should be. All this information has also been designed into the user story. You don’t have to think about what information you need to add, you just add it.
Friction removed.
Each scrum activity removes some friction
Scrum is a series of well-defined activities, each designed to solve a problem. These activities are repeatable, and they are done in the same way each time. You know what is coming and once you have learned them, you do them without thinking much about it.
Scrum is a series of well defined activities, each designed to solve a problem. These activities are repeatable, and they are done in the same way each time. You know what is coming and once you have learned them, you do them without thinking much about it.
Write a user story. We covered that above. But still, we have communication protocol that always gives you the information you need.
Prioritize the backlog. Now we know which story to do first. No need for endless discussions every time you start with a new story.
Refinement. (A.k.a grooming.) You make sure that you understand what the story is about, find out what information that is missing. Talk to the stakeholders when things are unclear. It makes the team decide on architecture. We now have all the information we need to actually develop the story. And we know we have it.
Add story points. It makes sure that everybody in the team has understood what has to be done to solve the story. It shows the stakeholders how much work it actually takes to do it, just by a glance. And it is a help in deciding how much work you can add to the sprint. That’s a lot of friction gone.
How to write story points
Story points are not estimated time
Sprint Velocity. After having done a few sprints, you see how many story points in average that you can manage to finish each sprint. This becomes the guideline when you plan the next sprint. Gone is the need to negotiate and guess how much we can manage.
Sprint planning. We just pull the stories from the top of the backlog, add up the story points from the stories we pull, and make sure that we don’t move over the team velocity. Could planning ever be simpler than this? More frictionless?
The Sprint. You focus on development. You know what to do, for whom you are doing it, the architecture to use, and so on. There’s no need for gathering information about what to do, since you already have done that. With many of the big sources of interruption removed, you can focus on the development. Get into the flow. Write the code. Deliver.
Daily Stand-up. A time to make sure that there are no problems, and if there are, get help. A time to share information. A time to sync the development in the sprint. So we don’t have to interrupt each other all the time. Now, we will of course do that anyway, but not as much. And since we do this at the same time every day, we don’t get interrupted in our works, it is a part of our work.
Unit Tests. Write once. Let the compute execute many times. Never, ever, ever do manual testing of code again. That’s low friction! And now you have time to focus on the things that only humans can test instead.
A list with all articles related to unit testing
Sprint review. Syncing with the stakeholders to see if we actually solved their problem, and to find out if we created any new. Do it now when the issue still is fresh in our heads. It is a part of the work, it’s part of the flow. We correct things before we’re done with them. Which means we can let go of them, never think of them any more. A lot less baggage to carry around.
Retrospective. The process that is designed solely for removing friction.
Find out what is causing friction in the process right now and find a way to fix that.
Find out what is working well and find a way to do more of that. Super charge it.
Conclusion
As you see, Scrum is a long series of routines that is designed to reduce friction in the process. And they are in many ways depending on each other. Like story points and sprint planning. It is important to understand the entire flow to succeed with scrum. There is much more to each stage than you might think at first glance. So, good luck!
— Cheers
