5 pitfalls to avoid when starting with Scrum

1. “Scrum… Why explain? Let’s just get started!”

I am definitely an advocate of starting and on the way discovering what is going well and could be better. But when you start with Scrum, it requires a different way of thinking from the team. Much more focus on just one project. Often it means a completely different way of thinking and working. And as logical as Scrum is, it’s new to many people. The terms are new, the short iterations are new. Super focused work in sprints is new. Collaborating with the customer on the team is new. Provide a soft landing and introduce them to Scrum so that throughout your first Scrum you are playing the same game with the same rules.

“The time you put into preparation with your team will pay off in speed and job satisfaction more than double during the first and subsequent Sprints.”

“Starting 20 projects at once” 2.

When you start with Scrum, there are often 20 projects already mixed up in your department. After all, that’s the way you’re organized now. Why not convert all these projects to the Scrum way of working at the same time? After all, then everything is immediately organized Agile.

In Scrum, you work focused on a project and finish it first before starting another one. 20 projects at a time, we don’t really believe in that at Scrum. When you want to make speed, it’s much more effective to focus. Starting with Scrum starts with prioritizing which projects (in the eyes of the Product Owner) are the most important. So this also immediately determines what not to work on. And that is what the team, the Product Owner and the rest of the organization must stick to. If you do not do this, in no time you will have another 20 projects running at the same time, which will not be completed, where there is no grip and the job satisfaction of everyone involved will disappear. And was that precisely the reason why you wanted to embrace another method such as Scrum? Exactly.

“Prioritize the projects. Dare to choose. Get up to speed. And enjoy finishing”

Scrum master and Product Owner in one” 3.

When starting with Scrum, both with the Product Owner on the client side and a Product Owner on an internal project of your organization, it is important that the Product Owner is actually part of the team. With mandate. Scrum is a role-playing game. Things like “no time,” and “deciding things for the Product Owner because he is not present” are killing in Scrum. It takes the speed out of the process, causes just the wrong stuff to be made by the team, and the grip on the project is lost. Exactly three advantages you wanted to gain from Scrum are killed this way. So don’t do it. In addition, you want the team to become self-managing. Because you take on the role of both Scrum Master and Product Owner, you effectively take over the entire management of the project. What will happen when something doesn’t quite work out in the team? Exactly … the team will sit back and expect you to fix everything. And that is exactly not what you want. It is important that everyone understands and plays the role-playing game. The Product Owner decides on the business value to be delivered by the team. The team is fully committed and the Scrum Master facilitates the team and keeps it up to speed in good cooperation with the Product Owner.

4. “We work on the project in between and not on set days.”

Asking an existing team to Scrum on fixed days within an established structure and culture often meets with resistance. Working multiple days on 1 project? What about all my other work? How will that be finished in time? And all those other questions from other departments and managers who claim my time at my desk? Can I just dismiss them like that? To start with the latter: Yes, you can safely refer them to the days when you are available. This really takes some getting used to for others, but when management has expressed that this agile way of working is being experimented with, the space is also there to work dedicated and not get distracted. Scrum with each other on the same days. This ensures rhythm and speed, easy mutual coordination, taking decisions on the spot (no emails that take another week to be answered) and clarity to the organization when you are and are not available as a team. People are rhythm animals. The stand-up, the reviews, the demos, they all start at this time. Then it’s also convenient when everyone is there. For example, start with three days of dedicated work on a project. The other two days are entirely devoted to getting rid of To Do’s from the other work that also needs to be done.

5. “We just start with just a scrum board.”

Scrum is full of principles, concepts and events. That in itself is not rocket science, but it is designed so that all the cogs are connected. This Scrum machine ensures speed, quality and grip. So it works optimally when you start working with all concepts and events at once and not just with, say, a Scrum Board. This board helps teams on their way: after all, there is more overview and more interaction and alignment in the team. This is perceived as pleasant and quite an improvement step. But a Scrum Board is also just one of Scrum’s tools. For Scrum to work, all the wheels have to turn. The best thing when embedding it in your team, is to name 1 project where you apply Scrum all the way (all the concepts and events). Make it something special, something cool. Even if it’s uncomfortable for the team and yourself. You learn together along the way. Inspect & Adapt. Is there resistance in the team to all these changes? Then agree to give 1 full sprint a chance and have the team’s commitment to it. The retrospective is already scheduled, so everyone knows when feedback is allowed. The length of 1 sprint is also fine for most people to work on this. And a nice length to experience the benefits as well.

“Embedding Scrum into your team and organization requires customization.”

Experiment and learn mostly what works for you. In other words, Inspect & Adapt. But do that with all the ingredients of Scrum. From role play to the events and the application of the Agile principles. Only then will you achieve the benefits of speed, high quality and grip! Inspect & Adapt and let Scrum work for you!