Модели за отстраняване на пречки за Scrum екипи
Научете практични модели за идентифициране и премахване на пречки в Scrum. Разберете как да овластите самоуправляващите се екипи и да отстраните първопричините в цялата организация.
Повечето инженерни екипи търпят триене, което всъщност трябва да елиминират. В Scrum пречка е всяко нещо, което забавя или спира напредъка на Scrum Team към постигането на Sprint Goal. Това не е просто инцидент със срив на системата или болен разработчик. Пречка е всяко организационно триене, технически дълг или процедурна бариера, която ограничава доставката. Начинът, по който даден екип се справя с тези препятствия, показва дали той наистина е самоуправляващ се, или просто чака някой друг да дойде и да го спаси.
Иницииране на отстраняването вместо тичане по задачи
Scrum Guide от 2020 г. ясно посочва, че Scrum Master служи на екипа, като осигурява отстраняването на пречките. Там никъде не се казва, че Scrum Master трябва лично да решава всеки възникнал въпрос. Когато на някой разработчик му трябват права за достъп до тестови сървър, неефективният Scrum Master подава заявка вместо него. Добрият Scrum Master пита защо изобщо достъпът изисква административна заявка или напътства разработчика как да поиска достъп директно.
Превръщането на Scrum Master в административен куриер отнема силата и отговорността на Developers. Ако препятствието се намира във вътрешните граници на екипа, самите Developers следва да го решат. Scrum Master се намесва тогава, когато проблемът идва от по-широката организация, където екипът няма правомощия да прави структурни промени.
Класифициране на препятствията според контрола и влиянието
За да отстранявате пречките системно, трябва да идентифицирате къде точно се корени проблемът. Всеки блокиращ фактор попада в една от три отделни зони:
- Пряк контрол: Проблеми вътре в Scrum Team, като забавяния при прегледа на код или слаби критерии за приемане, които екипът може да разреши веднага.
- Пряко влияние: Триене с директни партньори, като споделени тестови среди, управлявани от друга група, което изисква сътрудничество и преговори.
- Организационна архитектура: Фирмени политики, правила за покупки или изолирани звена в компанията, които изискват намеса на ръководството за промяна.
Когато се появи пречка, класифицирайте я, преди да предприемете действия. Ако третирате организационно ограничение като вътрешна задача на екипа, губите време. Ако ескалирате вътрешен комуникационен проблем към висшето ръководство, вредите на автономията на екипа.
Направете цената на забавянето видима
Организациите често игнорират проблемите, докато те не придобият ясна финансова стойност. Ако екипът ви прекарва по три дни в чакане на одобрение за сигурност по време на всеки Sprint, споделянето на недоволство по време на Retrospective рядко променя отношението на мениджмънта. Ръководителите често възприемат оплакванията като обикновено инженерно мърморене.
За да прекъснете този модел, измерете количествено въздействието. Проследявайте загубените часове, пропуснатите Sprint Goals и разходите за заплати за времето на престой. Поставете тези данни на табло с пречки на споделено място. Когато заинтересованите страни видят, че бавните проверки за сигурност струват петдесет хиляди долара на всяко тримесечие поради забавена доставка, лидерите по сигурността ще намерят начин да автоматизират списъка си с изисквания.
Атакувайте системата, а не конкретния тикет
Често срещан модел на провал е третирането на повтарящите се пречки като изолирани събития. Да приемем, че на вашия администратор на бази данни са му нужни четири дни, за да изпълни скриптове за миграция. Един добронамерен Scrum Master може да изгради лични отношения с администратора, за да избутва заявките на своя екип напред в опашката.
Това е пререждане на опашката, а не премахване на пречка. То оставя първопричината за проблема непокътната. Ефективното отстраняване означава да попитате защо изобщо съществува ръчен преглед на миграциите. Работете с администратора за въвеждане на автоматизирани проверки за сигурност, включване на тестовете за миграция в процеса на изграждане на софтуера и елиминиране на опашката. Премахването на пречка означава да гарантирате, че тя няма да се повтори никога повече.
Ранно улавяне на препятствията по време на Daily Scrum
Daily Scrum не е среща за отчет на статуса. Това е работна сесия за инспекция на напредъка към Sprint Goal и адаптиране на плана за деня. Когато Developers се събират за петнадесет минути, те трябва да извеждат на преден план зараждащите се пречки, преди тези въпроси да са се превърнали в пълни блокери.
Дисциплинираният екип не чака работата да спре напълно, преди да сигнализира за проблем. Ако разработчик забележи, че времето за отговор на дадено API се влошава или че външен екип не отговаря, той го споделя веднага. Екипът коригира дневния си план, за да заобиколи препятствието, докато Scrum Master работи за трайното разчистване на пътя.