2017 Revisions to the Scrum Guide

Share this...
Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditDigg this

EDITOR’S NOTE: Troy Lightfoot watched the webcast of Jeff Sutherland & Ken Schwaber’s review of the 2017 Updates to the Scrum Guide.  Below are his observations.

Revisions to the Scrum Guide 2017

Ken and Jeff decided to incorporate community feedback and make some changes to the scrum guide this year. They started off discussing the state of Scrum with some amazing numbers…an estimated 90 percent of all agile teams are using scrum totaling approximately 12 million people daily. The latest state of agile report from VersionOne has respondents pegged at around 80 percent with either pure scrum or a hybrid of Scrum mixed with XP and/orKanban. Those are huge numbers which help demonstrate why it’s necessary to make improvements to the scrum guide based on community feedback.

The focus of this new revisions this year were:

  1. Uses of Scrum
  2. Refined the Role of the Scrum Master
  3. The Daily Scrum is for inspection and adaption to ensure progress toward the sprint goal.
  4. Time-Boxes carry a maximum length.
  5. Sprint backlog includes feedback from the sprint retrospective

 

Uses of Scrum

There is a focus in this revision to make it clear that scrum is a framework not just for software development but also almost anywhere. Some examples from the new scrum guide are below.

“Scrum has been used to…

  1. Research and identify viable markets, technologies, and product capabilities;
  2. Develop products and enhancements;
  3. Release products and enhancements, as frequently as many times per day;
  4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
  5. Sustain and renew products.

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.” – www.scrumguides.org

Refined Role of the Scrum Master

Ken and Jeff talked about the difficulty of the scrum master role as a change agent in an organization and how two key skills not often talked about for a scrum master are political skills and patience. Some minor language is included in this new revision moving from the word “ensure” to help, support, and promote.

Here is a quote:

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”

Reading into this a bit more, the scrum master is a scrum process expert and teacher not just to the scrum team but the organization as well. The scrum master must understand the scrum guide in depth and be able help others understand not only the process itself but the intent and reasons behind why those processes exist.

Added in service to the product owner section…

“Ensuring that goals, scope, and product domain are understood by everyone on the scrum team as well as possible”

Ken and Jeff also talked about the scrum master helping the team and organization understand lean thinking.

 

The Daily Scrum

They discussed the common problem of the daily scrum being a status meeting and not a planning meeting. They compared it to a football team huddling in between each play and figuring out the next plan of action to take in order to achieve the team’s goal of scoring. There is more of an emphasis now in the scrum guide on focusing on the sprint goal during the daily scrum and not so much on the “three questions.” In fact it’s now worded as…

“The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the sprint goal. Some Development Teams will use questions and some more will be more discussion based.”

The three questions also all end with “that helped the team achieve the sprint goal” (Note, that is not new.)

They referenced a white paper https://34slpa7u66f159hfp1fhl9aur1-wpengine.netdna-ssl.com/wp-content/uploads/2014/05/Shock-Therapy.pdf which describes “shock therapy” for implementing scrum. One of the practice it recommends is during the daily scrum, the team should focus on completing the highest priority item before starting on any new work. If a high priority item is still in progress, team members should plan how they can swarm on that item before pulling any new work. This is a fundamental in lean thinking and personally I’m glad they mentioned the scrum master coaching the team in this way.

 

Time Boxes

Jeff and Ken explained that a timebox is a maximum and not a minimum length of time. They used an example of how scrum teams at Amazon need a lot less time during sprint planning because they are doing continuous deployment; however other types of teams may need the maximum timebox length.

 

Retrospectives

The scrum guides now prescribes that at a minimum one retrospective item must be added to the next sprint backlog. Stating “to ensure continuous improvement, it includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.”

 

Misconceptions

They also addressed a few common misconceptions about scrum which included…

“Is scrum only good for software development?” – No

“Can I release before the end of a sprint?” – Yes

“What about dev ops?”

They said that scrum teams need an operational environment and an initial architecture wherein the service level agreement goals are being met. If the scrum team is empowered and the organization is supportive, the result is organizational change without crisis.

Scrum projects often require new capabilities to be instantiated and tested prior to proceeding.

 

Share this...
Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditDigg this

Leave a Reply

Your email address will not be published. Required fields are marked *