The circumstances where Scrum is used are diverse. When people get Scrum to work well for them, they have had to make it fit their situation. They often feel that was a shortcoming of Scrum, and if we only “updated” Scrum to include their addendum, everyone would benefit. Product backlog refinement has been a frequently visited topic:
Product Backlog Refinement: the process of adding detail, order, and estimates to inventory in a backlog. Items will have been refined to a sufficient degree once they are ready to be worked on. Refinement is best conducted by those who will eventually do the work.
My response: Scrum is a general-purpose framework applicable in complex situations, where more is unknown about the parameters than is known. The rules of empiricism and self-organizing make it work within short iterations that control the risk and increase chances of finding answers and creating value. The few roles, artifacts and events are fixed so the Scrum team can focus on unraveling complexity.
READ the ABOVE CAREFULLY again. It is important to take to heart.
METHODOLOGISTS ALWAYS WANT TO ADD TO SCRUM so it works better when circumstances exist or people want to increase the chances of getting the outcome they desire.
In doing so, they limit the applicability of Scrum. What if Scrum is being employed to get answers from research: Let’s use Scrum to determine if a specific tool set and cloud can really be used for this high volume, ultra-secure purpose? Many of the “enhancements” such as product backlog refinement would hinder.
Etc.
When we worked with you to help you learn and understand Scrum, we invested in you so you could train/mentor other people how to apply Scrum to their previously unapproachable situation. Each outcome helps people learn to work in teams to get outcomes from previously intractable situations.
Every time you attempt to make Scrum more specific from what you learned, you make it less useful to the rest of us.
Approach Scrum with humility. Learn and grow as you use it. Solve complex problems with Scrum as it is.
Or, you can create situation-specific Scrum variants, that you own and sustain. But, they aren’t Scrum.
Scrum On
Ken
Ken Schwaber's Blog: Telling It Like It Is 
A great post. But so hard to determine that exact point where one crosses from Scrum to “not Scum”. And therein lies the challenge.
Great time for me to read this. A client just discovered that a story completed and delivered during the current sprint missed the mark. It wasn’t until the end user put the feature to use that he realized the developer had used the wrong data source. On the one hand, the user acceptance test uncovered the error, the sprint is still in progress, so there may be an opportunity to correct the error and deliver working software that adds value during the sprint. On the other hand, I realize that all the players participated in the Scrum events in a sort of superficial way. Had there been more of a conversation around the story, and had there been better acceptance criteria, and had the developer and end user engaged in a better understanding of the problem and a potential solution, the outcome likely would have been different. The team didn’t take advantage of the opportunity to uncover complexity.
Ken is transforming the Scrum Guide in a sacred text, a holy scripture, which cannot be touched. It was revealed by himself, the Agile Prophet. He seldolmy mentions Jeff Sutterland, the true father of Scrum. And both are transforming Scrum in a dogmacric framework. This is not good.
“transforming the Scrum Guide in[to] a sacred text…”? I couldn’t disagree more with this comment. His point is very simple to understand – Scrum is a general purpose framework and not a specialized method. Other comments about being an “agile prophet” and failure to “mention Jeff” are just reckless insults that are both inappropriate and uncalled for. Question his logic if you will, but lets leave the personal insults out of it.
Where is the insult here? Ken’s comments on SAFe are a clear insult. However, almost everyone accepts his words because Ken is an unfailable Pope or Guru to his followers. Scrum is now an inmutable, perfect dogma that cannot be changed by anyone.
I am totally agree, that Scrum is best fitted for solving complex problems.
But in real life, the team is working on a product or better, responsible for a product, they will face complex and complicated work. Should they work have time Scrum and have time something else?
The dogmatic way in my opinion is not compatible with agile manifesto which says: Individuals and interaction over processes and tools.
Or the principle of inspect and adapt.
Good remark. Individuals and interaction over Scrum itself. Inspect and adapt, even Scrum itself. Otherwise, Scrum would not fit rhe Agile Manifesto.
Some solid baseline stays the same. It’s not set in stone. It’s your company & your money, do whatever you will with that.
Though without a solid baseline you may end up with some egocentric project managers that turn the work environment into living hell of politics and backstabbing.
Remember that project manager is a role, not a trade. Everyone can do that. Those less skilled in tech usually want to end up being project managers that try to weasel their way around the company by playing games and hiding the fact that they do mostly nothing.
If your company cannot do without managers then… good luck to you.
Isn’t it surprising that those who tweak or dismiss have spent a small fraction of effort that was initially exerted.
Thank you, Ken, for the post. I completely agree with what has been said there. I can only imagine a Product Owner of the public service, which employs 10M of users, and who is adding all the requested features from every user. I’m pretty sure that in this case the product can easily become useless. Same thing with Scrum. Jeff and Ken are great two owners of the Scrum Guide and we are JUST users. And Scrum is valuable as it is. Not because Jeff and Ken update it on every customer request.
Jeff and Ken are great two LORDS of Scrum and we are just their SLAVES.
No one forces you to try new things.
Reblogged this on Technology unplugged. and commented:
Why Scrum is what it is.
“Approach Scrum with humility. Learn and grow as you use it. Solve complex problems with Scrum as it is.”
Thanks Ken, this is really important. I will keep it on mind.
We cannot control anything or cause anticipate outcomes. We can use statistics to get a sense of outcomes, but there is not certainty.
Be aware HVAC Cleaning Company SCAMMERS!!!