First Sprint Panic

Has anyone else ever had crisis meetings with project managers after a first Sprint? It seems to be a very common thing. After all, first Sprints often go wrong. Of course, already the use of the word “wrong” is highly debatable, but let’s say they go “wrong” from an outside point of view. The team is not yet settled in, they have not even started their storming phase, they have no idea how much work they can get done in a Sprint, they are working with new tools and toolchains. So of course, many problems surface during the first Sprint. And that is great. More problems -> more learnings -> more improvements.

So why have I had to sit through so many first Sprint crisis meetings with project managers? There’s the project manager asking me why the team underestimated the work, why they didn’t see early enough that they would not manage to reach the Sprint Goal, why they did not raise impediments earlier, and so on. And of course, the project manager wants to know why we don’t have a burndown chart, a popcorn board and why subtasks are not being estimated in person hours. Because all of that would have ensured a “successful” Sprint. And that is just the tip of the iceberg.

I think one major reason for this crisis mode is that project managers in a classic project world are used to projects that go very smoothly at the beginning. Nothing goes wrong for many many months. Everything is being reported as “on track”. Everything goes according to plan. But then, three months before the fixed delivery date, people start admitting that things are not going so well, and the test teams are finding more bugs than the developers can fix. So experienced project managers go into crisis mode the very moment these indicators start popping up – because after all, they only have a few months left. Experienced project managers are trained to panic the moment they see a problem. That is a survival strategy in classic project management.

It is also a part of this project management experience not to trust anyone. After all, everyone has been telling you for many months that everything is fine, while in reality everything was a complete mess. So as a project manager, you don’t trust those people to fix things, but instead you go in and micromanage everything.

How does that translate to an agile project? Like I said, there are many good reasons why a first Sprint may not go so smoothly. And in an agile project, you see this immediately. You get a lot of indicators for things that need to be improved.

Now remember the project manager’s survival strategy: You see problem indicators, you go into crisis mode, stop trusting people and start micromanaging. So there are the Scrum Masters, sitting in a crisis meeting with the project manager after the first Sprint, being told what to do to fix all those terrible problems.

How can this be avoided? I guess one important method for you as Scrum Master or Agile Coach is to manage a project manager’s expectations – to let them know in advance that the first few Sprints will not go so smoothly and to explain to them that this is an important part of the learning and improvement process. Build trust by being honest with the project manager. You have to to remember though that honesty and transparency is something that many project managers are not used to, so you have to understand that this is a learning journey for them.

If you are the project manager in this scenario, I won’t even tell you not to get involved, because I know that it might be your natural survival instinct. Transparency is there for a reason, and it’s completely fine that you ask some questions. But I’d ask you to resist the temptation to micromanage. Don’t tell people what to do. You hired Scrum Masters for a reason. Ask them what the teams have learned, and you’ll probably get plenty of answers. Give yourself the chance to be surprised by what a team can learn within a few Sprints.

Disclaimer: I know, “project managers” are not considered a part of agile projects by many, but most organizations still use project managers, especially when they are at the beginning of an agile transition, so I am speaking from a realistic and pragmatic point of view here. If crossing your arms and saying “This project manager shouldn’t even be here” works for you as a Scrum Master, then that is great of course.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.