Още 10 важни промени в Scrum Guide 2020

От Scrum Guide-а отпада изцяло терминологията, свързана с empirical process control theory. Съответно от гледна точка на теоретични основни се говори само за емпиризъм, а Scrum e дефиниран просто като framework (а не както преди – process framework).

Предполагам, че тази промяна в Scrum Guide е отново продиктувана от усилията на авторите да опростят ръководството, а не защото фундаментално се е променило нещо. Аз лично винаги, когато обяснявам механиката на Scrum в моите корпоративни обучения по Scrum, влизам в детайли и говоря за Теория на управлението (Control Theory). Без тази част вярвам, че човек по-трудно би могъл да си обясни какво точно се променя в процесите на една организация, въвеждайки Scrum.

В предишната версия на Scrum Guide-а се говори за т.нар. complex adaptive problems, които са характерни за сложните адаптивни системи (каквато по същество е софтуерната разработка). Е, и този детайл вече отсъства.

Допускам, че тази промяна се дължи на желанието на авторите на Scrum да повишат неговата приложимост в области, където типа решавани проблеми е по-различен.

Тази съществена характеристика на инкремента да е "potentially releasable" отпада. Задължителни остават само "done" и "usable".

Не съм сигурен каква е причината това изискване да не е дефинирано явно – може би отново, за да се повиши приложимостта на Scrum в области, различни от софтуерната разработка (където нямаш release-и). Аз лично много харесвах тази характеристика на Increment-a и съм виждал как, бъдейки част от Scrum Guide-а, тя дава допълнителен стимул на developer-ите да търсят начини, това което създават, да е potentially shippable (а не да изисква дълги фази на последваща финализация).

До сега Definition of Done се дифинираше първо на организационно ниво (това се запазва и сега), а в последствие се „разширяваше“ от Development Team-ът. Сега, за Definition of Done, отговаря целият Scrum Team.

Това е по-скоро очаквана промяна с оглед на новата роля, която заема Scrum Team-а. Също така, в своята практика често съм срещал съпротиви в Product Owner-ите от гледна точка на Definition of Done и това, че те „нямат думата“ при нейното опрделяне (докато качеството на Increment-а има пряко отношение върху доставената стойност за клиента). Ето защо приветствам тази промяна. Единствено се надявам Product Owner-ите да не злоупотребяват с новите си „правомощия“ и да не притискат developer-ите да правят компромиси с дефиницията (нещо, което също често се случва в практиката).

Това е поредната съществена промяна в Scrum Guide-a. Преди, всеки Development Team дефинираше сам своя Definition of Done в зависимост от спецификите и естеството на работа, нужна за създаването на своя Increment. Единственото условие беше тя да позволява интегрирането на отделните инкременти в един общ инкремент (най-малкото в края на спринтa). Вече това е различни и при Scaled Scrum всички трябва заедно да създадат общ Definition of Done и съответно да се придържат към него.

Не съм сигурен от какво е продиктувана тази промяна, но ми се струва трудно осъществима. Основната причина е, че понякога Scrum Team-ите действително извършват много различна по тип работа и в този ред на мисли няма как да имат и постигат едни и същи качествени изисквания.

Този въпрос не беше съвсем ясен в предишните версии на Scrum. E, вече е ясно – в рамките на един спринт може да имаш различни Increment-и, които освен това може да доставиш по всяко време.

Най-накрая! Continous delivery-то е вече мисия възможна със Scrum! Ура! 🙂.

В предишната версия на Scrum Guide-a имаше отделни секции за това как следим прогреса при изпълнението на бизнес целите, както и при изпълнението на спринта. В основата стоеше актуализирането на оставащата работа (поне веднъж в спринта за бизнес целите, и поне веднъж дневно за работните задачи в спринта). Тези две секции вече изцяло липсват. Но пък се споменава batch size от ден или по-малко за задачите в спринта. Може би действително Scrum върви към лийн? 🙂

Безспорно ще ми липсват тези секции. Те ми даваха основание да изисквам от Scrum Team-ите да знаят във всеки момент каква е оставащата работа и ме улесняваше в това да „продам“ своевременното актуализиране на "remaining estimate"-ите. Сега ще трябва да проявявам допълнителна креативност, когато се аргументирам 🙂

Предишният Scrum Guide подчертаваше ясно, че отделните developer-и могат да работят по различни задачи, но няма индивидуален ownership, а всички отговарят за всичко в спринта. Тази част липсва в новия Scrum Guide.

Предполагам, че премахването на този текст се дължи на опростяване на Scrum Guide-a, а не защото правилото се е променило. Но времето ще покаже! 🙂

Новият Scrum Guide не поставя излишен акцент върху понятието "ready", когато става въпрос за това кога нещо е готово, за да влезе в спринта.

Силно приветствам тази промяната и се надявам с това да се прекрати погрешната практика от използването на Definition of Ready, която често срещам в практиката си.

Предишният Scrum Guide явно дефинираше, че Daily Scrum-овете са отговорност на Development Team-a. Сега липсва текст, който да подчертава това.

Може би отново става въпрос за опростяване на ръководството, колкото до промяна в правилото. В крайна сметка Daily Scrum-овете продължават да обслужват developer-ите и им дава формална възможност да инспектират прогреса в спринта и да се адаптират при девиации.