Scrum in the "Scrum - breaching" environment
Let's say any of you are invited to work as a Scrum master into the firm or organization who is successfully implementing Scrum wrongly.
Let's say they are omitting retrospective, Scrum review is very formal presentation of projects completed every month; the firm is having a release scrums, management is present at daily scrums and is instructing developers about their daily tasks; there is a bonus system based on story points, which management assigns to the team at Sprint planning, usually based on hours of work(with weekend work or overtime counting as extra story point); the release of the product is decided by Portfolio manager not by PO.
Sprint planning is the event where management is picking the tasks for developers from the Product backlog(usually described simply as Jira file number)
However the firm is collecting end users feedback, is considering in while assigning tasks, and is quite successfully(which means high profit).
Scrum is part of the Agile, and from general Agile perspective there is nothing wrong with the process except for use of term "Scrum"
As we also know 4 Principes of Agile are
- Individuals and interactions over processes and tools. Which means that if individuals are willing to run the project the way described above it si up to them
- Working software over comprehensive documentation. They have good quality products, so not fulfilling provisions of Scrum guide is a secondary thing
- Customer collaboration over contract negotiation. Checked
- Responding to change over following a plan. Presuming that rigid framework of Scrum is a "plan" their way can be considered a change
There are also 12 provisions of Agile more elaborated in the Manifesto
- Early and continuous delivery of valuable software. Checked
- Embrace change. If we consider the way they changed Scrum a change, also checked
- Frequent delivery. They do
- Cooperation. There is quite friendly atmosphere
- Autonomy and motivation. The high paycheck serves as motivation
- Better communication. There is clockwork communication in the hierarchy
- Working software. Checked
- Stable work environments. Its stable for decades, and no one wants much change
From a Scrum perspective what's going on is "not Scrum", which is obvious for an Scrum practitioner. From another hand this is only thing what's wrong there from business operation perspective, and considering that this use of name "scrum" is obviously just whim of the CEOs who want fancy name for their business operations, it is a wise business strategy for Scrum master not to try changing things, but adapt.
Of course to avoid any problems it would be good to suggest changing name of this project from "Scrum" to "Story pointed Agile" or "Interactive Agile hierarchy" and may be even publish it as a new methodology at Agile family, but even this change of terminology should be done carefully not to upset managers
Having said that I believe such approach is good for many real life situations which are so often described at Scrum blogs and social media: when a Scrum practitioners are entering a work environment where management is enforcing anything but Scrum by the name of "Scrum" and are confused how to react
If project is not successful, then its wise to leave the ship as soon as possible, but if it is successful and brings value(i.e. income or good salary) to the both Scrum master or PO and the firm who hired them, then best strategy is to adapt and prosper.
Of course, ones professional duty is, as written above, to somehow convince management to change a name of the project from "Scrum" to something even fancier(for them).
This definitely doesn't sound like empiricism being applied by a self-managing team. However, whether something should be called Scrum or not, is not really the point. As a Scrum Master, I used to try to convince those paying me that they should do Scrum, however that (mostly) became a theoretical debate.
In my experience of successful Scrum adoption, trust had to be built over time - by focussing on one improvement at a time and inspecting actually Done increments and actual results of improvements. Would it be possible to have a Sprint Retrospective, and actually do the action that comes out of it? Or perhaps inspect the Increment at the Sprint Review and then adapt the Product Backlog, without all of the other ritualistic actions that you described?
The "rituals" which take only 15 hours a month, plus 15 min. daily scrum are vital for achieving the results Scrum was designed for - being a risk control and waste removing mechanism at the first place. Unwillingness to spend even thos company time(from average 160-180 hours a month) is a clear respect how little SOME companies having for the framework they, themselves are paying to implement.
When I read this hypothetical scenario
Only one statement forms in my mind:
Job burnout.
Constant chasing and rewarding such behavior works in the short run but frequent personnel changes are "natural situation" in this kind of environment
Push policies always end the same way with lack of accountability and ownership.
Demotivation does not appear immediately it depends on the individual person.
Money works only up to a certain stage later it is only worse and the organizational cancer in this way grows and will fail with huge Impact.
Point is that in real life failure of the corporate firm often isnt the personal disadvantage for managers.
From "golden parachutes" to signing off debt by bankruptcy clause, there are many reasons...