2 Day Professional Scrum Master (PSM)3 Day Professional Scrum Master (PSM+)

Illia PavlichenkoProfessional Scrum Trainer (PST)

ilya@unusual-concepts.com

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, methodologies, and practices (Scrum Guide, July 2013)

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)

Development members not fully dedicated to team #3

In Scrum, we are acutely aware that finding the bottlenecks in the flowof 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 the team or the process... I have never seen these two roles combined successfully (Scrum Mastery, Geoff Watts)

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 knowing you have to deliver working software every seven days! (The Elements of Scrum, Chris Sims)

«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)

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)

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)

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)

Product Owner doesn’t attend Retrospective #25

Assuming trust and safety are reasonably in place, an effective product owner iscritical to achieving the fast, flexible flow of business value and therefore should participatein the sprint retrospective. (Essential Scrum, Kenneth S. Rubin)

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)

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)

Questions?