Share on Facebook Tweet it

Bloker na horyzoncie!

W dzisiejszym artykule chciałem przybliżyć tematykę blokerów. W procesie scrumowym, gdzie dążymy do maksymalnej transparentności, blokery mają nawet swoją własną kolumnę na dashboardzie.

Jaki jest cel takiego eksponowania blokerów? Sprawa wydaje się jasna. Chcemy pokazać wszystkim to co nas blokuje, tak aby problemy w projekcie widoczne były na pierwszy rzut oka.

Zastanówmy się nad tym kiedy blokery pojawiają się i czy można ich uniknąć.

Wydaje się, że blokery mogą pojawiać się na każdym etapie projektu i nie ma na to jakieś reguły. Mogą one być związane z:

  • niedostateczną znajomością technologii, którą zamierzamy zastosować
  • trudnościami w integracji systemów, które „teoretycznie” powinny  ze sobą współpracować wg zdefiniowanego interfejsu
  • niekompletną lub nieaktualną dokumentacją rozwijanego / integrowanego systemu
  • brakiem testów / niskim pokryciem testami „odziedziczonego” systemu
  • brakiem uprawnień do wykonania zadania
  • brakiem potrzebnej licencji
  • potrzebą refaktoryzacji komponentu / systemu
  • niską motywacją / znużeniem zespołu
  • itd.

Pojawianie się różnego typu brokerów jest rzeczą naturalną. Ich brak wskazywałby na jedną z dwóch sytuacji:

  1. Realizowany projekt nie sprawia zespołowi najmniejszych trudności. Jest realizowany w świetnym tempie, bezbłędnie i z wyprzedzeniem życzeń klienta. Można powiedzieć, że zespół marnuje się przy tym projekcie i mógłby się zająć czymś dużo bardziej ambitnym.
  2. Bardziej realistyczny scenariusz: nie potrafimy zidentyfikować problemów w projekcie. Nie dostrzegamy, bądź nie chcemy dostrzegać rzeczy, które w sposób tymczasowy bądź permanentny blokują lub opóźniają prace projektowe. Taka sytuacja może być wynikiem chowania głowy w piasek, kiedy user story czy zadania o wysokim ryzyku odkładane są na później. Innym przypadkiem jest brak aktywnego poszukiwania sposobów na podniesienie wydajności i zadowalanie się status quo.

W większości projektów zespół na bieżąco identyfikuje pojawiające się blokery. Rolą Scrum Mastera powinno być adresowanie tych problemów, a w razie ich braku podnoszenie rangi różnych niedogodności towarzyszących zespołowi w projekcie do miana blokerów.

Blokery powinny mieć swój priorytet. Zadaniem Scrum Mastera jest sprawienie, aby blokery o najwyższym priorytecie „znikały’’ z tablicy. Głównym zadaniem Scrum Mastera niewykonującego żadnych „prawdziwych zadań” powinno być to, aby blokery w projekcie były jak najmniejszego kalibru. Docelowo Scrum Master zajmując się blokerami o coraz niższym priorytecie staje się mniej widoczny. Zamiast „gasić pożary”, zajmuje się np.:

  • przygotowaniem warsztatów podnoszących kwalifikacje zespołu
  • rozwijaniem definition of done o dodatkowe punkty
  • testowaniem i wdrażaniem nowych narzędzi usprawniających pracę zespołu lub podnoszących jakość wytwarzanego systemu
  • dostrzeganiem ryzyk i zagrożeń ukrytych w user stories „na dnie” backlogu
  • podnoszeniem motywacji zespołu
  • itd.

W sytuacji, gdy dużą część dnia Scrum Mastera wypełniają ww. czynności, może zajść jedna z dwóch niekorzystnych zmian dla zespołu.

  1. W ramach oszczędności Scrum Master może zostać zwolniony, gdyż jawi się on jako osoba, która nie wykonuje „prawdziwych zadań”, a pełniona przez niego funkcja sprowadza się do rzeczy błahych i nieistotnych.
  2. Scrum Master przestaje pełnić swoja dotychczasową rolę i zostaje przemianowany na dewelopera.

W obydwu przypadkach odczuwalny jest brak osoby odpowiedzialnej za identyfikację i usuwanie coraz to nowych przeszkód napotykanych przez zespół. W obu przypadkach jakość pracy a w efekcie jakość tworzonego produktu ulegają degradacji.

 

Tags: , ,

Profile photo of liber

About liber

Jestem zdeklarowanym zwolennikiem zwinnych praktyk. Większość mojego doświadczenia z agile stanowi praca z zespołami scrumowymi zarówno jako Scrum Master jak i jako Scrum Coach. Nie stronie jednak od innych podejść. Ostatnio, na przykład, miałem przyjemność bycia członkiem zespołu kanbanowego. Po klikuletniej pracy w londyńskim City obecnie związany jestem z firmą Espeo Software.

Comments are closed.