Background

I've been scratching my head and reading more about Scrum lately. It's rather clear to me by know that Scrum needs some discipline, some interest and constant adjustment, to have an actual chance to work well for the team. What I'd like to share today is symptoms of Scrum at struggle, indicators that the agile process might not be treated as agile itself by the team. As any member of the teams involved, I am to blame for not turning the wheel around more myself, too.

I think it's important to talk about issues with Scrum, to identify causes, and to make adjustments to the process to not just "die faster" with Scrum.

So here's a few facets of a team struggling with Scrum:

Struggles

Daily Stand-Up Meetings

• Members struggle remembering what they did in general, yet few start taking and bringing notes
• Stand-Ups seems to keep catching everyone by surprise, while taking place the same time every day

Planning Meetings

• Stakeholder and/or product owner are at their phones rather than really listening
• Stakeholder wants to bypass backlog and priorities and discuss "just one small thing to be done this sprint"
• Tickets are too big to estimate well yet feel wrong or very tedious to split up further
• During Planning Poker: Estimates vary depending who would work on the ticket
• Estimating something as 2, 3, 5 or 8 does not get trivial and does not correlate to time put in well (because of things not taken into account that turn out later)

Retrospective Meetings

• No one feels like reporting anything for any of "went well", "went bad", "should be improve"; consensus is "business as usual, nothing special"
• Notes are just filed and not acted upon outside the team
• Constant struggle with telling "went bad" apart from "should be improved"

Review Meetings

• Stakeholders are not really interested to hear about or see things done
• Preparing demos to show during review takes a considerable amount of time (that does not seem to match value)

In General

• Tickets are often not ready-to-be-implemented
• Big topics (like architectural changes, updates of unsupported dependencies, decrease of technical depth) are procrastinated for month, rather than being addressed
• Team velocity does not stabilize for months (due to: sick leave, vacation, frequent change of members)
• Velocity is measured without taking (varying) total team hours into account
• Product owner does not help with decisions, rather mirrors questions back to developers
• Incidents produce new tickets that take priority and go into a sprint, directly
• Some team members want to improve the process (and take it seriously) while others consider that a waste of time (and take as "just a tool")
• Some team members care a lot about avoiding over-commitment while others are tending towards "we'll get done, what we'll get done"

Sounds familiar? Sounds very unfamiliar? Let me know