> While they just try to focus on building software, Scrum dragged them into seemingly endless series of meetings called Reviews, Retrospectives, Plannings and Dailies.
This just caught my eye. The Scrum process as originally described had three meetings - one planning meeting per sprint, one retrospective per sprint, and one daily stand-up. It's a stand-up, as opposed to a sit-down, to try to enforce brevity. It's also typically recommended to spend 5% of your sprint in backlog grooming/refinement whatever we're calling it.
You should, of course, iterate on your process to make it suit yourself. My team, for example, decided that we'd spread that backlog refinement over multiple days to keep it short, sweet, and relevant. We probably spend more time on it than 5%, but that's purely self-interest, as it keeps our plannings short (we are usually coding by the afternoon of the first day of sprint), and our stories well-estimated and deliverable.
But then it's hardly reasonable to complain that your modified process means that the underlying principles are bad.
That grabbed me too. Our coders pretty much just code. They talk amongst each other sometimes to the PO to clarify requirements. That's about it. We never ask coders to write stories unless they're developer stories they have asked for themselves.
I worked a remote job last year which used Scrum. We typically would have 2 hour stand-up meetings per day, A 3 hour retrospective meeting every week (usually Friday) and 4-5 hour meetings at the end of each sprint for figuring out what we were going to be doing for the next sprint (every 2 weeks). The business owner would many times be figuring things out as we went along during these 5 hour meetings..sometimes painfully slow.
This was all for a 5 person dev team. I was consistently billing more hours for meetings than actual coding work. At one point, the owner decided to have a meeting every Friday to just "hangout" where we would either tell a joke or a story..to "get to know each other" (this was another hour). I was the only American working for the company. The rest of the team was from India, Mexico, and Egypt.
To give you an idea of the work environment, one of the other remote employees kept overwriting all of our git checkins. They never figured out who it was (I'm not sure why), but I had to re-do all of my checkins for 3 weeks. It was complete chaos.
I finally quit when my business started making enough for me to survive without it.
The icing on the cake was when the owner changed the name of the LLC a few months ago, so all of my shares became worthless.
Yep, that sounds pretty terrible. To give you a contrast, our stand-ups take 10 minutes at worst, and our retrospectives take 3 hours every third Friday, and plannings are about 3 hours also, again once per three week sprint.
> While they just try to focus on building software, Scrum dragged them into seemingly endless series of meetings called Reviews, Retrospectives, Plannings and Dailies.
This just caught my eye. The Scrum process as originally described had three meetings - one planning meeting per sprint, one retrospective per sprint, and one daily stand-up. It's a stand-up, as opposed to a sit-down, to try to enforce brevity. It's also typically recommended to spend 5% of your sprint in backlog grooming/refinement whatever we're calling it.
You should, of course, iterate on your process to make it suit yourself. My team, for example, decided that we'd spread that backlog refinement over multiple days to keep it short, sweet, and relevant. We probably spend more time on it than 5%, but that's purely self-interest, as it keeps our plannings short (we are usually coding by the afternoon of the first day of sprint), and our stories well-estimated and deliverable.
But then it's hardly reasonable to complain that your modified process means that the underlying principles are bad.