Стани господар на Agile и Scrum! Запиши се за програмата за лична ефективност за Agile / Scrum екипи с начало 11.2021.
Scrum Guide 2020

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

Новият Scrum Guide е вече факт. В предишна статия разгледах 15 важни промени, за които трябва да знаеш. Е, има и още!

1. Scrum вече не е дефиниран като process framework

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

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

2. Complex adaptive problems е заменено от complex problems

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

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

3. Няма явно изискване Increment-ът да е potentially releasable

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

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

4. Вече целият Scrum Team дефинира Definition of Done

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

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

5. При Scaled Scrum всички Scrum Teams имат общ Definition of Done

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

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

6. Може да имаш multiple Increments в рамките на един спринт

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

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

7. Липсват указания за това как се следи прогреса

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

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

8. Collective ownership на задачите в спринта липсва

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

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

9. 'Ready' е просто ready

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

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

10. Отговорността за Daily Scrum-овете не е явно дефинирана

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

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

Пропуснал си предишната статия с още 15 промени в Scrum?

Не се притеснявай! Промените те чакат! :) Премини към 15 важни промени в Scrum Guide 2020.

Свържи се с мен

Хареса ти това, което прочете? Научи още повече с моите сертифициращи обучения по Scrum, моята програма за лична ефективност за Agile / Scrum екипи или просто ми пиши.