I appreciate the conversation and that assumptions about Scrum are being challenged. And I agree that Scrum is not a silver bullet.
But I’ve seen planning poker work. It does not always go like the author’s anecdote. If some dev just barks “20 points? REALLY?” when the team is trying to come to an estimate, that dev is an asshole and you’ve got larger problems.
And I’ve seen morning standups work too. Someone has to be tasked with keeping the team on task. The conservation needs to be limited to what happened yesterday, what happens today, and what blockers can the PM tackle for the team.
I’ve seen this work in large organizations. I’m not talking about an 8 person start-up. Just because it’s not universally applicable or successful doesn’t mean it needs to die in a fire.
(Nice troll style points for the title and the image of “Visual Studio TFS” branded planning poker cards though.)
Agreed. I also think the article misses massively on the “Why are we supposed to think developers are not business people?” It’s more the case that developers are not necessarily subject matter experts on the business subjects. Your US-based developer is going to understand international finance issues better than the international accounting folks? Please tell me more of all the magical unicorns you’ve employed who hold better subject matter expertise than.. well… those who work in the subjects.
I’ve noticed that developers themselves are very prone to the misconception that being good at writing software makes them good at everything that their software deals with. particularly annoying is when they have some reductive argument that they are convinced is correct because everyone else is clearly just overcomplicating things.
Also, planning poker isn’t scrum in the same way that syrup isn’t pancakes. Some people use them together, sure. But it’s a pretty weak argument.
On the other hand, there’s something to be said about how common it is to do “scrum plus” or “scrum but.” (And, indeed, much has been written about this, and a fair bit more coherently as well.)
It’s both a criticism and a mundane fact that scrum doesn’t reliability fix every organizational misstep within a group and the groups with which it must interact. It’s not a very opinionated framework, and so it tends to attract opinions, both in favor of planning poker and the like, and against.
I found most of the author’s arguments flimsy at best. If someone is grinding gears when shifting, it doesn’t mean that the manual transmission is flawed. It means that someone is practicing its usage incorrectly.
If someone grinds gears when they’re shifting it does mean the manual transmission is flawed, and it exposes its greatest flaw: it requires skill to use correctly, and is very easy to use incorrectly. Compare with an automatic transmission that “just works” in everything from econoboxes to supercars.
I’ve never been part of a scrum team like this. And at Google, I’ve never even seen scrum happen (counter to the author’s first sentence). Maybe other teams use it, but not mine. Where I work everyone just works on whatever they feel is important and you make sure to keep your manager informed.
Though I’m not saying self-management is generally applicable to all cases. When you are working on a tight release schedule for something like a smartphone and have very specific goals, self-management probably breaks apart.
I appreciate the conversation and that assumptions about Scrum are being challenged. And I agree that Scrum is not a silver bullet.
But I’ve seen planning poker work. It does not always go like the author’s anecdote. If some dev just barks “20 points? REALLY?” when the team is trying to come to an estimate, that dev is an asshole and you’ve got larger problems.
And I’ve seen morning standups work too. Someone has to be tasked with keeping the team on task. The conservation needs to be limited to what happened yesterday, what happens today, and what blockers can the PM tackle for the team.
I’ve seen this work in large organizations. I’m not talking about an 8 person start-up. Just because it’s not universally applicable or successful doesn’t mean it needs to die in a fire.
(Nice troll style points for the title and the image of “Visual Studio TFS” branded planning poker cards though.)
Agreed. I also think the article misses massively on the “Why are we supposed to think developers are not business people?” It’s more the case that developers are not necessarily subject matter experts on the business subjects. Your US-based developer is going to understand international finance issues better than the international accounting folks? Please tell me more of all the magical unicorns you’ve employed who hold better subject matter expertise than.. well… those who work in the subjects.
I’ve noticed that developers themselves are very prone to the misconception that being good at writing software makes them good at everything that their software deals with. particularly annoying is when they have some reductive argument that they are convinced is correct because everyone else is clearly just overcomplicating things.
Also, planning poker isn’t scrum in the same way that syrup isn’t pancakes. Some people use them together, sure. But it’s a pretty weak argument.
On the other hand, there’s something to be said about how common it is to do “scrum plus” or “scrum but.” (And, indeed, much has been written about this, and a fair bit more coherently as well.)
It’s both a criticism and a mundane fact that scrum doesn’t reliability fix every organizational misstep within a group and the groups with which it must interact. It’s not a very opinionated framework, and so it tends to attract opinions, both in favor of planning poker and the like, and against.
I found most of the author’s arguments flimsy at best. If someone is grinding gears when shifting, it doesn’t mean that the manual transmission is flawed. It means that someone is practicing its usage incorrectly.
If someone grinds gears when they’re shifting it does mean the manual transmission is flawed, and it exposes its greatest flaw: it requires skill to use correctly, and is very easy to use incorrectly. Compare with an automatic transmission that “just works” in everything from econoboxes to supercars.
I’ve never been part of a scrum team like this. And at Google, I’ve never even seen scrum happen (counter to the author’s first sentence). Maybe other teams use it, but not mine. Where I work everyone just works on whatever they feel is important and you make sure to keep your manager informed.
Though I’m not saying self-management is generally applicable to all cases. When you are working on a tight release schedule for something like a smartphone and have very specific goals, self-management probably breaks apart.
saying that anything needs to die in a fire is a great way to not have your argument taken seriously