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

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

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

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

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

Може би най-съществената промяна е премахването на 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 екипите и ще помогне на всички да се фокусират върху важните неща, а имено тези, които спомагат за максимизиране на добавената стойност на клиента.

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

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

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

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

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

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

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

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

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

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

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

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

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

Чудесна промяна. За мен винаги е било изключително важно екипът да може да отговори на въпроса „Защо“. Е, вече няма как – това става задължително. Ура! 🙂.

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

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

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

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

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

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

Давам дефиницията такава, каквато е в 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.".

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

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

До сега официалните артефакти в 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 за Product Increment

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