2 Day Professional Scrum Master (PSM)
3 Day Professional Scrum Master (PSM+)
Illia Pavlichenko
Professional Scrum Trainer ...
Rotten Scrum
27 symptoms that you are NOT using Scrum properly
Scrum is not used entirely #1
Scrum exists only in its entirely and functions well as a container for other
techniques, me...
Scrum doesn't cause
organizational changes #2
Scrum isn't a process that you modify to fit your enterprise. Instead, it ex...
Development members not fully
dedicated to team #3
In Scrum, we are acutely aware that finding the bottlenecks in the flow...
Development Team is not happy #4
Scrum is an enabler for building software products better and faster. But, most of all,
i...
Development Team is not cross-
functional #5
Cross-functional teams have all competencies needed to accomplish the work
wi...
Development Team is not self-
organizing #6
Self-organizing teams choose how best to accomplish their work, rather than be...
Existence of Team Leaders,
Architects or similar roles #7
Scrum recognizes no titles for Development Team members other th...
No collaboration, lack of «we’re in
the same boat» attitude #8
Through shared working, teams create a sense of community a...
Development Team does not use
modern Engineering practices #9
It's important to point out that just because Scrum doesn't ...
No sustainable pace #10
People are respected in the time they can spend on their work via the idea of
Sustainable Pace. Wo...
Daily Scrum is a status meeting #11
The Daily Scrum is a 15-minute time-boxed event for the Development Team to
synchroniz...
UnDone work on Sprint Review #12
The Development Team demonstrates the work that it has “Done” and answers questions
about...
Sprint Review is a Demo #13
The Sprint Review is a meaningful dialog between the Product Owner and team members
about the ...
No end users on Sprint Review #14
I strongly suggest inviting actual customers, and /or users, to the Sprint Review; this ...
Product Owner has no authority #15
A project with an underpowered product owner is much like a car with an underpowered
en...
No Vision from Product Owner #16
The product owner is a visionary who can envision the final product and communicate the
v...
Part-time Scrum Master #17
Developing a self-organizing team and building the relationships both within the team
and betwe...
Scrum Master with authority #18
The ability to lead without being bestowed butt-kicking privileges is the ultimate
challen...
Scrum Master and Product Owner
in one #19
Merging the ScrumMaster and Product Owner roles removes the balance and thus the...
Extending the Sprint length or too
long sprints #20
A short cycle forces you to focus on the essential and do away with pr...
«Ready» as a contract between
Development Team and Product
Owner #21
Product Backlog items that can be “Done” by the Devel...
DoD does not strengthen over
time #22
As Scrum Teams mature, it is expected that their definitions of “Done” will expand t...
Rare production releases #23
Value is an internal assumption within the organization until the software is actually
releas...
Increment is not «ready for
production» #24
Scrum facilitates control through frequent, regular inspection and adaptation ...
Product Owner doesn’t attend
Retrospective #25
Assuming trust and safety are reasonably in place, an effective product own...
Test or Design activities are done
outside the Sprint #26
In Agile all disciplines are performed in a non-linear, incremen...
Non-development Sprints like UAT
or Hardening or Sprint Zero (0) #27
Each iteration creates an increment of potentially us...
Questions?
Upcoming SlideShare
Loading in...5
×

Rotten Scrum

303

Published on

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.

Published in: Leadership & Management
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
303
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Rotten Scrum

  1. 1. 2 Day Professional Scrum Master (PSM) 3 Day Professional Scrum Master (PSM+) Illia Pavlichenko Professional Scrum Trainer (PST) ilya@unusual-concepts.com
  2. 2. Rotten Scrum 27 symptoms that you are NOT using Scrum properly
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. Questions?
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×