Thought provoking! IMHO, Scrum has deliberately not been prescriptive for teams to adapt the framework to their needs. Apart from the Rituals & Timeboxed Iterations nothing is mandatory. If the team is heavily focused on software development and needs strong engineering discipline, XP would be a better choice.
Times I have seen in my career where people where mentioning the "rules of Scrum" as a reason to follow them:
- We must use Story Points for Scrum
- the team must committed to the entirety of the sprint backlog to be finished
- Stakeholders must wait the sprint review to give feedback to the team
- At the end of the sprint, and only then, the team must release a new version or the sprint is failed
- a team must have 2-3 months defines in advance and those sprints cannot be changed by anyone for a team to be successful with Scrum
See the pattern here? Yes, none of those are prescribed by Scrum. Even more, many of those contradicts the Scrum Guide. So, very often, when a team told me that Scrum failed them, I asked them why they think so, and most of the time, and I can't actually find a single example where it wasn't the case, it was about a prescription that the team give to themselves that as nothing to do with Scrum (like mentioned above).
In my practice, also, Scrum has many times proved itself an excellent "trust engine": following Scrum practices and values help building trust, not only with stakeholders, but also within the team itself and for yourself. Developers in my Scrum team have shown more confidence and better accountability than my non-Scrum team. So, very hard for me to believe that Scrum is responsible for the lack of accountability in your team. It's probably more how Scrum were introduced to your team, or a question of the culture of the team, but you are in better place to figure it out.
Now, should you use Scrum all the time? I think not. I have a principle to always start from where the team is and build from there. Radical sudden change rarely works unless properly support across the structure in place and with good example of success, especially if there is something else at stake, like the survival of your project, or even your team. So, building step by step, by keeping what your team is strong and adopting new principles were your team is weaker, very similar to what you proposed, is IMO, the way to go. And one day, you'll figure out, what the team is going is mostly Scrum, just by another name (e.g. it's not a sprint, it's an iteration cycle, it's not a backlog, it's a queue, it's not a retrospective, it's a postmortem, it's not a product owner, it's a request manager, it's not a scrum master, it's a coach...).
Transparent, unambiguous lines of accountability are absolutely necessary and if they do not exist or change with tide, there are likely deeper underlying problems.
I tend to believe in people and delivery/outcomes over processes - a Scrum/Agile principle - and I think that helps save me from becoming too dogmatic. But I have seen what you describe, as well. The bar (certification) is low but experience - and, I suppose, the capacity to prioritise outcomes over output - is the elevating factor.
There is a bit of a flaw in your argument: an accountability sink exist only if the reason to deny a request is held to the policy rather than the purpose of a policy. E.g. If I'm want to have a contract from a public organism and try to bribe a politician to provide me with this contract, the politician can still mentioned to refuse it for cause of policies against corruption, but this doesn't make the policy wrong. It's a bit the same for your example of a manager refusing you a raise because it is outside the brackets. It can look for other way to recognize your contribution, and if he doesn't is probably because he doesn't care, but one shouldn't just ignore a policy, rule or law just because it's inconvenient at the moment.
Let me know if I am missing something, but I don't believe it's a flaw in the argument.
I even got my money back without a receipt once.
People can override policies or choose to hide behind them.
It's too simplistic to assume a manager doesn't care because they are unable to recognize your contribution in other ways. It may also be incompetence on the part of your manager for example!
However, managers will definitely say stuff like this to prevent everyone on their team to keep asking for a raise.
I would reverse the argument: managers that lack accountability will use policies to avoid dealing with some difficult responsibilities. That's accountability sink in my opinion. But the mere existence of rules, policies or laws is not enough to say "eh, we should get rid of them because those are unaccountability sinks." Applying to Scrum, this mean "the presence of rules in Scrum is not the cause of unaccountability, but some unaccountable people are using the rules of Scrum to abdicated their responsibilities." I think such behaviors should be denounced, not Scrum or the Scrum Guide, which have always presenting themselves has a framework to be adapted rather than a strict structure to follow and have always seen a good measure of evolution to improve itself over the years. Scrum never forbid you to not adopt it, but they are right in saying that if you change it, it's no longer Scrum and so its promises can no longer be held. If I gave you a chocolate cake recipe and you replace the floor by sand, and double the cooking time, don't hold me responsible for the result.
You're right about about the adaptation part. Scrum present itself as an immutable but incomplete framework. However, nothing in it said that if you failed, you aren't using Scrum. It says that if you modify it, you cannot call it Scrum anymore and you can cover up problems, limits its benefits and rendering it useless. That's aligned with both my experience and the cake example I gave. Now, you can take my chocolate cake, replace the chocolate with raspberry jam, add some meringue on top, and brule it to get a nice burn and that will be excellent, but it wouldn't be anymore a chocolate cake. The scrum guide even invite you to look for yourself if it works for you. And through our the guide, they emphasize what you need to make the Scrum works and how incomplete it is. And that also matches my observations: every time I've seen a team failing when using Scrum, they have made modifications or were ignoring part of it: values, skipping some activities (like retro), confounding sprint backlog from product backlog (especially teams using Jira), not having a sprint goals, not being open, not having the courage to bring up their problems, not following the empirical process of transparency, inspection and adaptation, etc. I've yet to find a team that follows all of this to fail at Scrum. I've seen many teams however failing to implement all of them. Now, one can say that Scrum failed because those teams weren't able to implement all of this, and that can be an argument. I'm just not using it: it's not because some people fails to follow a recipe instructions that I will stop making excellent chocolate cake following the same recipe. I can maybe improve the recipe, find out why some people failed, etc., and that is exactly why the Scrum Guide has evolved over the years, but that do not make Scrum inevitably broken. And let be clear: Scrum is not the only game in town and certainly not only way to achieve success. So, you can do what you want and I wish you the best of luck and looking forward to read about it. But your success with an approach removes nothing to the value of Scrum. Diversity of practices are always a good thing.
Thought provoking! IMHO, Scrum has deliberately not been prescriptive for teams to adapt the framework to their needs. Apart from the Rituals & Timeboxed Iterations nothing is mandatory. If the team is heavily focused on software development and needs strong engineering discipline, XP would be a better choice.
Times I have seen in my career where people where mentioning the "rules of Scrum" as a reason to follow them:
- We must use Story Points for Scrum
- the team must committed to the entirety of the sprint backlog to be finished
- Stakeholders must wait the sprint review to give feedback to the team
- At the end of the sprint, and only then, the team must release a new version or the sprint is failed
- a team must have 2-3 months defines in advance and those sprints cannot be changed by anyone for a team to be successful with Scrum
See the pattern here? Yes, none of those are prescribed by Scrum. Even more, many of those contradicts the Scrum Guide. So, very often, when a team told me that Scrum failed them, I asked them why they think so, and most of the time, and I can't actually find a single example where it wasn't the case, it was about a prescription that the team give to themselves that as nothing to do with Scrum (like mentioned above).
In my practice, also, Scrum has many times proved itself an excellent "trust engine": following Scrum practices and values help building trust, not only with stakeholders, but also within the team itself and for yourself. Developers in my Scrum team have shown more confidence and better accountability than my non-Scrum team. So, very hard for me to believe that Scrum is responsible for the lack of accountability in your team. It's probably more how Scrum were introduced to your team, or a question of the culture of the team, but you are in better place to figure it out.
Now, should you use Scrum all the time? I think not. I have a principle to always start from where the team is and build from there. Radical sudden change rarely works unless properly support across the structure in place and with good example of success, especially if there is something else at stake, like the survival of your project, or even your team. So, building step by step, by keeping what your team is strong and adopting new principles were your team is weaker, very similar to what you proposed, is IMO, the way to go. And one day, you'll figure out, what the team is going is mostly Scrum, just by another name (e.g. it's not a sprint, it's an iteration cycle, it's not a backlog, it's a queue, it's not a retrospective, it's a postmortem, it's not a product owner, it's a request manager, it's not a scrum master, it's a coach...).
Transparent, unambiguous lines of accountability are absolutely necessary and if they do not exist or change with tide, there are likely deeper underlying problems.
Book added to the list...
I tend to believe in people and delivery/outcomes over processes - a Scrum/Agile principle - and I think that helps save me from becoming too dogmatic. But I have seen what you describe, as well. The bar (certification) is low but experience - and, I suppose, the capacity to prioritise outcomes over output - is the elevating factor.
There is a bit of a flaw in your argument: an accountability sink exist only if the reason to deny a request is held to the policy rather than the purpose of a policy. E.g. If I'm want to have a contract from a public organism and try to bribe a politician to provide me with this contract, the politician can still mentioned to refuse it for cause of policies against corruption, but this doesn't make the policy wrong. It's a bit the same for your example of a manager refusing you a raise because it is outside the brackets. It can look for other way to recognize your contribution, and if he doesn't is probably because he doesn't care, but one shouldn't just ignore a policy, rule or law just because it's inconvenient at the moment.
Let me know if I am missing something, but I don't believe it's a flaw in the argument.
I even got my money back without a receipt once.
People can override policies or choose to hide behind them.
It's too simplistic to assume a manager doesn't care because they are unable to recognize your contribution in other ways. It may also be incompetence on the part of your manager for example!
However, managers will definitely say stuff like this to prevent everyone on their team to keep asking for a raise.
I would reverse the argument: managers that lack accountability will use policies to avoid dealing with some difficult responsibilities. That's accountability sink in my opinion. But the mere existence of rules, policies or laws is not enough to say "eh, we should get rid of them because those are unaccountability sinks." Applying to Scrum, this mean "the presence of rules in Scrum is not the cause of unaccountability, but some unaccountable people are using the rules of Scrum to abdicated their responsibilities." I think such behaviors should be denounced, not Scrum or the Scrum Guide, which have always presenting themselves has a framework to be adapted rather than a strict structure to follow and have always seen a good measure of evolution to improve itself over the years. Scrum never forbid you to not adopt it, but they are right in saying that if you change it, it's no longer Scrum and so its promises can no longer be held. If I gave you a chocolate cake recipe and you replace the floor by sand, and double the cooking time, don't hold me responsible for the result.
You're correct, not all rules, policies or laws are accountability sinks.
Scrum does not present itself as a framework to be adapted, but to adapt on top. Big difference.
It is forbidden, but 99 percent of Scrum Teams are not doing Scrum, yet they (and we) say they do Scrum.
E.g. I would amend the Scrum Guide that following the purpose behind the rules itself is more important than following the rules.
Now, it's an accountability sink.
When it fails: but they were not doing Scrum.
You're right about about the adaptation part. Scrum present itself as an immutable but incomplete framework. However, nothing in it said that if you failed, you aren't using Scrum. It says that if you modify it, you cannot call it Scrum anymore and you can cover up problems, limits its benefits and rendering it useless. That's aligned with both my experience and the cake example I gave. Now, you can take my chocolate cake, replace the chocolate with raspberry jam, add some meringue on top, and brule it to get a nice burn and that will be excellent, but it wouldn't be anymore a chocolate cake. The scrum guide even invite you to look for yourself if it works for you. And through our the guide, they emphasize what you need to make the Scrum works and how incomplete it is. And that also matches my observations: every time I've seen a team failing when using Scrum, they have made modifications or were ignoring part of it: values, skipping some activities (like retro), confounding sprint backlog from product backlog (especially teams using Jira), not having a sprint goals, not being open, not having the courage to bring up their problems, not following the empirical process of transparency, inspection and adaptation, etc. I've yet to find a team that follows all of this to fail at Scrum. I've seen many teams however failing to implement all of them. Now, one can say that Scrum failed because those teams weren't able to implement all of this, and that can be an argument. I'm just not using it: it's not because some people fails to follow a recipe instructions that I will stop making excellent chocolate cake following the same recipe. I can maybe improve the recipe, find out why some people failed, etc., and that is exactly why the Scrum Guide has evolved over the years, but that do not make Scrum inevitably broken. And let be clear: Scrum is not the only game in town and certainly not only way to achieve success. So, you can do what you want and I wish you the best of luck and looking forward to read about it. But your success with an approach removes nothing to the value of Scrum. Diversity of practices are always a good thing.