Scrum Guide Agility

I would imagine that during the early phases of Scrum, when Ken Schwaber and Jeff Sutherland were honing their ideas that the "definition" of what they were doing would change regularly. I'm sure that they would try things out and then observe the results -- some things (like the concept of a Sprint, a planning session, etc.) would have been seen as good, while others (hopping on one leg for the entire Sprint (maybe)) were seen as being bad, or at least not explicitly good.

There was then considerable effort, which I understand has really only happened over the past 8-10 years to boil off everything that isn't what is strictly necessary; so the practices, techniques and even tools that are common to many successful Scrum teams, but aren't strictly necessary were removed from the rulebook.

What we have today is a concise set of rules. Why aren't these frequently updated? Quite simply because they don't need to be. Teams are free to use whatever practices they wish in accordance with these rules (or indeed not in accordance with them if they choose not to use the Scrum framework) and these practices can and should be inspected and adapted frequently. The rules though, are largely static.

What we've really seen in recent updates to The Scrum Guide isn't changes to the rules, but rather clarifications of what things mean -- the switching out of "commitment" for "forecast" with relation to the Sprint Backlog for example; the word has changed, but the intended meaning of it has remained the same. The addition of the Scrum values in the most recent version didn't change anything as such, but it did make it explicit that the values mattered.


So, I don't think The Scrum Guide is developed in an 'agile' way [any more], but for good reason -- the rules of a mature game shouldn't need to change on a regular basis, and if they did then the game would probably provide little value in reducing complexity, or controlling risk.

That said, I think that the community has influence over the guide (as is evident from the inclusion of the scrum values), which is a good thing.

I would 2nd Ramsay's comments for the most part. Would you put out new code if it wasn't needed for example just because you are Agile and feel you need to release code at certain regiments? That would be a wasted effort, money and completely disruptive. With Product Ownership comes releasing VALUE. If Ken and Jeff were to release versions of the Scrum Guide often, who would keep up, how would that disrupt organizations using Scrum and in reality of this empirical framework, we do what? We learn from what is there, from what we are doing and improve upon it as needed. So, to learn, we must do and that is why both Ken and Jeff work with Scrum, work in organizations and with organizations that are using Scrum and based on what they learn from that, they improve the Framework.

Like Ramsay wrote, the rules are the rules of Scrum and those shouldn't change often. What do are the practices that you use within Scrum and those are constantly being adapted by those who use them.

Those are good discussions. Let me wait for more discussion before I could post some conclusion with concrete data to support.

Here here to both responses!! I especially like Mr. Naiburg's example of modifying software. Much like any product or system, there is an initial flurry of activity which slows over time. Within an organization adopting the Scrum framework, initially there will be a multitude of additions and changes; as things mature, the rate and number of changes will naturally decrease.