Over the years I've seen numerous Scrum adaptions, and I thought perhaps it would be interesting, to sum up some of the common misinterpretations of Scrum. As my journey in the realm of Scrum continues, I have a hunch that this blog will never be finalized, which is not a bad thing though.
To keep it transparent and consistent, I've categorized the topics in the same manner as the Scrum Guide. I would love to hear about the misinterpretations that you have faced, so feel free to participate in the comment section. Enjoy and spread the love!
General
Scrum the abbreviation:
It's Scrum, not SCRUM. Scrum is not an acronym.
Reading the Scrum Guide once and think it's enough:
The more knowledge you gain and the more you start living and breathing Scrum, the more you will discover while reading the Scrum Guide. It has nothing to do with not understanding Scrum fully. Reading the Scrum Guide is a continuous inspect and adaptive cycle itself. I've been involved with Scrum for many years now and every time when I read the Scrum Guide, I manage to pick out something new.
Benefits of Scrum:
What are the benefits of applying Scrum? It's fun, will result in happier people, on time, no waste, time-to-market products, qualitative software etc. Is this true? It can be, it depends... Is it guaranteed? Definitely not!
"Scrum is an agile enabler" --Ken Schwaber
How does Scrum do it? By making all dysfunctions within your organization transparent. If your organization has the courage, commitment, respect, openness and focus on tackling these impediments and truly embrace empiricism, then yes, your organization can be agile. If not, no worries, the transformation is not a destination. It's a journey!
Velocity:
The word velocity is not mentioned in the Scrum Guide, yet almost every team uses it. So what is velocity?
"Velocity in Scrum actually is an indicator of productivity, an indicator of how much software, preferably releasable software, a team has produced in a Sprint. That, in turn, is not a promise, nor a contract for the future. Predictions are fragile. Empirical process control has the potential of antifragility. We embrace complexity." --Gunther Verheyen
For more information about velocity: https://guntherverheyen.com/2015/03/09/velocity-in-scrum-actually/
Scrum is perfect:
No, Scrum is not perfect nor is it complete. If not, Scrum has grown lighter and lighter. Over the past years, situational practices, prescriptions, and techniques have been removed from the Scrum Guide.
The Scrum Team
Who is the boss:
Right of the bat, in Scrum there are no bosses. Period! Only the roles of Product Owner, Scrum Master, and Development Team. Each role has responsibilities and accountabilities. Each role needs each other in order to deliver valuable increment.
Product Owner: A Product Owner should be seen as the owner of the product, the product CEO if you will. Great Product Owners are visionaries with an entrepreneurial mindset. They are the one with a product vision and needs a Development Team to turn that vision into a valuable increment. Instead of managing, the PO is a servant leader who should trust the self-organizing professionalism of the Development Team and Scrum Master.
Scrum Master: A Scrum Master's role is that of a coach and a teacher whose primary responsibilities include teaching Scrum theory, practices and rules alongside the three pillars of empiricism. A Scrum Master serves the Product Owner, Development Team and organization in their Scrum journey.
Partially because of the industrial revolution and Taylorism, we tend to think in hierarchy, the person who is hiring is the boss. No question ask. However, Scrum is also about change. It's not only a process framework but also a tool to enable Agile. Therefore it has the potential to change the way people in an organization think and behave. The word "hire" is no exception. The word "hire" should be given a new definition in this transformation as well.
The Product Owner
The Product Owner is the one writing the product Backlog Items:
"The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog." -- Scrum Guide 2017
This does not mean that the Product Owner is the only one who creates the Product Backlog Items. The Product Owner may do the work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is responsible for the prioritization of the Product Backlog:
The Product Owner is actually responsible for the ordering of the Product Backlog. When it comes to prioritization, it's a collaboration within the Scrum Team.
For more information about the Product Backlog and ordering vs prioritization: https://www.scrum.org/resources/blog/myth-5-scrum-product-backlog-prioritized
Scrum Master
Scrum Master vs. Agile Coach:
Ah, my favorite one. Is there a difference? Should there be a difference? I like to be bold and say no!
"A Scrum Master is an Agile Coach and an Agile Coach is what a Scrum Master should be"
Scrum Masters are not team facilitators. One of the 8 stances of a Scrum Masters is that of a change agent.
"Leading and coaching the organization in its Scrum adoption" --Scrum Guide 2017
So here it is, a Scrum Master is also a coach. Does this mean that every Scrum Master out there is a coach? Definitely not! Can everyone be a coach, maybe... In my opinion, the word coach is heavily underestimated. Couple months ago I started my coaching course at the International Coach Federation. What an eye-opener when it comes to things like active listening, asking powerful questions, shaping a relationship of trust, ethical code of respect, understanding the psychological complexity of the human being etc. Long story short, coaching is not easy, but again, being a Scrum Master should not be a walk through the park either ;)
Scrum Master, the facilitator, mentor, and coach:
When you ask anyone, "What does a Scrum Master do?", 9 out 10 times, you'll get answers like "a Scrum Master facilitates the Scrum Team by removing impediments". Is that it? Definitely not! A Scrum Master is a coach, servant leader, teacher, mentor, manager, impediment remover, facilitator and change agent. A Scrum Master serves not only the Scrum Team but also coaches the organization in her Scrum adoption.
For more information about the role of a Scrum Master: https://www.linkedin.com/pulse/8-stances-scrum-master-barry-overeem
The Scrum Master is responsible and accountable for the Sprint progress:
Always very frustrating to see vacancies like "Scrum Master/ Project Manager". No, a Scrum Master is not a project manager. A Scrum Master does not manage the Scrum team and is, in terms of self-organizing teams, definitely not responsible for the team performance. (how to influence a Development team in self-organizing, well, that's where it gets interesting right?) Then what are the responsibilities of a Scrum Master? Believe it or not, but it's actually clearly written in the Scrum guide.
Development Team
T-Shape is a must:
In Scrum, we talk about cross-functional teams and cross-functional teams have all the competencies to accomplish the work without depending on others not part of the team. The key word here is team, not multi-skilled individuals. Just to be clear, I'm not saying that teams should not have multi-skilled developers in their team. It would be great if you did. In my experience, I do see many organizations forcing developers to be "t-shaped" because otherwise "you're not doing Scrum" and that bothers me.
I believe Mike Cohn said it brilliantly in this blog: https://www.mountaingoatsoftware.com/blog/cross-functional-doesnt-mean-everyone-can-do-everything
Long story short:
"Cross-functional teams is a must, but T-Shape indivuduals is a choice"
Team Size:
"the optimal Development Team size is between 3 and 9" --Scrum Guide 2017
Note that the Scrum Guide is talking about the optional team size. This does not mean that a Development Team is required to split up into smaller teams only because it surpasses the 9 members.
For more information on team size: https://guntherverheyen.com/2015/03/10/team-size-in-scrum-actually/
Scrum events
Daily Scrum
Daily Scrum vs Daily Standup:
The Scrum event that happens every day, same location and the same time is called a Daily Scrum. Not a Daily Standup. Although I definitely see the benefits it is not mandatory to do it standing up. The word standup is derived from Extreme Programming where everything needed to be well...extreme.
Important note: Scrum is a framework within which you can employ various processes and techniques. Scrum simply say that the Development Team needs to come together daily and talk, not about how they should talk.
Start time Daily Scrum:
It doesn't matter at what time you do your Daily Scrum. As long as it is held every day at the same location and time to reduce complexity. The idea of doing the Daily Scrum immediately in the morning derives from Lean where they use the term "Day Start".
Participating vs. attending the Daily Scrum:
"The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum" --Scrum Guide 2017
The Scrum Master and Product Owner are not part of the Development Team, therefore they can attend but aren't required not participate in the Daily Scrum. The Development Team uses the Daily Scrum to inspect their progress toward their Sprint Goal and to inspect how progress is trending toward completing the work in their Sprint Backlog.
"Project thinking" in Scrum:
Yes, "project-thinking" is actually embedded in Scrum. In most organizations, there is usually a program which consists of projects. These projects have a start and end date and within this timespan, Scrum is being applied. Is this is the correct way? Actually, Scrum has a different way of project thinking.
"Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product" --Scrum Guide 2017
Scrum Artifacts:
Product Backlog
The purpose of providing estimations:
The purpose of estimation is not about coming up with an accurate estimation. It's about creating focus. Triggering a conversation that is needed to achieve mutual understanding and enhance transparency. In order to trigger conversation, different (optional) techniques like Planning Poker, Silent Voting, T-Shirt Sizing etc. can be used. The transparency can also help the Product Owner in the ordering process.
Themes, Epics, User Stories:
In Scrum, all items on the Product Backlog are called Product Backlog Items, not themes, epics, user stories etc. I've even worked in a company where they thought that "if you're not using User Stories, you're not doing Scrum". This, of course, does not mean that you can't use them. Nothing in Scrum is saying you can't use them. Just understand what is a part of Scrum and what isn't.
Artifact Transparency
Definition of Done
Potential Releasable Increment:
It used to be called a 'Potential Shippable Increment'. This has been changed to 'Potential Releasable Increment'. Why? To retain focus on what is exactly the Definition of Done. Potential Shippable can also be interpreted as potentially shippable TO ANOTHER DEPARTMENT!!