Candidly what every org is missing: accounting. IN a very literal sense. How much time did we spend on a feature, what was the cost. How much does it cost to run the feature? How much do people use the feature? Are we gaining or loosing clients because of it? Stuff someone from accounting into every dev team and make them live and die by the numbers.
A lot of features for resumes will die quick deaths.
I have seen (and often done myself) all of the following X items to avoid Y consequences in Scrum.
- Not written unit tests to get a ticket merged under the sprint timeline. We eventually turned them off at one org as a hindrance to merging tickets. Seriously, our unit test runner failed and to keep the sprint on track we disabled the tests. And to keep the project on track, they were never repaired. Scrum demands the sprint always provide value and as value is only what is provided to the user, no tests.
- Inflated points totals and conspired with others to inflate points totals so management is convinced pace is improving. I waited for my preferred and less diligent QA to be free to get a ticket done, so I am not interrogated holding up the burndown chart.
- Put unfinished functionality into the code as an error and merging it so that it would come back as a bug report, allowing the ticket size to be inflated for the same work.
- Skipping obscure edge cases found later if they would take more time, to avoid a lecture about the importance of detailed grooming. One job got to the point of specifying which files and functions needed to be changed for higher precision.
- Finished a task in the morning and then waited until the next day to pick up a new ticket because points is tied to days and you don't want the Scrum master asking why something is delayed in the burndown chart because you really only had half a day from when you assigned it to yourself.
The central failing of Scrum is that it is built on:
> Commitment, Focus, Openness, Respect, and Courage
And 1,3, and 5 in particular are either about different things for different people, or simply are absent because of the reality of a corporate hierarchy (i.e. it is always in your interest to suck up and seem reliable while hiding failures).
And to stave of possibly detrimental short-termism a culture of brain-storming systematic solutions to any significant problem (technical or HR) that has had a history of occurring more than once.
Work talk discussions should constantly revolve around tradeoffs instead of the word "deadline".
+1 to doing away with daily status meetings if unproductive.
I hate sprints. It really feels like they're forcing us to come up with rough deadlines for arbitrary work, then treat those deadlines like a contract. We're playing ourselves.
I also hate all the ceremony around planning sprints. I'd much rather have a constantly sorted backlog and let the manager types focus on keeping the top tickets clear and actionable.
Beyond that, you're asking a bunch of (probably) introverts to have a social meeting every. single. morning. That couldn't possibly cause issues with job satisfaction could it?
I did scrum for the first three or so years of my career. In my latest role we don't, and it's a way, way better daily routine.
Fix it with Kanban. Or at least the Kanban-flavored way of working where you set top priorities, keep lines of communication open, and just do what matters.
All processes can be screwed up if your leaders try hard enough, but Scrum is almost never the answer.
For my current team, I like either sync or async (in Slack) standups that basically say if anyone's blocked or could use some extra eyes, and what's next in their sights. For a team project board, I prefer Kanban style without estimates--I've never seen velocity tracking used to any purposeful effect. If you want a team to build good features fast, don't bother them with "process theatre", instead ask the team lead/PM the questions and they should either have a good sense or be able to find out soon by having human discussions with the team.
The fix is... just trust? You can do standups async, in text. Or better still, expect devs to move tickets accordingly.
We moved to monthly retros. They're a good fighting ground - people will argue about how we do deployment, QA, etc. We often argue on scrum and processes too. These are useful to do frequently early on and then reduce later. Sometimes we use them when something is slipping.
You can have demos just to showcase new features, without having to demo the API or do it live. Live wastes a lot of time because things suddenly don't work or people show uninteresting parts like loading or navigating all the way from the home screen.
The scrum guide 2020 doesn't mention story points at all.
I don't know how to fix this. But maybe we should just go back to plan in hours..
“Scrum works … if it is being properly implemented and followed.”
Sure that is with almost everything. In addition if you need an army of scrum coaches to implement scrum and you see many failures in the industry isn’t it time to rethink the process how we create software?
Maybe scrum isn’t the solution but just a stepping stone that came after waterfall.
Other problem is that doing any kind of deep work in a two week sprints is highly risky. You don't want to get to the end of the sprint with anything 90% done, because it doesn't matter, you're a failure. And when you have other things to do beyond crunching tickets, anything that would take more than a couple of uninterrupted days to be done become highly risky, because the deadline is there next week looking at you.