To Follow or Not To Follow Scrum Guide

According to the Scrum Guide:

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

I would say if you do something that contradicts the Scrum Guide, it's not Scrum. You might have found something that is better, or at least better for you.

In short, you are welcome to follow any practices you like, but Scrum is well defined, and if you are doing something else, it's not transparent to call it Scrum.

I have often found that if there is a temptation to omit part of Scrum, there's an underlying cause that needs to be understood.

For instance, with one Scrum Team I worked, we did not set Sprint Goals. When we found out that this is part of Scrum, we tried it. It was frustrating and time-consuming, and we discussed whether Sprint Goals were a complete waste of time, but we persevered. It remained a little frustrating, but they did eventually help us a bit.

Ultimately, though, this helped us all realize that our biggest problem was not having to set goals, but that we had an unfocused Product Backlog, which the Product Owner was not empowered to own, and that there was no clear vision for the future of our product.

We lacked a product mindset.

In some organizations, understanding that problem will only come from implementing Scrum properly; especially where it hurts.

Whether you can then fix the problems you see will depend on the willingness of those involved. This could extend well beyond the Scrum Team, and could involve management or even the entire organization.

It might be that if you implement Scrum, feel the pain, and try to resolve it, you will meet some kind of resistance. It might be that you ultimately cannot resolve the underlying problem.

Once it has been decided not to fix an impediment to Scrum working properly, it should be possible to have a mature conversation about the best course of action.

Perhaps it makes sense to persevere with Scrum (even when it causes problems); perhaps you should do something that is not Scrum, but follows many of its rules; perhaps you should stop using Scrum altogether.

I have read a number of articles saying we shouldn't just follow what the Scrum Guide says.

I would agree with that but what you are missing is that no where does it say not to follow the Scrum Guide.  I frequently will introduce some principles and techniques from various Agile practices.  But I honor the framework described in the Scrum Guide.  Scrum does not provide process so you will have to come up with your own processes.  From my experience and interactions with other Agile Coaches/Scrum Practitioners, I have found that very few people "just follow what the Scrum Guide says" because it does not say anything about process.  Humans are creatures that want process and that applies even more to many software developers.  

Following the Scrum Guide provides you with a framework that helps in making information transparent, introduces cadence of inspect and adapt, provides roles that can build successful teams, and provides flexibility to use processes that work for your team.  As a framework, that is what I would expect. 

I have read a number of articles saying we shouldn't just follow what the Scrum Guide says.

Can someone explain what it means and if we're not following the guide, how can we say that Scrum as a framework is implemented well in an organization?

It is also important to think about what the Scrum Guide says, and also about what it doesn't say and why it doesn't say it. Scrum is not a pick-and-choose framework where you can leave bits out, nor is it a methodology which can be "followed". There are a lot of options for implementing the framework and they need to be chosen wisely.

PART I “To Follow or Not To Follow the guide”

A. Think for yourself (not follow)

Scrum is not a process, technique, or definitive method so it is not really possible to ‘follow’ Scrum. Specific tactics for using the Scrum framework vary and are not described in the guide. You will need to think for yourself, make your own decisions, your own plans, your own mistakes, do your own work, celebrate the success of your work.   

B. You can structure your work using Scrum (not follow)

Scrum roles, events, artifacts and their interrelationships provide a frame within which you can structure your work. Scrum is the frame, it is not your work!

You may want to follow your plan, deliver your increment, achieve your goal. All that scum did is give you a frame of interrelated events, artifact and roles to come up with that plan, to manage that delivery, to focus on that goal.

C. You can understand the theory, foundation, approach, pillars of Scrum (not follow)

Scrum is founded on empiricism, asserting that knowledge comes from experience and making decisions based on what is known.

Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

D. You can live by/  embody/  learn/  explore the values of Scrum (not follow)

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.

The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

