Hello, my name is Illya Pavlichenko and I’m an Agile Coach and Professional Scrum Trainer (PST) at Unusual-Concepts. My job is all about dealing with Agile and Scrum dysfunctions and I love it. I work with multiple companies/teams and I see the same anti-patterns (symptoms) of using Scrum AGAIN and AGAIN. Well, I decided to create a list of them. It turned out to be exhaustively long. Then I removed less important items and finally got the list of 27 symptoms you can see below. Each of the symptoms potentially can lead to a separate article and/or discussion. That is why I attached quotes from best Scrum books (from my point of view) to make those symptoms as self-explanatory as possible. So, are you ready for 27 Scrum dysfunctions? Here it is - Rotten Scrum.

1. 2 Day Professional Scrum Master (PSM)
3 Day Professional Scrum Master (PSM+)
Illia Pavlichenko
Professional Scrum Trainer (PST)
ilya@unusual-concepts.com

2. Rotten Scrum
27 symptoms that you are NOT using Scrum properly

3. Scrum is not used entirely #1
Scrum exists only in its entirely and functions well as a container for other
techniques, methodologies, and practices (Scrum Guide, July 2013)

4. Scrum doesn't cause
organizational changes #2
Scrum isn't a process that you modify to fit your enterprise. Instead, it exposes every
dysfunction in your enterprise while you build products. Whenever people change
Scrum, it's because they have run into a problem, dysfunction, or conflict that they
do not want to face and fix (The Enterprise and Scrum, Ken Schwaber)

5. Development members not fully
dedicated to team #3
In Scrum, we are acutely aware that finding the bottlenecks in the flow
of work and focusing our efforts on eliminating them is a far more economically
sensible activity than trying to keep everyone 100% busy (Essential Scrum, Kenneth S.
rubin)

6. Development Team is not happy #4
Scrum is an enabler for building software products better and faster. But, most of all,
it restores energy and work pleasure for all of the involved players (Scrum a Pocket
guide, Gunther Verheyen)

7. Development Team is not cross-
functional #5
Cross-functional teams have all competencies needed to accomplish the work
without depending on others not part of the team. The team model in Scrum is
designed to optimize flexibility, creativity, and productivity (Scrum Guide, 2013)

8. Development Team is not self-
organizing #6
Self-organizing teams choose how best to accomplish their work, rather than being
directed by others outside the team (Scrum Guide, 2013)

9. Existence of Team Leaders,
Architects or similar roles #7
Scrum recognizes no titles for Development Team members other than Developer,
regardless of the work being performed by the person; there are no exceptions to
this rule (Scrum Guide, 2013)

10. No collaboration, lack of «we’re in
the same boat» attitude #8
Through shared working, teams create a sense of community and identity for their
projects. They are able to collectively converge on a purpose and a driving challenge
for the project. Decisions are consensus-driven, and team works in partnership
toward success (Collaboration Explained, Jean Tabaca)

11. Development Team does not use
modern Engineering practices #9
It's important to point out that just because Scrum doesn't include technical
activities within its scope should not lead anyone to conclude that it doesn't think
they are important (Martin Fowler, 2009)

12. No sustainable pace #10
People are respected in the time they can spend on their work via the idea of
Sustainable Pace. Work is organized in such a way that the tempo is sustainable,
indefinitely (Scrum A Pocket Guide, Gunther Verheyen)

13. Daily Scrum is a status meeting #11
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 (Scrum Guide, 2013)

14. UnDone work on Sprint Review #12
The Development Team demonstrates the work that it has “Done” and answers questions
about the Increment (Scrum Guide, 2013)

15. Sprint Review is a Demo #13
The Sprint Review is a meaningful dialog between the Product Owner and team members
about the existing product and its capabilities… Review should not be reduced to merely a team
presentation to an audience (The Professional Scrum Master’s Handbook, Stacia Viscardi)

16. No end users on Sprint Review #14
I strongly suggest inviting actual customers, and /or users, to the Sprint Review; this will
appreciate the chance to give feedback. This gesture also creates customer loyalty and builds
team excitement because team members get to talk to real live people using their product!
(The Professional Scrum Master’s Handbook, Stacia Viscardi)

17. Product Owner has no authority #15
A project with an underpowered product owner is much like a car with an underpowered
engine: The car runs, but it struggles when the going gets tough (Product Management
With Scrum, Roman Pinchler)

18. No Vision from Product Owner #16
The product owner is a visionary who can envision the final product and communicate the
vision. The product owner is also a doer who sees the vision through to completion (Product
Management With Scrum, Roman Pinchler)

19. Part-time Scrum Master #17
Developing a self-organizing team and building the relationships both within the team
and between the team and others is not an easy thing (Scrum Mastery, Geoff Watts)

20. Scrum Master with authority #18
The ability to lead without being bestowed butt-kicking privileges is the ultimate
challenge for a new Scrum Master. A truly respected leader requires no authority and
certainly no force (Scrum Without Cutting Corners, IIan Goldstein)

21. Scrum Master and Product Owner
in one #19
Merging the ScrumMaster and Product Owner roles removes the balance and thus the
neutrality of the role. There will no longer be any neutral facilitation, no protection of th
team or the process... I have never seen these two roles combined successfully (Scrum
Mastery, Geoff Watts)

22. Extending the Sprint length or too
long sprints #20
A short cycle forces you to focus on the essential and do away with productivity-sapping
habits from your waterfall days. Nothing cuts down on meeting bloat more than knowin
you have to deliver working software every seven days! (The Elements of Scrum, Chris
Sims)

23. «Ready» as a contract between
Development Team and Product
Owner #21
Product Backlog items that can be “Done” by the Development Team within one Sprint
are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually
acquire this degree of transparency through the above described refining activities
(Scrum Guide, 2013)

24. DoD does not strengthen over
time #22
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to
include more stringent criteria for higher quality (Scrum Guide, 2013)

25. Rare production releases #23
Value is an internal assumption within the organization until the software is actually
released to marketplace. Releasing software on the marketplace is the only way to
validate this assumption (Scrum a Pocket Guide, Gunther Verheyen)

26. Increment is not «ready for
production» #24
Scrum facilitates control through frequent, regular inspection and adaptation of transparent
software functionality. Transparency means the software is ready. It can either be immediately
deployed or built upon without regression. It has no technical debt. (Ken Schwaber, 2014)

27. Product Owner doesn’t attend
Retrospective #25
Assuming trust and safety are reasonably in place, an effective product owner is
critical to achieving the fast, flexible flow of business value and therefore should participate
in the sprint retrospective. (Essential Scrum, Kenneth S. Rubin)

28. Test or Design activities are done
outside the Sprint #26
In Agile all disciplines are performed in a non-linear, incremental way, in parallel and on a daily
basis, by cross-skilled teams with continuous collaboration and negotiation over emergent
ideas, techniques and practices (Scrum a Pocket Guide, Gunther Verheyen)

29. Non-development Sprints like UAT
or Hardening or Sprint Zero (0) #27
Each iteration creates an increment of potentially usable software. The functionality is
complete, with no work left undone. The result of one iteration is used as the starting point for
the next iteration (Software in 30 Days, Ken Schwaber and Jeff Sutherland)

30. Questions?