Friday, November 20, 2020

Dramatic changes in Scrum Guide 2020

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


   


     

  



Saturday, April 18, 2020

Essential Lean - Waste Red Flags


We need to find out the sources of waste, but that requires a very good and close observation of the overall process. Some wastes, tough are important, are difficult to identify. For example:
  • It is difficult to find that you have a lot of extra features or junk stories in your product. 
  • It is difficult to find that you have a lot of hidden work (for example product parts that are hard to read or are hard to change because of the technical debt) 
Some other sources of waste are easier to detect, and are induced by most of the others (see "Avalanche effect"):
  • Waiting
  • Defects


This means that, although we could successfully use Waiting and Defects wastes as red flags, finally we need to identify and eliminate the root causes. We should also remember that we cannot reduce the Lean goal of avoiding waste only to these two sources. Waiting is the main subject for the methods that use a visual control of the work. However, if something is harder to draw, it does not means that it is less important. There is no generic ranking between the main sources of waste and their impact is different from one context situation to another.

Essential Lean Series

Read first: Principles of lean thinking (by Mary Poppendieck)     

Essentializing Lean - essay
Essential Lean - Red Flags