Стани господар на Scrum. Запиши се за следващия ми сертифициращ курс по Scrum на 18-19.03.2021.
Scrum Guide 2020

15 важни промени в Scrum Guide 2020

Новият Scrum Guide е вече факт. За разлика от миналата актуализация (през далечната 2017 г.), тази включва съществени промени, с които е добре да се запознаеш.

1. Минимизиране на Scrum Guide-a и отпадане на някои правила

Scrum Guide-ът вече е 13 страници (което е с 6 по-малко от предишната версия). Това е повече от 30% съкращение. Освен опростяване на езика и още по-синтезирана информация, това се дължи и на премахването на някои правила в Scrum, за които ще пиша по-долу.

Аз съм голям привържаник на KISS принципа ("Keep It Simple, Stupid") и изключително много привествам "олекотяването" на Scrum рамката, особено по отношение на някои от правилата, които са премахнати. Това дава още по-голяма свобода на екипите да експериментират и да открият онези неща, които работят за тях.

2. Емпиризъм + Лийн мислене

Scrum Guide-ът вече споменава и принципите на лийн мисленето и ги посочва като теоретична основа на Scrum. Няма много конкретика, освен че и тук целта е да се намали т.нар. "waste" и да се постави фокус върху "важните" неща.

И това е чудесна новина. Моята практика показва, че прилагането на лийн принципите в Scrum води до съществени подобрения и увеличава значително добавената стойност за клиента. Това, че вече формално се споменава за тях в Scrum Guide-а, ще отвори широко вратите за тях и ще ускори тяхното приемане и имплементиране от Scrum екипите.

3. Няма Development Team

Може би най-съществената промяна е премахването на Development Team. Вече няма екип в екипа. Единственият екип е Scrum Team-а и в него има един Scrum Master, един Product Owner и Developers.

Причината за тази промяна е нещо, което често наблюдавам и аз в своята практика, а имено противопоставянето между Product Owner и Development Team и делението между "аз и те" и "тя/той и ние" (което се дължи на различните цели, които те преследват). Ето защо новата версия акцентира върху това, че те трябва да работят като един екип - Scrum Team и да преследват обща цел, а имено т.нар. Product Goal.

Следните характеристики, които бяха валидни за Development Team-а, са валидни и за Scrum Team-a:

  • Екипът е малък (но отпада задължението да е между 3 и 9 човека).
  • Липсват йерархични нива (т.е. налице е плоска властова структура).
  • Няма подекипи.
  • Екипът е cross-functional.
  • Екипът е self-managed (да, вече не е само self-organized).

Надявам се, че тази промяна ще подобри кохезията в Scrum екипите и ще помогне на всички да се фокусират върху важните неща, а имено тези, които спомагат за максимизиране на добавената стойност на клиента.

4. Целта на Scrum Team-а е Product Goal

В предишната версия на Scrum Guide-a се говори за бизнес цели и, че Product Owner-ът е този, който би следвало да се погрижи за тяхното постигане като определя приоритетите за Development Team-а. Е, това вече е малко по-различно.

Първо, вместо много и различни бизнес цели - говорим за една единствена (дългосрочна) цел, а имено Product Goal. Причината е постигането на по-добър фокус, което е и една от ценностите в Scrum.

Второ, вместо Product Owner-a да е отговорен за постигането на тази цел, отговорен е Scrum Team-а. Причината е насърчаване на отговорността за успеха на продукта в целия екип (т.е. не е достатъчно само да създадеш Increment, както ти е задал Product Owner-a - важното е той да постига поставената му цел), което също е една от ценностите в Scrum.

Въпреки че ограничението за една идинствена цел (вкл. при Scaled Scrum) ми се струва трудно постижимо в реалния живот, явното дефиниране и артикулиране на такава, както и споделената отговорност за нейното постигане, отново ще повишат кохезията в екипа и ще дадат възможност на всеки да се противопостави на решения и действия, които са в противоречие с тази цел (което често не се случва в практиката).

5. Ролите са заменени с отговорности

Вече няма явно дефинирани роли, а се говори за групи от отговорности, които попадат под шапката на: the Developers, the Product Owner и the Scrum Master.

Не открих съществени разлики в самите отговорности. Може би най-важните са:

  • Product Owner-ът дефинира и комуникира Product Goal-a.
  • Product Owner-ът може да делигира всичко, но отговорността винаги остава при него.
  • Scrum Master-ът явно отговаря за ефективността на Scrum Team-a.

Признавам си, че не разбирам съвсем причината за премахване на термина роля. Може би целта е да се "олекоти" рамката и да звучи по "не-нормативна". Или просто е направено с цел да се "опрости" самото ръководство, за което създадетелите на Scrum бяха критикувани през последните години. Времето ще покаже :)

