Scrum Guide Update, November 2017
This November Jeff Sutherland and Ken Schwaber published a new version of the Scrum Guide. In this article I’d like to discuss the biggest changes and their comments out of their webcast on this Scrum Guide update.
Uses of Scrum
There is a lot to do about the uses of Scrum. If you read the old Scrum Guides it focuses on software and hardware development. Even the team that is adding the value is called “Development Team”. Nowadays Scrum is adopted in more areas than software / hardware development alone. The current version of the Scrum Guide reflects the uses of Scrum today.
The Scrum Guide states also the following:
Scrum proved especially effective in iterative and incremental knowledge transfer. Small teams of people are essential to Scrum. The individual team is highly flexible and adaptive. These strengths continue if multiple teams are working together to do any kind of complex work.
When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work.
Mastery of the Scrum Master
The 2016 edition of the Scrum Guide defines the responsibility of the Scrum Master as follows:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practises, and rules.
Well… this does not mean the Scrum Master is the personal assistant of the Development Team to book rooms, take notes, organise meetings, creating reports, etc. What I’ve seen too is that junior developers get assigned the role of Scrum Master to do the stuff I just mentioned.
In order to emphasise the importance of the Mastery role of the Scrum Master the phrases above are changed into the following:
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, practises, rules, and values.
In other words, the Scrum Master is supporting the Product Owners and Development teams to understand Scrum and work the Scrum way. What means a lot of coaching, training and challenging Scrum Teams to improve. Remind that the Development Team is self-organising, so they have to do all the PA work by themselves ;-)
Three Questions no more at the Daily Scrum
The biggest change in this Scrum Guide update is the change in the Daily Scrum. In the webcast Jeff and Ken talk about the meaning of the Daily Scrum, inspect and adapt the planning to meet the sprint goal at the end of the Sprint. The biggest pitfall is that during the meeting sharing progress becomes the main goal.
In the old version, there were three mandatory questions. What did u do yesterday? What are you going to do today? And do you see any impediments? The overall question that should be the one talking about is more like: “What are we going to do to finish the top user story today?”
In the new Scrum Guide the three questions are no longer mandatory. The first paragraph reads now:
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimises team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
During the Daily Scrum the Development Team can add, change or remove tasks from User Stories. As long as it serves to meet the Sprint Goal.
Scrum vs. DevOps
In the webcast Jeff and Ken answer the question “What about DevOps?”. They point out the following:
The Development Team has to prove in the first couple of Sprints that the product is viable and will produce value. To do this, they need an operation environment and the initial architecture wherein the SLA goals are being met. If the Scrum Team is empowered and the organisation is supportive, the result is organisational change without crisis. Scrum projects often require new capabilities to be instantiated and tested prior proceeding (minimise risk early).
They also say that DevOps is based on a misunderstanding of Scrum. Scrum is not meant for development only. Like build a release and sent it to Operations to install it in production. In their example, they talk about having the Ops disciplines supporting the Development Team. The Ops team should provide the Development Team the platform (hardware / software) to run the software.
In my opinion DevOps is a result of a real-life problem that huge organisations have in gluing the different departments (with different ways of working) together. When you talk about Operations you have a combination of a lot of disciplines (and their company policies). A few examples of disciplines you can find in Operations are: Infrastructure Engineers, Platform (Windows, Linux or Cloud) Engineers, Security Officers, Database Administrators, Technical Support experts, and so on.
I agree that Ops should support the Development Team, but I don’t know if Scrum is always the right answer to it. A way Ops can support the Development Team is by providing technology for the team to use like Continues Testing, Deployment and Integration. This way feedback is available to the Development Team as soon as possible.
Further reading or watching
Below you can watch the full Scrum Update webcast of Jeff Sutherland and Ken Schwaber. The online and PDF versions are available on the Scrum Guide website scrumguides.org.
