Often something comes to my attention. Scrum by the book. Teams who are new to scrum often tend to start doing scrum as it is written. And in most cases these teams run into problems, or better yet, challenges that are not written down. What to do with team interruptions. What must you to do with colleagues who are in transition from their old roles to new ones. Dealing with the company or other departments that not yet use any kind of Agile working model. These things are written somewhere in a book. I have read a lot of them en most of these books are a bit in the higher scrum knowledge zone. Not yet to be picket up by starters. Don’t get me wrong there. As a beginner you can pickup any book about scrum, userstories, coaching or whatever. But as a beginner it is hard to see what is theory and what is the real world.
But there is nothing wrong in doing scrum by the book. Even for an experienced team it is sometimes good to go back to the basics. In my experience it is very likely that along the way when implementing scrum you tend to forget certain basic rules. Small things getting out of hand. By getting back to the basics, these things can be solved quickly and clearly. Take interruptions for example. One of the first “real world” things you might encounter when starting with scrum. While running a sprint with a estimated set of userstories it sometimes happens that something is shoved in. New Un-estimated work that is somehow urgent. Urgent because someone outside of the team forgot to mention it or put it on the backlog. When you have people who are not yet solid in their scrum role or an inexperienced team. And even a business unfamiliar with the Agile way, it happens that everything is dropped to solve the new problem. But is that wise. Scrum suggests that workitems not on the backlog shall not be worked on by the team. A sprint is not interrupted and the team has the right to say no to new work that has noting to do with the current goal.
If an alert Scrummaster says no to work to protect the team, all sort of thing are going to happen. Product owners get pressured to pickup the work. The team is urged to do the work because otherwise bad things might happen. Unpleasant things. And so the work is done, bringing the sprint at risk. Sounds familiar? And it is so simple and textbook material. Just say no. Say no to the new danger that comes into the team. Let the team do the work they are supposed to do and committed to do. As long as servers don’t crash and sites go down, nothing will happen when the extra work is not picked up. And why is that. In most cases, extra work items or urgent userstories are forgotten work. How come it was forgotten to be mention during the planning sessions. Why did it suddenly popup from nowhere. Why wasn’t the work on the top of the list. Because the new work is not important. Do mind, I’m not talking about a live environment that suddenly goes black. If that happens everyone should get involved to get it back online again. Don’t panic but do the job. But work that someone forgot and suddenly was found in a drawer somewhere cannot be priority work that is allowed to interrupt the team.
So give this the “Scrum by the book” approach. Don’t do it. Put it on the backlog for the next sprint and keep the goal clear. And the statement that before scrum this was never a problem is nonsense. I’ll bet that before scrum was implemented in your team, everybody was running. And everything was important and urgent. And after the scrum transition only a few of these so-called urgent work items shows their ugly face. They are probably the last few remainders of the old way. Deal with them, but stick to the program. When in doubt or when you loose control or overview in the scrum process, just go back to the basics. Oddly this always seems to work. Use scrum in its basic textbook suggested way, and things will be solved. It is so simple.