Sprint Retrospective събития, които наистина променят поведението
Научете как да провеждате Sprint Retrospective събития, които водят до реална промяна в поведението. Открийте конкретни начини за подбор на приложими подобрения, които се утвърждават трайно във вашия екип.
Повечето Sprint Retrospective събития пораждат оплаквания вместо реални промени. Екипите се събират, пишат бележки за тромави прегледи на код или шумни срещи, гласуват за тях и обещават да се справят по-добре. Две седмици по-късно абсолютно същите проблеми се повтарят. Ако дадена Retrospective не промени начина, по който разработчиците работят в понеделник сутрин, тя е просто скъп театър. В Scrum Guide от 2020 г. ясно се посочва, че целта на Sprint Retrospective е да се планират начини за повишаване на качеството и ефективността. Когато се съсредоточите върху конкретно поведение, а не върху общи настроения, ретроспективите се превръщат в най-полезния и възвръщаем час от вашия Sprint.
Капанът на неясните намерения
Екипите често бъркат разпалената дискусия с реално взето решение. Чуват се заключения като „трябва да комуникираме по-рано“ или „трябва да пишем по-добри тестове“. Това са просто пожелания, а не промени в поведението. Пожеланието носи на всички краткотрайно удовлетворение, без да изисква никаква дисциплина. В понеделник разработчиците се връщат към старите си навици, тъй като не е било дефинирано нито едно конкретно действие.
Истинската промяна изисква ясно наблюдаеми рамки. Вместо да се съгласявате да „комуникирате по-рано“, решете, че всеки pull request, останал отворен повече от четири часа, задължително се споменава на сутрешния Daily Scrum. Това е видим спусък и недвусмислено действие. Всеки в Scrum Team може веднага да установи дали то се е случило, или не.
Ограничете обхвата до един експеримент
Прекалената амбиция убива напредъка. Когато екипът изведе осем задачи за действие от една-единствена Retrospective, най-вероятно няма да завърши нито една. Всеки нов навик изисква когнитивно усилие. Инженерите и без това изразходват мисловна енергия за доставяне на стойностни Increment единици, справяне с техническия дълг и решаване на бизнес казуси.
Възприемайте резултатите от своята Retrospective като малки, контролирани експерименти. Изберете проблема с най-силно въздействие, разработете една-единствена намеса и я изпробвайте в рамките на един Sprint. В Scrum Guide се отбелязва, че най-съществените подобрения могат дори да бъдат добавени в Sprint Backlog за следващия Sprint. Поставянето на такова подобрение директно в Sprint Backlog му осигурява същата видимост и уважение, каквито имат функционалностите на продукта.
Създаване на проверими експерименти
Всяко приложимо подобрение трябва ясно да посочва спусъка, конкретното действие и начина за проверка. Ако не можете да наблюдавате резултата до края на текущия Sprint, експериментът е твърде абстрактен.
- Определете спусъка: Дефинирайте точното условие, което задейства действието, например когато дадена история влезе в етап на преглед на кода.
- Посочете ясното поведение: Опишете кой точно какво ще направи, без да разчитате на неясни прилагателни.
- Задайте правило за проверка: Определете как екипът ще инспектира резултата по време на следващата Sprint Retrospective.
Например екип, който се сблъсква с бавни прегледи на кода, може да приеме следното правило: когато се подаде pull request, проверяващите го инспектират до два часа или веднага работят по двойки. На следващата Retrospective екипът проверява времето за обработка на pull request заявките, за да види дали практиката е помогнала. Така абстрактното желание се превръща в конкретен протокол.
Затваряне на цикъла по време на следващата Retrospective
Една Retrospective никога не бива да започва на празна дъска. Тя трябва да стартира с експеримента, избран по време на предходния Sprint. Преди някой да заговори за нови проблеми, Scrum Master или разработчиците трябва да зададат един прост въпрос: Изпълнихме ли нашия ангажимент и подобри ли той ефективността ни?
Ако екипът е изоставил експеримента, инспектирайте причините. Твърде труден ли беше, беше ли забравен или проблемът всъщност не се оказа толкова важен? Ако екипът е изпълнил действието и качеството се е повишило, утвърдете това поведение във вашите работни споразумения или в Definition of Done. Ако не е помогнало, го отхвърлете без угризения. Непрекъснатото усъвършенстване не означава незабавно намиране на идеалното решение. То се състои в поддържането на дисциплиниран цикъл за обратна връзка, който систематично премахва неефективните навици.