5 ms·

Scrum – False God of Innovation

10 points by bdehaaff 13y ago

Bhardwaj 13y ago
This is what happens when Scrum is not treated as a framework, but as the Bible. The whole point around agility (Including the Scrum framework) is Inspection + Adaption. Scrum does not solve problems - it merely brings them out in the open. It's a tool - not the goal. It's driven by the value, not the process. A seasoned agilist would ask you to build a great product with a great value even if it breaks the process. If somebody asked you to follow Scrum to the dot at the expense of the value then s/he has a problem in understanding agility. Wrong implementation of Agile is worse than the wrong implementation of a traditional approach!
- bdehaaff 13y ago
  Agreed. It's fundamental to address the "whys" and "whats" in addition to the "hows."
rhundhausen 13y ago
Just a few points about Scrum that you have wrong ... * Scrum is not a methodology or a process, just a framework * There is no product manager role in Scrum, but there is a Product Owner role * There is a big difference between "ownership" and "management", which could be the source of some of the dysfunction you are seeing * There is no formula for a Product Owner to follow. Remember, Scrum is just a framework, and the Scrum Team gets out of it what it puts into it. * You make the POs sound like victims by saying "... have not been able to really do anything about it". I think they were the wrong person for the job. * Product Owners should not attend the daily Scrum. It's just for the development team. Instead they could spend this time innovating! * A product's vision is manifested in a properly refined backlog. * It sounds like the first two struggles you listed (MVP and complaining customers) were caused by the PO being ineffective. The next three are just aspects of a PO's job responsibilities * Effective POs should be focusing on competitive research, market assessment, positioning, go-to-market readiness, etc. * I'm not sure where you came up with the notion that POs should be heads down. The Scrum Guide describes just the opposite. I do agree with your antidote at the end, that a PO should start with the goal, be transparent, and trust the dev team. If your article just these points, readers might find it valuable. I know you want to sell your product, but if you are going to bash Scrum in the process, you might want to up your game, and your facts. Richard
- bdehaaff 13y ago
  Thanks for taking the time to respond.

10 points by bdehaaff 13y ago

This is what happens when Scrum is not treated as a framework, but as the Bible. The whole point around agility (Including the Scrum framework) is Inspection + Adaption. Scrum does not solve problems - it merely brings them out in the open. It's a tool - not the goal. It's driven by the value, not the process. A seasoned agilist would ask you to build a great product with a great value even if it breaks the process. If somebody asked you to follow Scrum to the dot at the expense of the value then s/he has a problem in understanding agility. Wrong implementation of Agile is worse than the wrong implementation of a traditional approach!

bdehaaff 13y ago
Agreed. It's fundamental to address the "whys" and "whats" in addition to the "hows."

rhundhausen 13y ago

Just a few points about Scrum that you have wrong ... * Scrum is not a methodology or a process, just a framework * There is no product manager role in Scrum, but there is a Product Owner role * There is a big difference between "ownership" and "management", which could be the source of some of the dysfunction you are seeing * There is no formula for a Product Owner to follow. Remember, Scrum is just a framework, and the Scrum Team gets out of it what it puts into it. * You make the POs sound like victims by saying "... have not been able to really do anything about it". I think they were the wrong person for the job. * Product Owners should not attend the daily Scrum. It's just for the development team. Instead they could spend this time innovating! * A product's vision is manifested in a properly refined backlog. * It sounds like the first two struggles you listed (MVP and complaining customers) were caused by the PO being ineffective. The next three are just aspects of a PO's job responsibilities * Effective POs should be focusing on competitive research, market assessment, positioning, go-to-market readiness, etc. * I'm not sure where you came up with the notion that POs should be heads down. The Scrum Guide describes just the opposite. I do agree with your antidote at the end, that a PO should start with the goal, be transparent, and trust the dev team. If your article just these points, readers might find it valuable. I know you want to sell your product, but if you are going to bash Scrum in the process, you might want to up your game, and your facts. Richard

bdehaaff 13y ago
Thanks for taking the time to respond.