Skip to main content

Scrum Guide Agility

Last post 07:35 pm September 9, 2016 by Alan Larimer
4 replies
05:36 am September 9, 2016

How many of you think like me with respect to that Scrum Guide itself is non-agile which gets updated once in 3 years or so as if it is not having much scope to get revised much more often while reality "could be exactly opposite"?


07:26 am September 9, 2016

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.


01:54 pm September 9, 2016

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.


02:15 pm September 9, 2016

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


07:35 pm September 9, 2016

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.