SKUPIENIE W SCRUMIE

W wymarzonym świecie na wykonanie wszystkich postawionych przed nimi zadań Zespoły dostają nieograniczony czas. Doba rozciąga się niczym z gumy, środowiska działają w pełni przewidywalnie, wymagania płyną stabilnym strumieniem. Wszyscy jednak wiemy, że w codzienności projektowej presja czasu i piętrzących się zadań jest ogromna.  Z tego względu prawdziwą sztuką jest umiejętność wybrania, które zadania trzeba wykonać pilnie. Które odłożyć w czasie. A których… w ogóle nie wykonywać. Dodatkowo, zawsze warto ocenić, które czynności można wykonywać równolegle, a które muszą być wykonywane sekwencyjnie.

Realizacja takiego podejścia wymaga zrozumienia i skupienia od wszystkich członków Zespołu. Szybka analiza sytuacji, nadanie zadaniom odpowiednich priorytetów a następnie pełne skupienie na ich realizacji. Brzmi banalnie… w praktyce jednak rzadko udaje się to tak bezboleśnie.

Wynika to z kilku przyczyn. Każdy z nas ma inny poziom szczegółowości analizy, przy którym czuje się komfortowo z podjęciem decyzji. Często też mamy sprzeczne cele i stąd problem z definiowaniem priorytetów.

W zespole scrumowym nad priorytetami w Backlogu Produktu czuwa Product Owner. To na jego barkach spoczywa odpowiedzialność za to, które wymagania uzna za ważniejsze i pilniejsze do zrealizowania.  Nie jest w tym oczywiście odosobniony. Ma za sobą wsparcie Zespołu, który zawsze służy radą. Nie mniej, to od jego decyzji zależą priorytety Produktu.

Kto w takim razie decyduje o realizacji zadań w czasie Sprintu? Backlog sprintu jest już własnością członków Zespołu, i to od ich decyzji zależy jak backlog sprintu przekują na przyrost. I aby mieć szansę osiągnąć sukces musi być w pełni skupiony na celu. Służą temu takie ceremonie jak Planowanie, na którym cel jest definiowany, a następnie codzienne ‚standupy’, na których Zespół podsumowuje swoje dążenia do jego osiągnięcia, oraz typuje ewentualne przeszkody.

I tu pojawia się niezwykła wręcz misja dla Scrum Mastera. To Scrum Master stoi na straży skupienia Zespołu. Jego rolą jest tutaj dbanie o to, by wszyscy członkowie rozumieli co i kiedy należy zrobić. Ponadto strzeże Zespół przed ‚atrakcjami’ z zewnątrz, które mogą odbić się na ich pracy.

Nie dopuszcza do mnożenia zbędnych spotkań, odcina zadania nie będące scopem sprintu. Usuwa z ich drogi przeszkody tak, aby mogli pozostać maksymalnie skupieni na swoich zadaniach. Tłumaczy, na wszystkich stopniach organizacji, jak istotne jest to dla uzyskania dobrych efektów ich pracy.

Ostatnio natrafiłam na ciekawe stwierdzenie: „Jeśli masz do zrobienia 100 rzeczy i bardzo ograniczony czas, lepiej skupić się na 10 najważniejszych z nich, i zrobić je dobrze, niż próbować zrobić je wszystkie byle jak. „

Dlaczego tak?

Po pierwsze daje nam to większą szansę na ukończenie krytycznych zadań.

Po drugie, ogranicza konieczność, a co za tym idzie, koszt związany z ‚przełączaniem kontekstu’ (ang.: context switching). Cóż to takiego?

Termin ma swoje źródło nie gdzie indziej jak w ‚computer science’ i jest to proces zachowywania i odtwarzania stanu procesora tak, by wiele procesów mogło dzielić zasoby pojedynczego procesora.

W przypadku ludzi ma zastosowanie do określenia wysiłku jaki potrzebuje ludzki umysł, aby z wykonywania jednej czynności przestawić się na wykonywanie innej. Może się wydawać, że krótka przerwa w kodowaniu, żeby odpisać na maila, czy też rozmowa na czacie w czasie testowania to nic takiego. Nic bardziej mylnego! Szacuje się, że przy zaangażowaniu w dwie czynności jednocześnie do 20% czasu zabiera zmiana kontekstu.

Zabierając się do pisania tego tekstu postanowiłam przeprowadzić taki eksperyment na sobie. Zmierzyć czas w jakim ten tekst powstanie i porównać go z czasem, jaki zajęło mi napisanie poprzedniego. Na co dzień, jak wielu z Was, robię wiele rzeczy jednocześnie. Rozmawiam, siedzę na spotkaniach, piszę i czytam maile, uzupełniam backlog. Można tu wstawić też: piszę kod, kompiluję, testuję.

W trakcie pisania tego tekstu, czuję boleśnie na własnej skórze koszt robienia rzeczy w tak zwanym ‚międzyczasie’. I czytając za każdym razem od nowa napisany akapit, po to by dopisać jedno zdanie przed kolejnym spotkaniem zastanawiam się dokąd to zaprowadzi 😉

Jest to cenna lekcja i myślę, że następnym razem dwa razy się zastanowię widząc kolegę w ‚ciągu programowania’, w słuchawkach na uszach, odciętego od świata, czy moje pytanie na pewno nie może poczekać.

Spróbujmy więc rozejrzeć się i dostrzec skupienie innych, uszanować je i docenić. Sami spróbujmy ograniczyć ilość czynności, które wykonujemy jednocześnie. Sama jeszcze nie wiem jak to zrobić, ale na pewno spróbuję. Nauczmy się też robić rzeczy ważne przed tymi, które mogą poczekać. Niech ocena priorytetów wejdzie nam w krew, stanie się nieodłącznym elementem poprzedzającym działanie.

CYKL: WARTOŚCI W SCRUMIE

Michalina Smolarkiewicz