ToDo-Sprints: How Activity Planning Prevents Project Delays
Methodically organized, short sprints eliminate misunderstandings and ensure reliable delivery of important results.
As a product development leader, I regularly attend project review meetings where we discuss the status of important product development projects. In these meetings, project teams typically present two very different types of topics to top management:
1. Technical Concepts and Product Performance Reports
For these agenda items, project teams seek management confirmation and approval for technical approaches and performance metrics. In these cases, management takes an active role in the decision-making process, providing valuable input, strategic direction, and meaningful oversight that actually adds value to the project.
2. Project Delays and Missing Results
The second type of agenda items puts management in a completely different role. Here, project delays and missing deliverables are presented in detail. Teams explain what went wrong and outline their plan to mitigate the consequences of this mess. These presentations carry an undertone of: "We want you to know how critical the situation is. Don't be surprised if things ultimately go wrong - everything we're doing is without alternatives because lost time cannot be recovered. We hope the plan works, but you can't help us anyway." There's not even an expectation that leadership can still help. And believe me, these agenda items are no fun for management!
To change this situation for the better, I've been exploring how to prevent it from happening in the first place.
There must be a way to manage projects so that critical delays don't occur at all.
However, if they do arise, the goal should be to present decision alternatives to management early enough so their decisions help prevent problems from escalating in the first place.
If we succeed in this, management will have a positive value contribution for both types of agenda items. And ideally, the project team will solve problems early enough that many of them will not need to be reported at all.
One aspect of the solution is the "Drum Beat" that I've introduced in previous articles. This helps project management teams plan more realistically, recognize project risks earlier and proactively avoid problems through better planning.
The other important aspect that needs to be addressed is guaranteeing proactive work management in functional departments. Since project content is created in functional areas, these employees must be included in solving the problem.
The method to achieve this is the ToDo-Sprint - designed to make task processing more prophylactic, effective, and integrated. I'll focus on this aspect in today's article.
But first, let me dive deeper into the fundamental root causes of project delays. I'll explain the causes I've identified so you can consider whether these might also exist in your organization.
From these causes, you'll understand why a combination of Kanban and Scrum can solve the problem.
Multitasking Needs Clear Priorities
I work in a matrix organization.
In my article "Mastering the Matrix" I wrote about the special characteristics this involves. Take a look at that article - it should help you to understand this point better.
When project organization (as process organization) and functional organization (as structural organization) are arranged in a matrix, there's typically no unique assignment of employees to projects. A functional team works simultaneously, but with different intensities, across multiple projects.
Without a process to synchronize, prioritize, and organize all these tasks - as was the case with us - tasks remain uncoordinated. The affected project learns too late what won't be delivered in time, putting it into a reactive mode where it shouldn't be.
We need a working mode that ensures project-wide planning of all activities within functional area teams.
Since we're talking about teams with normal employee numbers (5 to 10 people), we can use a setting similar to agile Scrum.
Employees plan their activities together in short cycles, considering the concrete situation as it currently exists.
To avoid ineffective multitasking, we need "timely dedication" - temporary focus on a single activity planned so that all important results for all projects can be delivered.
This means that while work may be done on multiple activities for different projects within a sprint, at any specific time (hour, day) work is done on only one task. Only when that's completed is the next one tackled.
The Scrum Board structure with categories Backlog, In Progress, and Done works perfectly for this.
The "Roadblock" category signals urgent support needs for the team.
With this approach, emerging problems are recognizable on a quarterly or weekly basis, and solutions can be sought and found proactively before time runs out.
Capacity is Objective
The truth is brutal and unavoidable: capacity is finite.
Because this insight is so uncomfortable, management tends to use the ostrich method - sticking their heads in the sand and preferring not to talk about it.
"They'll figure it out somehow. They should just try harder, then it'll work."
This attitude puts management in the position of later sitting helplessly in project reviews, feeling bad anyway.
It's a non-delegable management task to consciously evaluate whether it really "still works" or whether resources are objectively insufficient and decisions must be made.
I'll explore what decision options management has in these situations in a future article.
But to even be able to decide, there must be a planning process where these cases are uncovered early and prophylactically, showing the team and the management the decision alternatives.
The Scrum approach also helps with this problem.
Since planning occurs over short-term intervals (quarter, week), resource availability is easily assessable. The workload is also concrete since the status quo on which the activity builds is clearly on the table.
Functional area management must engage with the results of Scrum planning and either make necessary decisions immediately or acknowledge decisions the team has made and consider them in leadership actions.
I recommend briefly reviewing the Scrum planning of all teams in a functional area during regular area leadership communication and sharing critical issues.
Avoiding Interrupted Flow
Nothing is more frustrating than having to wait for input and helplessly watching your own deadline wobble because you can't work on the topic.
That's why it's helpful to look during planning at who needs what when from whom, so inputs are available at exactly the right time.
When coordination between affected colleagues (I call them service provider and service recipient) isn't organized and methodically structured, workflow stagnates.
"It was obvious I needed that. It's always like that. You should have known."
"We talked about it - why didn't you do it?"
A well-organized planning method is needed so these detailed plans happen timely, completely, and sustainably, allowing all employees to work efficiently on important tasks in an uninterrupted and unhindered flow.
Here I draw on the pull principle from Kanban.
For this to work well, there are some rules to follow.
ToDo Sprint Rules
Each employee is personally responsible for ensuring that required inputs are clearly and unambiguously defined and communicated to contributing colleagues.
Inputs are scheduled so results are available exactly when needed for further processing. This creates no inventory and results aren't overtaken by time.
Each team member plans their own activities. When a task is scheduled, it signals a commitment that it will actually be completed.
The requester is responsible for scheduling with the service provider. If they can't agree with the service provider, they must seek alternatives or organize escalation. (Escalation isn't negative here - it's involving additional resources to solve the problem.)
Tasks with no requester are omitted. (What nobody needs doesn't get done.)
When problems emerge during processing, the service provider must immediately contact the requester and involve them in solving the problem. (Maybe it can be done with less after all.)
Point three is especially important to me because it ensures that whoever has to do something has actually "bought" that assignment - firmly committed to actually doing it.
The ToDo Sprint Process
The ToDo Sprint approach isn't rocket science and resembles many known frameworks.
Drum Beats are divided into one- or two-week ToDo-Sprints, each getting a backlog with tasks to be completed in each sprint.
During Drum Beat planning, these backlogs are filled for each sprint of the Drum Beat.
During Drum Beat planning, resource availability and task dependencies are also considered.
By PED (Planning Event Drum Beat), there's an initially filled backlog for all ToDo-Sprints of the new Drum Beat.
Each new ToDO-Sprint starts with a review of the previous sprint.
Based on review results and current project situation, the backlog for the coming ToDo-Sprint is updated and refined.
ToDo-Sprint planning is discussed in functional area regular communication.
After completing ToDo-Sprint planning for the current sprint, each team member independently moves their tasks into "In Progress" and "Done" columns.
When a team member moves a task to "Roadblock," line supervisors and the Drum Beat Deliverable Owner step in and support resolving the roadblock.
I haven't tried it yet, but I'm still considering setting up a parking area on the ToDo Board where requesters can park their required inputs for backlog planning.
Another important point to consider: for every task on the ToDo Board, the recipient of the deliverable is noted!
It's also not enough to just describe the task - the expected outcome of the activity must be clearly defined between the service provider and service recipient on the ToDo Board.
How much detail to include is something both parties must decide together. What's important is that they agree on the required result. I believe the more detailed it's written down, the more confident you can be that you truly understand each other.
The ToDo Sprint Combines Agile Sprint and Lean Kanban
Features from Agile Sprint:
Fixed timeframe
Team plans work for the coming sprint together
All tasks are visible to all participants
Shared understanding of goals and progress
Regular review of work results and processes
Early recognition of deviations
Immediate correction when problems are identified
Features from Lean Kanban:
Pull principle - only tasks that meet concrete needs are completed
Focus on continuous flow - all activities are scheduled so no "inventory" or "overproduction" occurs
Each backlog item represents a deliverable
In this article, I've described how project work in functional organizations can be organized so that threatening project delays are recognized early and prevented as much as possible.
I'm sure there will be many more questions about this. If you have questions about this topic, don't hesitate to ask them in the comments.
We can also explore your questions in chat or via DM.
I'll dive deeper into project management practices in the coming articles. Please subscribe to the newsletter so you don't miss them.
If my newsletter resonates with you, please consider sharing it with others.