Scrum exists to expand scrum.
The role of scrum master is about scrum indoctrination.
The authors of scrum created that role to make the methodology viral.
The methodology is also vague enough to blame you for anything that goes wrong with it.
The role of scrum master is about scrum indoctrination.
The authors of scrum created that role to make the methodology viral.
The methodology is also vague enough to blame you for anything that goes wrong with it.
My current employer doesn't do it (they have a 'stand up' but it's just everyone telling what they're working on while nobody listens), and I have no clue when what will be finished - and neither does management.
I mean for my current project which will probably keep me occupied until the end of the month, I got a design document with a pretty decent todo list, but someone had already Decided that it would take about 5 days.
So far they don't seem confrontational or critical about it though, so idk, I guess they're okay with it.
Scrum reports = documentation.
Sources of truth are: the implementation, the business, customer satisfaction. And if you want to go deeper: technical debt, developer satisfaction, developer retention.
The more distracted you get with planning, the worse your product becomes and the more disempowered your developers become.
Scrum can work only if it is kept down to earth. But as soon as product managers stop meeting with developers, you have entered the path to technical bankruptcy.
Scrum is meant to promote collaboration between product manager and developers, but in most cases, product managers get away with avoiding this responsibility. And the reason is because scrum does not have provisions to keep product managers accountable...
Scrum does not define real deliverables for product managers, therefore in practice it becomes the opposite of what it promotes.
Shame really, Software Philosophers like Kent Beck kind of got lost in all that noise, who always emphasized the human aspect of software creation