How important is it to do "proper" Scrum?

Hello Alex,



as you described reality is often something completely different than theory.

For me, most important thing is to start somewhere and improve on the way. Change things, try things, fail, learn, succeed. That is how teams get more mature and eventually shift to what I think you called "proper Scrum".

So don't worry too much about it. I would advise sharing your concerns with your team (not only Scrum Master) and trying to provoke change.



 

I'd recommend understanding and helping teams and organizations understand why the Scrum artifacts and events are the way they are. Although it's not really part of the Scrum Guide, there is a reason for a Product Goal, a Sprint Goal, why Sprint Reviews are more than presentations and demos, and Daily Scrums are planning and not status meetings. Unfortunately, there are many organizations (and people) who have not only not read the Scrum Guide, but also haven't dug deeper into why the structures in Scrum are the way they are and what benefits (and drawbacks) those structures have.

It is important to understand the context the team is working in. There are contexts and environments where Scrum is not a good fit. Although it's true that changing the minimal elements laid out in the Scrum Guide results in something that is not Scrum, making those changes may result in a way of working that is much better for the team's environment. However, this goes back to some people and organizations not understanding the rationale behind the structures in Scrum and alternative structures designed to achieve the same objectives.

I believe that helping a team and the broader organization be successful is far, far more important than doing "proper" Scrum. There are plenty of good approaches that organizations have used that are not Scrum. Since Scrum is so popular, it is important to not only understand the "mechanics" of Scrum (what the Scrum Guide says), but the underlying rational, values, and principles that guide those mechanics. Since you're operating within the context of SAFe, it would also show how what SAFe describes is inherently at odds with Scrum, and perhaps even agility.

How important is it to do "proper" Scrum by the book? But I ask specifically because I'm trying to understand how or why it could be important for the team I'm working in, and the work I'm doing.

How important is it to get different outcomes than the ones currently being obtained?

The situation you have described is one of organizational gravity, which tugs and tears at Scrum until the scrunched-up framework is molded around the organization's current form and shape. You may find Scrum terms of reference being abused on occasion, but there is no substance to a genuine enterprise change attempt.

The pulverized and liquidized remnants of Scrum then end up being sprayed over the company like a kind of veneer, perhaps in the hope that some of it sticks. Unfortunately, I'll bet the outcomes are the same.

...but we're also doing SAFe...

Going to start with that before I get on my soapbox.  SAFe does not use Scrum as described in the Scrum Guide.  They use a variation that they call ScrumXP.  It is defined specifically to be compatible with the rest of the Scaled Agile Framework.  Yes, it uses some Scrum terms and some of their events, artifacts, etc somewhat align with the ones described in the Scrum Guide.  But it is not Scrum.

Now for the soapbox.  This is my opinion and may be different from others, including those associated to Scrum.org. 

@Ian's statement makes me think of the intent of Scrum, not the steps.  The intent of Scrum is to allow teams to react to change with some level of consistent behavior.  Following the framework as described in the Scrum Guide leads to a team/organization that has learned how to use empiricism to drive their work. 

As @Thomas pointed out Scrum is not a fit for all organizations.  Like you, I have worked in places that claimed to "use Scrum" but did not fully understand the essence of Scrum.  Most people do not realize that Scrum is a framework and instead claim it as a methodology or process.  It is actually a somewhat light framework if you compare it to a lot of the project management methodologies that exist.  It is prescriptive of some things not for the activity specifically but for the benefits that are obtained. 

Not all organizations will benefit from a "pure" implementation of the Scrum framework.  But I have yet to see one that couldn't benefit from the principals that the Scrum framework promotes.  In the end, the organization needs to decide what their goals are for agile practices and settle on what works best for them.  In my opinion, Scrum is one of the easiest to implement but the hardest to follow because it expects a lot of self-reliance and discipline of the teams.  Self-managing, self-organizing teams are not something that most organizations are able, or willing, to support. 

Thank you for your comments, folks!

I have some questions to your answers:

Since Scrum is so popular

How can Scrum be so popular if nobody uses it? :-/ I'm exaggerating again but who can prove that Scrum has benefits when everybody just picks the cherries and ignores the rest? :D

SAFe does not use Scrum as described in the Scrum Guide.  They use a variation that they call ScrumXP.  It is defined specifically to be compatible with the rest of the Scaled Agile Framework.  Yes, it uses some Scrum terms and some of their events, artifacts, etc somewhat align with the ones described in the Scrum Guide.  But it is not Scrum.

