"Ceremonies", "daily stand up" and other hazards.
As the Scrum spreads across the commercial companies and government institutions, it's fair to establish that almost no one is running Scrum by the book
Which is logical. The more people are practicing certain ideas, the more deviations are there, for good or for worse. Scrum is not an exception .
So yes, most people are either trying to add new elements to the Scrum framework, or changing the whole process. Or, on the contrary, are mixing Scrum with existing and established practices, because it makes them feel more secure.
Sometimes it's done as a conscious experiment, in true Agile fashion with an intention to create a new valuable methodology or framework.
Most notable are Spotify attempts to create a system of "Tribes, Guilds, Squads and Chapters", results of which are still discussed here; or emergence of the dissident SAFe Scrum network independently from scrum.org. With its own culture altogether.
More often the deviations are caused either by poor understanding of Scrum provisions, or by the intention to somehow mix the existing company culture with Scrum.
Pressure for the top management, luck of trust within organization, own prejudice and negative emotions of practitioners are most often the factor
Many deviations are common and well described, they happen in many places with the same scenario, and have the same cause and consequence. First of all it is an ill fated weaponization of velocity, particularly-use of story points as a metric. Comparing the scrum teams with each other, and forcing them to compete is another problem.
Using the metrics which are not related to the value of the product to estimate both Product backlog items and increment; altering or cancelling Scrum events "to save company time"; running the Scrum as a traditional waterfall project, but calling Team Leader a "scrum master", and Product manager "the product owner" are also frequent...
Another common occurrence is a "Zombi scrum", when the teams of developers are pedantically following all the prescribed procedures without any understanding WHY are they doing it.
In most cases people who are involved understand that they are exercising scrum poorly, but are having own explanation: like referencing market pressure, insecurity and unreadiness of the firm to change, pressure from the CEO's or urgent deadlines as a reason. To be honest, I myself have decided to abandon Scrum and run a project as a traditional command-and-control method because of tight external deadline once, and having not enough time to wait until the self managing team will catch up with the performance. But this was an extreme case scenario.
However there is one interesting matter among all hazardous tendencies and habits which has grown onto Scrum framework like a mold or the tee...
There is a certain combination of practices and terminology which is clearly breaching Scrum rules, but is so widespread and frequent, that it has almost grown into a methodology of its own.
With its own glossary, methods and rules. It could be considered the interesting experiment, same as the Spotify system which I have mentioned above, if it would be only able to prove creating value...
Problem is, whoever, that practitioners of this system are certain that the project management system which they are using is actually called "Scrum". And they are often unaware of actual Scrum rules as written in Scrum guide, creating obvious confusion in the whole Agile related industry
I choose to call this alternative version "ceremony Scrum", because calling Scrum events "ceremonies" is one the frequent symptoms of this method
Other common symptoms of "Ceremony Scrum" are:
- Calling daily Scrum "daily standup", presumably forcing the developers to stand during the meeting(actually I have seen a tutorial about doing this).
- Calling Scrum events "ceremonies", as mentioned above.
- Mandatory use of terms "User stories" and "Epics" to describe product backlog items, based on their size. Considering the non functional PBI "not user stories".
- Idea that Scrum team should be between 3 and 9 people, mandatory.
- Idea that Product owner can deny or cancel the Increment for any reason.
- Insisting that Kanban(indeed useful) is a mandatory element of Scrum or is actual foundation of Scrum.
- Insisting on Planning Poker as mandatory element of Sprint planning
- Having multiple product owners for one Product, usually one Product owner per team
- Using Sprint review as a presentation and gateway of the increment.
- Scrum master is planning and conducting Daily Scrum and other events
- Definition of Done as a commitment to Increment is misunderstood or even absent from the practice. Increment is not an artefact.
- "Definition of ready" (for PBI) is a commitment in Ceremony Scrum
- Considering Scrum to be a best methodology to porperly use Jira and other Atlassian software for project management(I am not joking)
Those behaviors could be seen as simple deviations. But as I have said, they are so widespread that they are becoming a system of their own. After digging a bit deeper I have discovered existing Scrum courses and classes, including one at LinkedIn, and multiple ones on Youtube which are actually teaching the above-mentioned version of "Scrum".
Some Agile coaches who had the Scrum course in business school or university are also spreading same thing, with exact same methodology and terminology
The source of those ideas is less clear.
Either previous versions of Scrum guide, without knowledge of updates, like notorious Michael Lapishins blog which is contributing to misunderstandings greatly... Or simply learning about scrum from some other source, without actual reference to scrum guide, who knows?
-