One reason Scrum is done in so many different ways is that there are hundreds of greedy training organizations that teach it in various ways. Scrum is just a Framework. As an Agile Coach and Scrum Master, I teach Jeff and Ken's Scrum Guide, and then we implement what fits the team. At the retrospective, they discuss and may determine better ways to improve their process. I see so many Scrum teams being destroyed due to the incompetence of the Scrum Masters. The name of the game is to teach the team to be self-managing, meaning they internally decide who does what, when, and how.
And as far as Story points that came from XP, even the originator wishes he had never come up with the concept due to them being abused so much by Velocity. Management uses Velocity to measure teams against teams and individuals against individuals. Even if Velocity is used as it should be for a single team, it is inaccurate. If half the team is out sick, they have poor Velocity, and they are accused of being lazy. Management doesn't care about Capacity, they just see the change in Velocity and are accusatory.
The term "Scrum Team" should be abolished. These are software development teams. Scrum is a tool that, as stated in the article, people do not use correctly most of the time, if there is even such a thing as a correct scrum. Scrum is fairly small part of the dev process, but is sold as if it is the be all and end all, and ends up wasting so much time - better to be agile. The article is the "agile mindset" vs fixed processes expressed quite well.
But seriously: Teams should look at Scrum and take what they find useful. How can you establish this when you’re supposed to do Scrum by the book by outsiders, management, trainers? Any ideas, Maarten? How can one convince people who never worked in a scrumteam but believe in the “rule book”?
Scrum framework is just a the starting template. When I interview veteran SM, my main question is, how did you evolve scrum in your org? If they're still stuck at the "guide" level, they're not SM as they're missing the "being" Agile part. They're stuck in "doing" Agile.
One reason Scrum is done in so many different ways is that there are hundreds of greedy training organizations that teach it in various ways. Scrum is just a Framework. As an Agile Coach and Scrum Master, I teach Jeff and Ken's Scrum Guide, and then we implement what fits the team. At the retrospective, they discuss and may determine better ways to improve their process. I see so many Scrum teams being destroyed due to the incompetence of the Scrum Masters. The name of the game is to teach the team to be self-managing, meaning they internally decide who does what, when, and how.
And as far as Story points that came from XP, even the originator wishes he had never come up with the concept due to them being abused so much by Velocity. Management uses Velocity to measure teams against teams and individuals against individuals. Even if Velocity is used as it should be for a single team, it is inaccurate. If half the team is out sick, they have poor Velocity, and they are accused of being lazy. Management doesn't care about Capacity, they just see the change in Velocity and are accusatory.
The term "Scrum Team" should be abolished. These are software development teams. Scrum is a tool that, as stated in the article, people do not use correctly most of the time, if there is even such a thing as a correct scrum. Scrum is fairly small part of the dev process, but is sold as if it is the be all and end all, and ends up wasting so much time - better to be agile. The article is the "agile mindset" vs fixed processes expressed quite well.
What’s your take on extending sprints?
I don't see the point. Sprints should be lightweight, so extending becomes besides the point.
The consideration of extending Sprints usually becomes into the picture when Sprints are meeting heavy and sluggish.
I had to chuckle at the subtitle!
But seriously: Teams should look at Scrum and take what they find useful. How can you establish this when you’re supposed to do Scrum by the book by outsiders, management, trainers? Any ideas, Maarten? How can one convince people who never worked in a scrumteam but believe in the “rule book”?
Scrum framework is just a the starting template. When I interview veteran SM, my main question is, how did you evolve scrum in your org? If they're still stuck at the "guide" level, they're not SM as they're missing the "being" Agile part. They're stuck in "doing" Agile.