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