6. Self-managing замества Self-orginizing

Self-organization беше характеристика на Development Team-а и включваше възможността на този екип сам да определя отговорите на въпросите "кой" и "как" по време на изпълнение на спринта. Сега тази характеристика е прехвърлена върху целия Scrum Team и вече включва и въпроса "какво", превръщайки екипа в self-managed.

Приветствам тази промяна, защото вярвам, че тя ще акцентира по-успешно овластеността на екипа пред всички заинтересовани страни.

7. Sprint-ът e формално дефиниран като event

В предишната версия на Scrum Guide-a се дефинираха 4 явни събития. Е, вече събитията официално са 5 и включват Sprint-a като събитие-контейнер.

Това по-скоро ще намали дебатите в общността за това дали Sprint-a е събитие или не, отколкото ще доведе до някаква съществена промяна в прилагането на Scrum. Разбира се, това е в кръга на шегата. Това е важно уточнение, защото то подчертава, че Spint-ът дава формална възможност за инспекция и адаптация на Scrum Team-а на Product Goal-a - нещо, което е изключително важно и не трябва да се пропуска.

8. Sprint Planning-ът включва нов етап - 'Защо?'

Вече не отговаряме само на въпроса "Какво" и "Как". Отговаряме и на най-важния въпрос, а имено "Защо".

Чудесна промяна. За мен винаги е било изключително важно екипът да може да отговори на въпроса "Защо". Е, вече няма как - това става задължително. Ура! :).

9. Няма предефиниран формат на Daily-то

Трите въпроса отпадат! Ура!

Промяната, която може би най-силно приветствам. Винаги съм смятал формата с трите въпроса за изключително неефективен и за мен е истинско щастие да видя, че вече не е официално част от Scrum!

10. Демонстрацията не е задължителна в Sprint Review-то

Да, вече не е задължително да правим "демо" по време на Sprint Review-то (въпреки че авторите казват "Scrum Team should avoid limiting it to a presentation"). Също така форматът е съществено олекотен, а фокусът е поставен върху Product Goal-а.

Аз лично много харесвах формата и структурата на Scrum Review-то по начина, по който беше описан в предишната версия на Scrum Guide-a. Вярвам, че промяната е направена, за да повиши приложимостта на Scrum в индустрии, извън софтуерната разработка, а не защото Scrum Review-то в този вид е било неефективно.

11. Отпада задължението за поне един 'process improvement' на спринт

Една от съществените промени на предишната версия беше задължението Development Team-а да реализира поне едно от подобренията в начина на работа, идентифицирани по време на последната ретроспектива. Е, в новата версия това задължение отпада.

Това е една от промените, които не ми допадат съвсем. Разбирам, че целта е да се олекоти рамката и да не е толкова нормативна, но преди години въведоха това правило, защото екипите влизат в конфортната си зона и не искат или просто не намират време за непрекъснато усъвършенстване и експериментиране. Сега, премахвайки това правило от Scrum Guide-a, се намалява натиска върху Scrum Team-a да имплементира подобрения в начина си на работа. Дано да греша! :)

12. Има явна дефиниция за това какво е продукт

Давам дефиницията такава, каквато е в Scrum Guide-a: "A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.".

13. Няма задължителни атрибути по отношение на Product Backlog Item-ите

До този момент всеки PBI трябваше да има поне 4 атрибута: description, order, value и estimate. Това вече не е задължително.

14. Отпада 10% ограничение за Product Backlog Refinement-a

В предишната версия на Scrum Guide-a имаше ограничение Product Backlog Refinement-a да не отнема повече от 10% от капацитета на Development Team-a. Вече няма такова ограничение.

15. Артефактите вече са официално 3

До сега официалните артефакти в Scrum бяха четири - Product Backlog, Sprint Backlog, Definition of Done и Product Increment. От тях отпада Definition of Done, който заедно с Product Goal и Sprint Goal се превръщат в т.нар. "commitments" за отделните артефакти, а имено:

  • Product Goal -> Product Backlog
  • Sprint Goal -> Sprint Backlog
  • Definition of Done -> Increment

Харесва ми тази промяна - особено частта с commitment-ите. Така е много по-подредено и разбираемо, и има яснота какъв е фокуса на всеки артефакт и в контекста на какво се инспектира и адаптира.

Има още!

Изненада! Промените не свършват до тук. Научете за още 10 важни промени в Scrum Guide 2020!

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

Хареса ти това, което прочете? Научи още повече с моите отворени обучения или просто ми пиши.