Scrums biggest problem has always been management interpretation of sprints as deadlines (commitments) and not estimates (forecasts).
The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow.
Getting people at the top to understand that challenge is the hard part.
Scrum, XP and/or Agile are not going to save you if the guy leading the project decides the hardware and firmware have to be completely re-done for no good reason other than his own opinion, lack of experience and ego mixed in with a bit of "not invented here syndrome", "if it ain't broken fix it anyway" and "make it complex not simple stupid" (recent random example).
My point being: other aspects of companies and teams are far more important than the latest fashionable project management methodologies/frameworks/philosophies.
The critical piece to any framework is how work is prioritized. If it’s by 1 guy, you will have the problems you describe.
If you have an approach that forces the people doing prioritizing to weigh Return on Investment (benefit or value / estimated time) to largely guide the priorities, busywork with little benefit like you describe won’t be prioritized.
Often the people at the top understand. However what most developers fail to understand is the guy at the top really needs accurate estimates. the more accurate the estimate the better he can do their job. Thus they are constantly loohing for a magic bullet that gives them that. it doesm't need to be perfect, but the closer the better.
It's not that they need accurate estimates is that often sales people want to share those estimates externally, so anything that takes longer due to unexpected complexity becomes an accountability issue.
There is a balance there. sometimes you need to sell on the next version's features to get enough now to develob that. Not everyone gets unlimited venture capital - and it isn't always a good idea to take it if you can.
Accountability is everywhere, but software managers are always looking for the silver bullet that would let them have a stellar reputation of being on time.
> Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly.
And if people mean different things by the word scrum, it is rather hard to tell whether they are doing it properly :-)
Scrum is pretty difficult to do properly (the famous "easy to understand, but difficult to master" formula; although I would argue that it isn't that easy to understand either, at least not something that someone unfamiliar with it can understand in a day or two). It requires certain changes within the organization, which few organizations are willing to adopt.
I find this to be a problem with agile, but not so much with Scrum. It's quite proscriptive and there is a set of quite specific rules and processes you can follow.
> I find this to be a problem with agile, but not so much with Scrum.
I am seeing problems left and right. Mostly because people often copy the activities (they would often even call them rituals or ceremonies, as if to make it even more obvious that they are treating them as mysterious quasi-religious practices) without understanding what they are intended to achieve.
For example:
- Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.
- Lots of sprint reviews that are just demos
- Lots of sprints without goals, that are just timeboxes to finish a certain number of tickets/stories
- Lots of teams that remain hierarchical, and instead of a real product owner have some kind of a middle manager (who might also assume scrum master responsibility, because he is manager)
- Lots of teams focusing on story points, velocity, and estimation
- Lots of teams that don't adapt previously formed plans to the emerging reality
>Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.
I remember reading the scrum manual but I don't remember it saying anything about it being necessary to show esprit to corps and a "collaborative spirit" during standup.
It did say how to conduct a standup ceremony though...
>Lots of teams focusing on story points, velocity, and estimation
The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow.
Getting people at the top to understand that challenge is the hard part.