Hva er nytt i Scrum?

Jeg har tidligere proklamert “Det kommer ingen Scrum 2.0” og det er fremdeles slik jeg tolker herrene Jeff Sutherland og Ken Schwaber. Men det forhindrer ikke at Scrum guiden på Scrum.org nylig fikk en oppdatering. Ingen stor dramatikk i endringen, men enkelte presiseringer og endringer kan være verd og merke seg.

Endringene forklares av Ken selv i denne podcasten. En kortversjon av endringene finner du her.

Jeg synes enkelte endringer er ubetydelige, noen er gledelige og andre kan være mer problematiske. Her følger noen synspunkter.

Gledelig endring

Det er gledelig at Release Planning meeting og Release Burndown nå ikke lenger er en del av Scrum. Dette er gledelig siden det har vært en tendens til at “gammeldagse” prosjektledere har brukt dette som en slags unnskyldning for å ikke release oftere og oftere. En eller annen form for langsiktig planlegging er selvsagt fornuftig, men dette tones altså ned i Scrum Guiden. Teknikker som Road Maps, Minimal Marketable Features, Story Mapping osv kan passe å bruke her, men Scrum skal som kjent ikke inneholde teknikker.

Problematisk

Jeg liker ikke at ordet commitment er erstattet av forecast for Sprint planleggingen. Bakgrunnen er at mange opplever at commitment er et litt for sterkt ord og at en del ledere vil opplever dette som et løfte. I komplekse IT-satsninger er det selvsagt umulig å love noe. Men vi kan love å gjøre vårt beste! Og vi kan jobbe hardt for å rydde unna avhengigheter og usikkerhet slik at vi får tro på Sprinten. Jeg liker å knytte forpliktelse til Sprinten for å være tydelige på at Product Backlog i motsetning til Sprinten ikke kan være en forpliktelse. Enkelt sagt tydeliggjør dette forskjellen mellom Product Backlog og Sprint Backlog. Forecast er jo som i en værmelding en slags prognose over hva vi sannsynligvis vil klare å levere. Helt greit det og, men vi mister da verktøyet for å nyenasere forskjellen på Product Backlog og Sprinten.

Ubetydelige presiseringer

Jeg synes det er en grei presisering at Scrum Teamet nå omfatter produkteier, Scrum Master og utviklingsteamet – the Development Team. Viktig å få fram at PO, SM og utviklerne må fungere som et team.

Helt OK også at burndown chart ikke lenger er mandatory. Andre teknikker kan fungere like fint når det gjelder å holde rede på gjenstående arbeid og hvordan man ligger an.

Bruken av Sprint Backlog er åpnet litt opp. Ikke lenger nødvendig å lage tasks – man kan jo for eksempel velge å bryte ned Sprinten Broduct Backlog Items på en annen måte. Eller ikke bryte ned i det hele tatt.

Product Backloggen er nå ordnet (ordered) i stedet for prioritert (prioritized). Poenget er at den til enhver tid skal ligge i en bestemt rekkefølge som PO har bestemt. Jeg synes denne endringen er ganske ubetydelig og de som vil kan lese Jim Copliens begrunnelse her.

 

 

 

Posted on August 5, 2011 at 5:40 pm by gamsjo · Permalink
In: Scrum · Tagged with: 

7 Responses

Subscribe to comments via RSS

  1. Written by Stein Inge Morisbak
    on 05/08/2011 at 8:29 pm
    Reply · WordPress › Error