Do you use Scrum for your project or “only” Agile Project Management? You may be wondering: “Why this question?” For advocates of Scrum applies: If you don’t follow the Scrum Guide exactly, you don’t use Scrum, but something else. In this article you will read how to use the Scrum Guide and when it makes sense or is allowed to deviate from it. Curious? Read on and learn more.
The Result is Not Scrum
The last version of the Scrum Guide by Ken Schwaber and Jeff Sutherland is from November 2017. I know the Scrum Guide almost by heart, but I probably never read the final part so concentrated. In the “End Note” of the Scrum Guide 2017 you can read:
Scrum’s roles, events, artifacts, and rules are immutable and although 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.
Simply translated this means for me: If you don’t stick exactly to the Scrum Guide and deviate from it, you don’t use Scrum.
Do you also ask yourself why this is stated in the Scrum Guide? Maybe this is for all the people who say they use Scrum when they have a daily stand-up meeting or for those who surprisingly call their development phases Sprint? That’s definitely not Scrum and not even Agile Project Management! For Agile Project Management itself, there is no clear definition. But what Agile means in Project Management I described in this article.
Apply Scrum to the Point?
How strictly does Ken Schwaber and Jeff Sutherland mean the above statement? The Scrum Guide 2017 also states that Scrum is used today in many different areas and not only in software development but also in the development of hardware, embedded software, networks with interacting functions, autonomous vehicles, schools, government agencies, marketing, management of organizations and almost everything we use in our daily lives as individuals and societies. Really?
But I’m not so sure if Jeff Sutherland really thinks that these areas “apply Scrum to the point”. Also in his book “Scrum: The Art of Doing Twice the Work in Half the Time” he writes that Scrum is used for example as a method in Danish schools. But as I understood it, the students there only work self-organizing, but they are probably far away from Scrum.
The rules of Scrum may not be changed, according to Scrum Guide. But Scrum also allows freedoms, e.g.:
- How long a sprint can be: one, two, three or a maximum of 4 weeks
- How many teams work on a project
- How large a Scrum-Team is (recommendation: between 3 and 9 people)
- Which tools you use to monitor progress, for example Burn-down Chart, Burn-up Chart
- Which questions are used in the Daily Scrum
- For which projects Scrum is applicable: Software, Hardware, Industry, Schools etc.
Scrum as a Container for Other Methods and Techniques
You may have noticed that the above quote also says: “Scrum functions well as a container for other techniques, methodologies, and practices”. What exactly does this mean now? Scrum should be used unchanged, but Scrum may be supplemented by helpful, proven methods, techniques and practices. These are e.g.:
- Product Vision
- Release Plan
- Sprint Backlog (Selected Product Backlog)
- Taskboard
- Impediment Backlog
- Team Backlog
- Velocity Chart
- Rules for Collaboration
Scrum may be extended, but not changed.
When Does It Make Sense to Deviate from the Scrum Guide?
I see the Scrum Guide more as a guideline and not as a rigid set of rules. If you have not been working with Scrum for a long time, then you should follow the guidelines of the Scrum Guide. Over time, however, you will gain experience, try new things and perhaps deviate from the Scrum Guide in certain respects. Is that bad?
“Scrum proponents” like Jeff Sutherland say: If a Scrum team deviates from the roles, artifacts or events defined in the Scrum Guide, changes them or simply omits them, then this is no longer Scrum it’s “Scrum But”. According to the motto: “We use Scrum, but…”. Some examples are:
- We use Scrum, but the daily stand-up meetings cost too much time. That’s why we only do one every other day.
- We use Scrum, but this time we don’t manage to reach our sprint goal within the 14 days. So we just extend the sprint by one week.
I’m not that strict! If you deviate in certain points from the Scrum Guide and this helps the team and the project to become even more successful, then do this and share your good experiences! There are always good reasons to deviate from guidelines, to experiment and to learn. The Scrum Guide is from my point of view “only” a guideline.
Scrum is Agile Project Management, but Agile Project Management is definitely not Scrum.
Here is More Knowledge
This was a short summary of how to use Scrum and the Scrum Guide. What experience have you had with deviating from Scrum? Do you agree with my statements or do you have another view or additions? Share your experience with me and the readers in the comment box below. Thank you!
Would you like to learn more about how Scrum can make your Agile Projects even more successful? My book “Scrum – How to Successfully Apply Agile Project Management and Scrum” takes you an important step further!
Do you know anyone who might be interested in this article? Then simply forward it or share it in your network. Thank you very much!
Other Books mentioned in this article: “Scrum: The Art of Doing Twice the Work in Half the Time“
