Which parts of Scrum do you most often skip?
Hello everyone,
My name is Malin I am currently conducting my thesis in computer science, where I examine with the help of a survey, the negative parts of Scrum. But now I would need your help! I would love to hear about your experience with Scrum, negative or positive.
Although Scrum is often seen as something positive from a business perspective, it can be unmotivating for many software developers. This has its consequences and can lead to teams using Scrum only partially or not following the Scrum guide, which, among other things, means that efficiency is negatively affected.
Are you working with software development? Do you perhaps use Scrum at your workplace? Or have you previously used Scrum? Which parts of Scrum do you most often skip? And what are the underlying reasons for this, accorning to your experience? I would be incredibly grateful if you wanna share your experience with me here in the forum, or if you would participate in my survey. It only takes a few minutes to participate, and each of you are important.
https://docs.google.com/forms/d/e/1FAIpQLSdgyG1C5GQQMV26PLp4qmynehXUObr…
Elements of Scrum are not generally skipped. The problem isn't that clean. Rather, they are more typically broken, scrunched up, reframed and moulded around what an organization does right now, so as to minimize change while creating the illusion of agility. The resulting failure to improve outcomes is what saps motivation.
Your premise is that everyone skips something in Scrum. But from my experience, many do not adjust Scrum at all. They see the value that the Events provide for empirical processing.
Although Scrum is often seen as something positive from a business perspective, it can be unmotivating for many software developers.
It is also motivating for developers if they have been coached in how the Scrum framework can be to their benefit. And if the emphasis is put on the Scrum Team's ability to deliver usable increments of value to the stakeholders.
Based upon your survey and the introduction your provided in your original post, it seems that you have already decided that Scrum is not useful and is unmotivating. I would be interested in knowing what led you to that conclusion. Have you ever worked in a Scrum Team? Have you interviewed any teams that use Scrum effectively?
If you look at posts I have made in these forums, I openly admit that Scrum is not right for everyone or every situation. That happens for a variety of reasons. Many organizations will adopt some parts of the Scrum framework but not use other parts. There is nothing to say that is wrong if it helps the organization and their teams to have the agility needed to provide successful products. But as the Scrum Guide states in the End Note
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
I tend not to skip any element in Scrum since the elements make up Scrum.
But I often see that things are missing in organisations who claim to be "doing Scrum".
It could be the Daily Scrum (that turned into people reciting their calendars and thus people stopped having them), the Sprint Review (where "not enough good things to show" where done during the Sprint so they decided to cancel it) etc.
What I try to do when I meet that is go back to the roots and talk about why these Events exist so we can use them for their intended purpose and restore value to them.
In fact explaining the "why" behind Scrum and its different parts is something I see way to many organisations failing to do. They instead "implement Scrum" as they have done with any of their previous "processes" and then when they aren't getting the benefits from Scrum they think the framework is to blame. When in fact what is often to blame was lacking change management to introduce Scrum in the first place.