"Ceremonies", "daily stand ups" 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; 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 from 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 properly 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".?Or at least its elements.

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?

This brings to very unpopular and tough conclusion:

As mentioned above it is fair to assume that the vast majority of Scrum practitioners, those in commercial firms in particular, are exercising Scrum which does not fit into Scrum guide provisions.

Majority of posts at the very forum of scrum.org, not to talk about Scrum related social media prove this...

Not to talk about the fact there there are at least three (yes three) different versions of the Scrum at the market today: actual Scrum guide regulated Scrum, already mentioned dissident SAFe Scrum which has deliberately changed both terminology and provisions, and somewhat swampy "ceremony Scrum" with a whole set of deviating stereotypes like "ceremonies, "daily stand ups", which I have described above.

In the Scaled Scrum, when companies have to divide big groups of people into Scrum teams, diversity is even wider. Apart from unpopular offspring of scrum.org which is called NEXUS(to which Jeff Satherlend, one of the creators of Scrum has not signed), there are older "Scrum of the Scrum", the controversial "Spotify Scrum", already mentioned dissident SAFe Scrum, and very convenient but unfortunately not very well promoted LESS Scrum. Each one is having own guiding principles and rules, often deviating from the "proper Scrum".

But wait a minute...The word is "deviating" is used purely from a Scrum guide perspective of course. Otherwise, if we shall see Scrum guide as a recommendation, not a rule, we must admit that practitioners have liberty to organize Scrum any way they want?

If stepping aside from Scrum guide is a conscious decision, or if it comes from ignorance and misleading education is another matter...

This way or another, we have to accept that in general most, if not everyone, who is running Scrum projects today are actually "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum"(this is a quote from Scrum guide). But still, many of them are able to yield profits and otherwise increase value.

Moreover, I have met managers who deliberately breach the provisions of the Scrum guide to keep up profits or successful team operations. I can provide examples.

Scrum Guide has no bounding effect on practitioners. Following or breaching the Scrum guide rules are a voluntary act; there is not a single force or legal provision in Universe which can force a practitioner to follow the rules, or punish him for refusing.

The only factor guarding the rules is a bold statement that "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum" actually covers up problems and limits the benefits of Scrum, potentially even rendering it useless. ". Which is scaring the practitioners to step out the imaginary cage of Scrum Guide. Or, like it often happens in actual real world, scares them to admit that practitioners actually act outside the rules of Scrum guide in practice... Which is reducing transparency, and prevents the feedback about the effects of using Scrum outside the boundaries of Scrum guide from returning to the source.

Could be its a high time to state collecting the feedback from Scrum practitioners and test actual Scrum guide against own core values, Transparency, Inspection and Adaptation??

Transparency?allows us to establish that many people are willing to do Scrum, but are unwilling or unable to do it according to the strict provisions of the Scrum guide

Inspection?will allow us to establish if "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum" actually covers up problems and limits the benefits of Scrum, potentially even rendering it useless." as Scrum guide says . May be some of the changes create an interesting, more profitable and productive way of producing value?

Adaptation?will allow new updates to Scrum guide based on this feedback, or may be will render Scrum Guide and all its provisions useless?

After all, Scrum existed from 1995 until 2009 without any Guide or set of rules, just as a system of thought without any guiding rules?

-----------------------------------

I invite everyone who is unable or unwilling to follow Scrum guide provisions while running Scrum project to share the experience in my Linked group Fusion Scrum https://www.dhirubhai.net/groups/12853780/

I am intended to create a feedback pipe(I doubt it can be called loup) and knowledge base about "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum". From my side I will spend some time gathering the stories about real life effects of running Scrum without fixed rules and boundaries.

This feedback will be further used for the creation of AS IF(Adapted Scrum Integrated Framework) network with some guiding principles to help practitioners achieving success outside the boundaries of the Scrum Guide.