Sprints
I'm not a fan of time-boxed sprints.
The workload is never even across team members. If the sprint ends this Friday, you always end up with some team members working around the clock to finish their stories, while other team members are done and playing ping pong. Maybe they could be helping their overworked teammates, but some tasks are hard to share and adding more people doesn't automatically speed things up. I think it's more important to have a regular, sustainable cadence for developing software than the artificial starts and stops and overloads and gaps you get with sprints.
Also, unless you have slack time, which sprints are designed to eliminate ("fill the sprint"), you don't have time to revisit code after you've come up with a better way to solve a problem. Scrum aims for predictable delivery at the expense of encouraging developers to come up with creative solutions, tweak existing implementations, tackle technical debt, etc.
Finally, time-boxing delivery means developers cut corners to wedge their stories into the sprint. No one likes having to tell the team you were almost done with a story, but the sprint ended, and you ran out of time. To avoid that, developers take shortcuts. The things that get cut are usually testing, refactoring, and making the code more robust. Developers need to balance gold-platting the code with delivering the code, but you can do that by talking with them instead of forcing an artificial delivery date.
Estimating and Sprint Planning
Having all team members sit in a long meeting to hear details on all the upcoming stories for the next sprint and reach some consensus on their estimated story points is a huge expense and waste of everyone's time.
You shouldn't need to estimate stories since the estimates become commitments and you will be wrong anyway. Plus, if you are working on the highest priority story, you are working on the right thing and going as fast as you professionally can. It will be ready when it's ready.
Most teams assign stories so not everyone works on each story. That means sitting through explanations of a story that may never fall in your lap is a waste of your time. It makes more sense to leave all the stories unassigned but ranked in priority order. Developers who are free should grab the top story, read it, and start asking for elaboration from the product owner or the person who added the story to the board.
Daily Standups
Daily standups are a thing managers like, but the people being managed don't. It's supposed to help communication and let management check in on how things are going.
But they become monotonous and routinized. "Yesterday I worked on X. Today I'm going to be working on X some more. I may have time to look at Y. No blocks."
The purpose of the daily standup is to surface problems a team member may be having so they can get help. But why do you have a team culture where people won't speak up as soon as they have a problem? Why do you ask them to do that on a schedule? It's far simpler to go in a common Slack channel and ask, "Is anyone who is familiar with the report module free? I'm stuck and could use some help."
If management wants to know the status of stories, they can look at the board, which should be constantly beaming out the latest status on each story in progress.
What's does scrum get mostly right?
It's not all bad. There are a handful of things we've plucked from scrum to incorporate into our software development process.
Definition of Done
I like that there is a unified definition of done that is created, socialized, and enforced by the team. Has the team agreed we are writing automated tests before a story is done? Great! Then you can gently remind a developer who forgot to write tests but moved the story that the team has agreed that's part of the work of each story.
Product Owner
I've been on projects where the product was owned by many people. It's difficult to get decisions made when more than one person is responsible. The best product owners are in the business, not a delegate of the business, and they have the connections to get answers when they don't know something off the top of their head.
I think the product owner role is something scrum gets mostly right, although I have heard the term product champion and like that better. Then the entire delivery team has a sense of ownership of the product with an enthusiastic cheerleader encouraging them to do their best work. When the delivery team feels they have decision making authority for adding and prioritizing stories, you can get amazing results. If they are yoked to a more hierarchical structure, they will do a good job, but probably nothing dazzling.
Retrospectives
Sprint has retrospectives at the end of the sprint to talk through what went well, what didn't, what the team wants to try differently next time, etc. These are a great idea, but I'm not a fan of having them scheduled regularly. As with the daily standups, if someone has a problem or a great idea for a process improvement, there's no time like the present to hear it. Waiting for the end of the sprint is artificial and leads to people forgetting that idea they had a week and a half ago. We do use the notion of retrospectives and continuously reflecting on how we can improve our processes, but every day is a good day to get better, not just at the end of a sprint interval.
