Disclaimer - these are my personal opinions about Scrum Guide changes
Most changes are not substantial. In many cases, Scrum becomes more generic because we have less guidance on Scrum's rules and practices, and by default we are free to find more options. At the same time, the small set of fixed rules remains the same with one important exception.
The Sprint is no longer an iteration.
The Sprint is no longer an iteration. Scrum no longer provides the explicit backbone for the work life cycle. Scrum is changing even more in the direction that it is not a product development framework, but a support framework for product development.
Sprint Review changes
The desired outcome of the Sprint Review and Sprint end was changed.
2017 Guide - Sprint Review section
<<"A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the
Product Backlog if needed.">> - See [R1]
<<The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;>> - See [R1]
So, at the end of the Sprint during the review, the development team finds out from the PO what part of their work is done and what is not done. This is a kind of acceptance.
2020 Guide - Sprint Review section
<<The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.>> - See [R2]
<<During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. >> - See [R2]
Only one of the two objectives was kept: review of the work and adjustments of the plan, adaptation. It is no longer an acceptance to explain what is done and what is not done. Changes in the Increment could explain this part.
Increment Changes
2017 Guide - Increment section
<<The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” >> - See [R1]
<<The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it. >> - See [R1]
We have one Product Increment per Sprint, which is done at the end of the sprint, and which could be released or not. Consequently, the Sprint is an iteration. One (enhanced) iteration.
2020 Guide - Increment section
<<Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.>> - See [R2]
The Sprint will now group one or more Increments. Explaining what is done and what is not done is no longer one of the goals of the Sprint Review. The remaining Sprint Review scope is only about inspect & adapt part ("empiricism"). Explaining "what is done and what is not" will be necessarily happen before delivering some of the increments to the stakeholders (before the Sprint Review).
Here is the work sequence before the new Guide
- plan the Sprint
- development (all the stuff, including testing) the intended Increment
- review: PO accepting what is done (and that become the Product Increment produced by the Sprint), final inspect of adapt and a potential release
Here a possible sequence of work using the new guidance:
- plan
- For each increment: development + accepting what is done and what is not + potential release
- review: inspect & adapt
What is the difference?
Previously, Increment delivery was managed by Scrum explicit rules, while the Sprint was an enhanced iteration managed by the Scrum rules as well.
With the new guidance, Increments delivery is free-style, outside the Scrum rules. Scrum Sprint just plan several increments together and later analyze them post-factum in the same package.
What is the purpose of the change?
Scrum claims that is very generic. At least for software development, there are three main categories of solution delivery life-cycle: iterative (iterative-adaptive), lean and exploratory. The previous version of Scrum was purely iterative (Sprint ~ an enhanced iteration) and does not match with the cases when you produce increments of working software very fast (~lean life-cycle, sometime Kanban based).
The Scrum Ceremonial cannot be executed for small increments
The Scrum ceremonial cannot be executed for small increments (no time), so they change the Sprint definition to apply the ceremonial to more increments when needed.
What is the problem with this change?
Is not a problem with the change itself, but with the way as Scrum is presented and used. It was presented and used as an universal and generic approach, but it was a deception if you want to manage only with Scrum fast deliveries and high incertitude case. Now the deception is clarified: Scrum ceremonial in an iteration cannot handle all your types of solution delivery. Okay, but what about the new guidelines that make the Scrum more generic? Yes, Scrum become more generic by acknowledging the fact that will not manage the delivery life-cycle but will only provide support.
A good part of the delivery is out of scope for Scrum guidance
It is good time for the teams and organization using Scrum to understand that a Scrum-only approach is not a good idea, and Scrum small guidance needs to be complemented with other sources.
References
[R1] The 2017 Scrum GuideTM - https://www.scrumguides.org/scrum-guide.html
[R2] The 2020 Scrum GuideTM - https://www.scrumguides.org/scrum-guide-2017.html
No comments:
Post a Comment