Many Teams Use Scrum As An Excuse To Avoid Their Accountabilities
Self-management doesn’t only come with rights, but also with responsibilities
Self-management doesn’t only come with rights, but also with responsibilities
“I’m sorry, but what you ask for isn’t Agile.”
Harry can’t believe what he just heard. “What? What do you mean?”
Angela shakes her head and sighs. She hates this part of her Scrum Master role. Another manager who doesn't seem to understand. Scrum is supposed to be simple!
“You want to know when we will finish the MVP. Well, it will take longer than a Sprint. It’s bigger than a Sprint. So we don’t know when it will be done. We don’t plan beyond a Sprint. That’s not how Scrum works.”
“But don’t you have an indication? A rough idea? I get that you can't give me a detailed plan. And I’m not asking for that. All I want to know is if we have any chance to present it at the winter event. It’s still 6 months away.”
“I see what you are doing. You are trying to trick me. You want to lure me into saying we may have a shot at doing this and then you are going to turn it into a deadline. Well, I’m not going to do this.”
“Could I ask this at the next Sprint Review? I would say this is a topic of discussion for this event. We may look into ways to increase the chances of making this date.”
“You can try, but our Product Owner Sundeep is very protective towards the team. He will not allow others to meddle with his backlog and pressure the team. If I were you, I would simply wait and see. The MVP comes when it comes.”
Bewildered, Harry goes back to his desk. He doesn’t know what to think of Scrum. Sure, their previous way of working with detailed plans that proved to be fiction wasn’t perfect at all. And he gets that teams were put into a squeeze as they had to meet the false promises.
But now it feels like it is too casual. They are in a dog-eat-dog business. The company simply can’t afford to be this careless. Is Scrum really the best way forward?
Harry is right. The way this team has interpreted Scrum is wrong, careless and dangerous. The team uses Scrum as an excuse to avoid responsibilities. But this is totally against the philosophy of Scrum. What’s more, it harms the Scrum Team and its stakeholders.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fea4acc69-c700-458c-828e-95c9a1bea31a_800x533.jpeg)
Harmful behaviour due to misunderstanding Scrum
Here are some examples of the wrong kind of behaviour by misunderstanding the Scrum framework:
Teams say the environment is complex, so they can’t predict when they are ready with a larger chunk of product.
The Product Owner is shielding the team from outside interference in such a way that stakeholders have no way to influence the backlog.
Scrum Teams don’t commit to achieving their Sprint Goal. They may even have no Sprint Goal at all. Not meeting the Sprint Goal is seen as normal, because of the complexity of the product.
Scrum Teams don’t use Daily Scrums to optimize the chances to achieve their goal. Instead, they only treat it as a status event without any actual learning and adjusting of the course.
Scrum Teams don’t commit to improving themselves. Sprint Retrospectives are no more than complaint sessions.
Scrum is an excuse for everything.
But Scrum is not like this, as I will show now.
Commitment to long-term objectives
The Scrum Team has the obligation to define a Product Goal that depicts the long-term objective for a Scrum Team. Typically Scrum Teams match their Product Goals with company goals.
Scrum Teams progress towards meeting the Product Goal Sprint after Sprint. Teams should relentlessly look for the best ways to meet this Product Goal.
At least once every Sprint teams and its stakeholders discuss how the team is progressing towards the Product Goal. This happens at the Sprint Review. The previous Scrum Guide mentions how the Product Owner discusses likely target dates and delivery dates.
The current Scrum Guide doesn’t do this anymore. This is not because it is not relevant. Rather, it is because the Scrum Guide is less descriptive. But the Scrum Guide still says:
“The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.” — Scrum Guide 2020
This progress included the current status, but also a projection of possible scenarios — including dates. These shouldn’t be dates set in stone. Scrum is for complex environments after all. But there are great alternatives, like using probabilistic forecasting.
Commitment to Transparency
Scrum Teams have the obligation to be transparent. The Product Backlog, Sprint Backlog and Increment should be transparent to everyone. Both within the team AND to their main stakeholders.
This is crucial as everyone who is involved in the decision process should be on the same page regarding the state of the product. Only with a transparent Product Backlog can the team and stakeholders make the best decisions on what to do next. Only with transparency on the state of the Increment can the team and its stakeholders inspect this Increment and decide if it does what they expected.
Transparency is a crucial part of empiricism. Empiricism is the foundation of Scrum.
Commitment to Maximizing Value
Scrum Team commit to maximizing the value of their product. This is primarily an accountability for the Product Owner, but it applies to everyone else within the team.
Scrum Teams have the obligation to make the best choices to achieve their goals and maximizing value. This is not only relevant for Sprint Planning, where the team decides what would be the most valuable thing to achieve next.
It also goes for the Daily Scrum where the Developers inspect how to progress towards the Sprint Goal and what they can do to optimize these changes.
Scrum Teams need to plan a lot. They do it constantly:
Whenever applicable, the team updates the Product Backlog to optimize the chances to create the highest value.
Every Sprint Planning.
Every Daily Scrum.
Every Sprint Review, inspecting the Increment and new developments impacting the product.
A commitment to constant planning and re-planning is necessary to remain on top of things. This is crucial in complex environments. Every new insight coming from inspection leads to adaptations and re-planning.
Commitment to Improve
Scrum Teams have an obligation to improve their quality and effectiveness. At least every Sprint, teams look for ways to improve their way of working to maximise the value of their work.
Scrum Teams work with double-loop learning. They not only inspect and adapt their progress towards the goals. They also constantly inspect and adapt their way of working to be more effective.
Scrum Teams shouldn’t only improve themselves. They should also relentlessly aim to improve interactions, tools and processes involving stakeholders and others that impact their goals. The importance of changing the organisation can’t be overestimated.
Scrum is a reason to be committed, not an excuse to avoid responsibilities
Teams that use Scrum as an excuse to avoid responsibilities and commitment are toxic. They may have a reason for their behaviour, but it will not help them in the long run.
It is a false depiction of what Scrum is and it will not convince your stakeholders. They will get tired from the excuses of the team. And excuses they are. Because Scrum Teams need to be extremely committed. The need to commit to:
the Product Goal
the Sprint Goal
the quality standards of the Definition of Done
maximizing value of the product
improving themselves
Scrum is hard work. Great Scrum Teams are never done learning and improving. And this is absolutely necessary to be able to succeed in complex product environments.
A Scrum Team that is committed to their accountabilities will have no issues having good conversations with their stakeholders. Because the stakeholders will notice the commitment, understand it and appreciate it. They will be enabled to play their part in the game of Scrum. And this will help everyone to make the best possible product.