So if one defines A. ‘think for yourself’, B. ‘frame your work’, C. ‘theory…pillars’, D. ‘live by…explore’ as ‘not just follow’ then do not just follow.

The guide is …. a guide. It can help you but ultimately, you’re accountable for your journey and that includes the navigation, plotting a course, setting the speed, etc.

PART II “how can we say that Scrum as a framework is implemented well in an organization”

You're on the right track by asking the question. How would you answer your own question?

Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

So, if Scrum is used well it contributes to e.g:

Increased customer satisfaction through early and continuous delivery of valuable software

Change harnessed for the customer's competitive advantage

Lowered risks, increased predictability

Collaboration between business people and developers

Motivated individuals

Real teams

Sustainable development

Enhanced agility

Maximized amount of work not done

Best architectures, requirements, and designs

And last but not least Scrum use is made transparent, inspected and adapted

you may want to have a look at https://www.scrum.org/resources/evidence-based-management  

I have read a number of articles saying we shouldn't just follow what the Scrum Guide says.

Can someone explain what it means and if we're not following the guide, how can we say that Scrum as a framework is implemented well in an organization?

Does everyone agree with this?

For me, I agree that there are certain things that you can modify but it really depends on the context. Is the article saying you don't have to have a Daily Scrum, you can do it every other day or you don't have to stick to 15 minutes, you can go to 30 minutes? Well if the team is collocated, they likely won't need a daily scrum. If the team is distributed and time zones make for a challenge to meet every day, meeting every other day can definitely work for the team. Maybe the article said you could have managers attend the retro. Before you quote the SG saying that managers should not be allowed, take it into the context of the team. While I don't like managers being involved in Retros, there are teams that I have worked with where the level of trust between the team and the managers is so strong that the presence of a manager does not inhibit the team from sharing anything. How awesome is that? Why would we want to block that from happening simply because the SG says to not allow managers? 

On the other hand, if the articles are saying you don't need to do a review or retro; I strongly disagree with that. Those are foundational pieces of Scrum and must be utilized. Maybe the article said it's not a problem to extend your sprints as needed at random. How can the team calculate their velocity correctly? How do they plan accordingly if they change the timeline at random? How can the team deliver on a regular cadence if the sprint lengths change frequently?

As with most issues with Scrum that bring about these questions, it all depends on the context and what the team wants and what the team is faced with. 

Hi. I know it's been a while since I posted this, but I really value everyone's responses.

When I say that "follow the Scrum Guide", I did not mean Scrum's intentional gaps.

For example. our current Sprint Planning only answers the "What" since we are only pulling in work during the planning because the solutions are already laid out during refinement session. The reason for this is, we're not a co-located team and our timezones are different from each other so we can't have meetings for 8 hours (since we use 4-week sprints).

Now some say that the problem here is we're not co-located. Does this mean we have to be colocated, and ultimately Scrum won't work for teams with different timezones?

Hi Clint,

Has the team identified it as an impediment and if yes, have any suggestions for improvements been outlined? 

The thing is, they never really tried it since they know they don't want people to change their work hours. We "follow the sun" in terms of work hours.

and also about what it doesn't say and why it doesn't say it

This is so undervalued. Both in the Scrum framework, as in the theory behind, as in coaching both teams and individuals, listen to what is not being said. And why. Try to understand the logic behind it. 



Daniel already mentioned process; I think this is a good starting point for an internal discussion on your side just to grasp the idea. Why doesn't Scrum mention a process? Than take that kind of reasoning, and with that the way you get to your answer, to your original question:)

Because Scrum is a framework from which your process evolves.  Ken intentionally scaled the original Scrum Process down to a framework. Didn't want to be prescriptive to the point of no flexibility or empiricism.  Once you define everything in one place, you don't learn or improve, you just follow like a robot.  Add practices that work for you, your team or your organization. If they don't work, remove them and try other things.  The process that you use sits on top of the Scrum framework.  

You can see the original Scrum paper here.