I've read this sentiment from you in other forum posts, and I find it very interesting because my company implies that it's definitely Scrum that is used here. Officially we're not bound to do Scrum, we're only bound to use some agile methodology/framework (I'm really lost on the vocabulary here, see below). I couldn't find infos regarding ScrumXP on https://www.scaledagileframework.com/, could you provide a link to that? :)

Most people do not realize that Scrum is a framework and instead claim it as a methodology or process.

I realise that it's called a framework, but I fail to understand what that is supposed to mean. To me, a process is "do steps A, B, C and don't deviate from it unless there are very specific reasons to" (and that would probably result in a new process, not doing the old one plus something different now and then; a methodology is maybe a toolbox I can pick stuff from? Or a set of processes? But what's a framework?

It is supposed to be lightweight compared to methodologies, if I understand correctly.

Another area where I know the word framework from is software. Django is a framework for creating websites that does not require me to use every single function but provides me with things I can use when I need them. But according to the (very strongly worded, in this regard) Scrum Guide that's not what Scrum is supposed to be.

So... what is actually important?

How can Scrum be so popular if nobody uses it? :-/ I'm exaggerating again but who can prove that Scrum has benefits when everybody just picks the cherries and ignores the rest? :D

Since 2007, VersionOne (now called Digital.ai) has been surveying agility in a broad spectrum of organizations. Since the very first report, Scrum has been the leading framework identified as in use by organizations that believe they are on the path of agility. At the minimum, organizations think that they are using Scrum.

I'm not aware of any measurements around the number of organizations who claim to be doing Scrum and if they are truly using Scrum. What we do know is that Ken Schwaber and Jeff Sutherland spent several years introducing what would become Scrum to several organizations with success. They've written about these in books such as Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust, Scrum: The Art of Doing Twice the Work in Half the Time, Agile Software Development with Scrum, and The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process.

Although no one can prove that Scrum will work for a given organization without attempting to do it, I don't think that one can dispute the fact that it has worked for a broad spectrum of organizations and it's worth looking at.

I've read this sentiment from you in other forum posts, and I find it very interesting because my company implies that it's definitely Scrum that is used here. Officially we're not bound to do Scrum, we're only bound to use some agile methodology/framework (I'm really lost on the vocabulary here, see below). I couldn't find infos regarding ScrumXP on https://www.scaledagileframework.com/, could you provide a link to that? :)

The definition of Scaled Agile's ScrumXP is available.

I realise that it's called a framework, but I fail to understand what that is supposed to mean. To me, a process is "do steps A, B, C and don't deviate from it unless there are very specific reasons to" (and that would probably result in a new process, not doing the old one plus something different now and then; a methodology is maybe a toolbox I can pick stuff from? Or a set of processes? But what's a framework?

It is supposed to be lightweight compared to methodologies, if I understand correctly.

Another area where I know the word framework from is software. Django is a framework for creating websites that does not require me to use every single function but provides me with things I can use when I need them. But according to the (very strongly worded, in this regard) Scrum Guide that's not what Scrum is supposed to be.

Scrum is a lot like Django.

Django gives you a lot of pieces. It gives you an ORM. It gives you a forms engine. It gives you modules for things like logging, syndicating content, and generating sitemaps. All the standard things that you need for creating a web application. Not every web application will need everything it provides, but most web applications won't need to grab a lot of other dependencies until you get into domain-specific details.

Scrum is the same way. It gives you a lot of pieces and rules for developing solutions for complex problems. It gives you the structures for planning, doing the work, getting feedback from stakeholders, and improving the team's way of working. It wraps all of these things up in timeboxed iterations.

Now, there's a philosophical question. What happens if you replace Django's ORM with something like SQLAlchemy or the templating enging with Jinja2? Are you still using Django? I don't think there's a right or wrong answer, but I suspect that the authors of the Scrum Guide would say that using parts of Django and replacing others could result in a good framework for building your system, but it's not Django. In the context of Scrum, they say that "implementing only parts of Scrum is possible, the result is not Scrum".

Personally, I find the strict definition of Scrum helpful to make sure that Scrum is a useful term. If someone comes to me and says that they are using Scrum, then I immediately have at least a partial model of how the team works. If they ask about a specific problem, I have an idea of where to start looking, in terms of Scrum roles and events. If those roles and events aren't there, then I need to spend the time developing a model of the team works in order to understand how to help them.

So... what is actually important?

If you're looking for a single answer to this question that everyone agrees on, you won't find it.

I think that what is important is the underlying values and principles. These aren't only the values and principles laid out in the Scrum Guide, but the deeper values and principles from Agile Software Development and Lean Software Development. There are countless practices that support these values and principles that I've seen work with a good deal of success for a variety of teams in different contexts.

My guess is that Ian, Daniel, and others will have a different take on what's important. Ian talks about outcomes. Daniel talks about intents and principles. Intents and outcomes are also important, so I can't and won't say they are wrong. What is important to you - what you value - is going to change how you approach problems. There are different ways to approach the same problems and get good solutions.

So... what is actually important?

Empiricism and lean thinking. Transparency, Inspection and Adaptation and removal of waste.

Once we understand what this means, we can better understand how each Event, Artifact, Commitment and Accountability serves us empirically.

Each Artifact supports Transparency.

Each Event is an opportunity for Inspection and Adaptation of something which is made more effective through the aforementioned Transparency.

Each Commitment helps us with focus and not wasting our efforts on work or activities that do not support our goals. 

Each Accountability has parts to play with the above. 

You could pick and choose the parts you want to use, but they won't work as well in isolation as they are meant to be parts of a system.

As an analogy, you could try to use only the pawns when you play chess, but you will find yourself to be very limited and unlikely to succeed, particularly if your competition is playing with all of the pieces. If you decide to form the game into something else around your pawn only play, you have made a different game with different rules. It is no longer Chess, just as using only parts of Scrum is no longer Scrum.

Thanks Ryan, that's a useful analogy for me! :) And thanks Thomas, that was a very easy to follow analysis of a lot of the topics that fly around in my head right now!