On 7 November 2017, the two fathers of Scrum, Ken Schwaber and Jeff Sutherland, presented a new version of the Scrum Guide. The previous version had been issued in July 2016. This latest version is available in English. I would like to use this blog entry to briefly highlight the key changes.
New chapter: Uses of Scrum
This explicitly explains that Scrum can be used not just for the development of software, but also for hardware, networks, cars, buildings, schools, government, marketing, business operations, in fact basically for almost everything you need in daily life.
In essence it involves small, multi-functional teams working collaboratively to solve complex problems, with the aim of developing or further developing a product or service in order to bring benefits to a large number of users.
Strengthening of the Scrum Master role
The Scrum Master is responsible for the promotion and support of Scrum, as defined in the Scrum Guide. The Scrum Master does this by helping everyone in the organisation understand and embrace the Scrum theory, practices, rules and values.
Daily is an Inspect & Adapt
Ken and Jeff again emphasise that the Daily is not a Status Report. Its focus is on determining whether or not the sprint goal can be achieved and how to eliminate possible obstacles. It is a brief Inspect & Adapt opportunity, whereby it is also entirely possible to change the plan.
The structure of a Daily is defined by the development team and can also be done without a Scrum Master.
Time boxes are a maximum and not a guide value
Time boxes are to be understood as a maximum, not as a specification. It would be ideal if less than half this time were taken, so that, for example, planning might also be completed in less than two hours.
Retrospective improvements in the Sprint Backlog
By the end of the sprint retrospective, the Scrum team should have identified improvements that it can implement in the next sprint. My personal recommendation in this regard is to list the implementation of these enhancements as high-priority backlog items in the Sprint Backlog.
DevOps and Releases
Scrum does not rule out DevOps, but in fact welcomes this. In other words, a DevOps team can also work pursuant to Scrum. DevOps supports the agile idea of delivering valuable software on a regular basis. However, Scrum does not state that a release should be made after each sprint, so this can be done independently of the sprint.