Why It's Unwise to Start with Scrum as Your First Step

A Drum Beat Implementation Roadmap: Which Step Is Done When and Why

Uwe Mierisch

Sep 08, 2025

Article voiceover

0:00

-16:23

Agile project management is based on Scrum.

That's how it all started, so let's introduce Sprint meetings and Scrum boards first.

Once that works, we can scale up and think about the higher complexity in projects.

Makes sense, right? That's why I often see teams taking this approach.

Noooo, that's not the right way to do it!

I used to do something similar myself. Back then it wasn't called Scrum - it was called Shop Floor Meeting.

But I found that it didn't really solve the problem. We still had issues with the quality of our development projects.

So in this article, I'll describe how to do it better - a way that actually makes the problems go away.

Starting Point

I think it's important to thoroughly analyze the starting situation before any project, change, or transformation.

So let's recap what we have and what we want to achieve with the Drum Beat method.

We use classic project management in our projects, just like it says in the IPMA textbooks.

Well, we say we work according to IPMA. In the end, it's probably more like freestyle.

We have a project plan,
project managers,
project team members,
and defined project roles.
We also have quality gates,
milestones,
and quality gate deliverables.
We have project traffic lights,
reporting,
risk management,
and project documentation.

That's good news because it means we don't have to start from zero. There's a foundation we can build on, even if it's not perfect yet.

What were the problems I wanted to avoid with the Drum Beat method?

The project plan doesn't work as desired.
Deliverables for quality gates and milestones are delivered poorly.
Project budgets and timelines get out of control.
Quality and performance of the developed product is compromised.

The next step was to identify the root causes of these problems and define countermeasures.

These countermeasures are the processes and roles I've explained in my previous Drum Beat articles.

To find the smartest implementation approach, I need to look at these causes again and prioritize them.

I can't tackle everything at once - that would overwhelm people in the organization and possibly ruin the whole implementation.

Here's the prioritized list of causes:

Project milestones are too long-term and too big
Poor prioritization of project activities by importance
Too late identification and correction of plan deviations
Poor resource management
Poor coordination of project activities between service providers and recipients

Based on this analysis, I can now stagger the introduction of Drum Beat elements over time. This way, I first create the prerequisites that enable the implementation of further process steps.

Here's how it works:

Step 0: Project Plan and Project Team

As I mentioned at the beginning, the project plan and project team already exist.

Even though they're far from the state I think is necessary, we'll leave both as they are for now.

The project plan is good enough to provide guidance for how the project should flow, and the project team is motivated to implement the plan.

That's enough as a foundation for the start. We won't waste energy improving this now - we need to work on more important issues first.

Only later, when the team has a clear understanding of what Drum Beats and ToDo Sprints can deliver, will we have the foundation to take the project plan to the next level.

Step 1: Define Drum Beat Deliverables

The change starts with Drum Beat Deliverables.

Drum Beat Deliverables are the heart of the transformation because they give the team a clear understanding of priorities in project work and management.

Only when Drum Beat Deliverables have sufficient quality can the other process steps produce meaningful results.

For this reason, the project management team must first learn how to derive and properly formulate Drum Beat Deliverables from the overall project plan and the current project status.

This isn't easy when you've never done it before. That's why it's important to support this implementation step with trained resources.

We need people who already know how to do this and can provide guidance and assistance to the project management team.

The transformation team itself needs to be involved in the planning and provide guidance to the team.

Usually, this manpower won't be enough either. We also need external consultants with agile project management training.

So everyone speaks with one voice, the transformation team and consultants must align their concepts before planning begins and agree on a common understanding. It's recommended to practice Drum Beat planning beforehand.

On this basis, both can now work together with project team members to define Drum Beat Deliverables and develop the templates I described in my article "Drum Beat Deliverables Create Clarity - and Deliver the Truly Relevant Results."

You will notice that Drum Beat Deliverables show strong qualitative improvement over the first three to four Drum Beats.

I recommend adjusting the method slightly after each Drum Beat.

In this case too, you should do a retrospective after each Drum Beat and implement what you learned in the very next Drum Beat.

Even though the following process steps aren't implemented yet, you'll still notice an improvement in project work. This is important because it promotes acceptance of the method.

Pay attention to positive feedback from the project team and make sure it's noticed throughout the organization.

Step 2: Conduct Planning Event

Even the first Drum Beat planning ends with a Drum Beat Planning Event.

At the beginning, this will also be organized and moderated by the transformation team and consultants.

The entire project management team is present. The functional area representatives on the project management team take on the role of functional area teams in one person.

We don't want too many people involved at the start so it stays manageable during this rough phase.

We pay the price that the actual project team isn't involved yet and can only be informed about the results afterward.

It's clear this leads to poor understanding and commitment from the project team. We have to accept this.

The priority is first to enable the core project management team and establish an initial content foundation.

Step 3: Implement Project Roles

After Drum Beat Deliverables are introduced and the team can produce sufficiently good results with support, we now need to ensure the team can manage on its own.

For this, we need to implement the new project roles.

Usually, the project will already have a project manager.

So we need to select, train, and coach:

We also need to redistribute responsibilities.

The project manager gets relief and focuses more on project content flow, while the Project Management Master takes responsibility for the method and the architect for the product.

The transformation team and consultants step back more and more, hand over responsibility for the process to project team members, and only support when necessary.

Step 4: Implement ToDo Sprints in Pilot Teams

Now we've created the foundation.

The Drum Beat Deliverables have quality that reliably provides guidance, and the project management team can independently plan, formulate, and manage DBDs.

Now it's time to involve the implementing functional teams.

The transformation team and consultants shift their focus from the project team to the functional area teams.

Project team employees now need to plan the activities required to realize Drum Beat Deliverables into ToDo Sprints.

This needs the same kind of support at the beginning as we organized for the project management team in step 2.

Since support resources are limited, we focus on selected pilot teams at first.

We identify teams that are particularly relevant to project results and whose employees are open to the new method.

These teams are now also included in Drum Beat Deliverable planning and planning events.

Even though only the pilot teams are currently implementing ToDo Sprint planning, all other project employees are already being trained. This way they are prepared for the next step and won't have forgotten what they learned when they need it.

Step 5: Roll Out ToDo Sprints Completely

In the next step, our pilot teams serve as role models for the rest of the organization's employees.

Now everyone participates in the ToDo Sprint Planning.

The pilot teams' ToDo Sprint backlogs serve as examples, and pilot team members are available as contacts for other teams.

This significantly increases the number of employees available for guidance, so we can provide adequate support to all employees despite limited resources from the transformation team and external consultants.

Step 6: Dashboards

Now all process steps are implemented.

To work with planning and continuously improve processes and results in a targeted way, we now need dashboards that show the project team how DBD and ToDo processing is going.

Of course, we've had DBD and ToDo boards available and used them in our project management tool from the beginning.

But now the focus shifts from the content of DBDs and ToDos to their flow.

The transformation team and consultants now support the project team in working with the boards:

Are DBDs and ToDos properly moved from “Backlog” to "In Process" and "Done"?
Is the "Roadblock" column used correctly?
How does the team work with statistics?
Are emerging delays addressed in time?

The implementation focus shifts from planning to execution.

Step 7: Perfect Project Plan

So the new process steps are now implemented.

Now we can return to the project plan and adapt it to the new method.

Since we now map many planning scopes and activities through Drum Beat Deliverables and ToDos, we can streamline the overall project plan so it really only contains the essential and long-term relevant planning components.

It should provide guidance for DBD planning but not create duplication in planning.

I like to refer to an old engineering rule. Maybe some of you still know this rule, even though it comes from a time when technical drawings were still drawn with ink on transparent paper:

"Each dimension may only exist once!"

The background is that contradictions are avoided by having no duplications. If a dimension exists only once, it can be wrong but not contradictory.

This principle also applies very well to planning and avoids one cause of misunderstandings.

It means each task should only exist once in planning. What's in the project plan shouldn't be in the Drum Beat backlog, and vice versa.

7 Steps Take Time

So I've divided the implementation into seven logically connected steps.

It follows agile logic - always focus on the next important step and implement MVPs instead of waiting and doing everything at once.

Due to agile thinking, there's a retrospective after each Drum Beat, and we improve the identified potential in each following Drum Beat, so we become better, more efficient, and more effective.

Want to introduce Drum Beat in your organization and still have questions?

Write them in the comments and I'll try to answer them to your satisfaction.