Tym artykułem chciałem rozpocząć serię wpisów dotyczącą książek, którymi według mnie może się zainteresować każdy związany z podejściem agile. Na pierwszy ogień trafiła jednak pozycja teoretycznie niezwiązana z tą tematyką. Factfulness jest jednak książką niezwykle wartościową, a zawarte w niej informacje przydadzą się praktycznie każdemu.
Z mojego punktu widzenia Retrospektywa Sprintu jest najważniejszym wydarzeniem w Scrumie. Daje ono zespołowi możliwość zatrzymania się na chwilę, przemyślenia ostatnich dokonań i wyciągnięcia wniosków na przyszłość. Domyka więc pętlę uczenia i umożliwia dostosowanie się do zmieniających warunków. Co jako prowadzący spotkanie możesz zrobić, aby retrospektywa była ciekawsza i bardziej owocna?
Przypomnij sobie, jakie spotkania czekają cię w nadchodzących dwóch tygodniach. Czy zastanawiasz się, dlaczego uczestniczysz w niektórych z nich? Bierzesz w nich czynny udział, czy tylko przysłuchujesz się dyskusjom mniej lub bardziej związanym z tematem? Jeśli pracujesz zdalnie, możesz przynajmniej w tym czasie odpisać na maile lub załatwić jakąś ważniejszą sprawę. Wystarczy jednak zastosować kilka prostych zasad, aby organizowane spotkania miały sens i korzyść dla ich uczestników.
Praca zdalna może być analizowana z różnych perspektyw. Niektórym firmom kojarzy się mocno z brakiem kontroli i świadomym obniżeniem wydajności przez pracowników. Z mojej perspektywy wygląda to inaczej. Częściej widzę przypadki osób, które pracując zdalnie, wciągają się w obowiązki zbyt intensywnie. Prowadzi to do poważnych konsekwencji, takich jak zmęczenie, spadek wydajności a nawet wypalenie zawodowe. Warto zwrócić na to uwagę i zmniejszyć ryzyko problemów.
Backlog produktu nie powinien być zbyt duży, aby można nim było wydajnie zarządzać. Nawet jeśli spełnia on ten wymóg, nie jest łatwo określić właściwe priorytety. Czy Product Owner powinien patrzeć na ważność, pilność, pracochłonność, czy po prostu preferencje klienta? Istnieje kilka różnych podejść, które warto znać i w razie potrzeby zastosować.
Ile razy w sytuacji kryzysowej mówiłeś lub słyszałeś „to na pewno ich wina”, “nic nie mogliśmy zrobić, to tak działa” lub “ale to zawaliliśmy”? Bardzo często, zanim zaczniemy szukać rozwiązania, wykazując odpowiedzialność, usprawiedliwiamy swoje działania, obwiniamy za porażkę innych, siebie lub system. Fazy te opisał Christopher Avery w Responsibility Process.
Zdarza się czasem, że Scrum Masterowi zarzuca się matkowanie zespołowi. Chodzi o zbyt częste pomaganie, przypominanie i prowadzenie za rękę. W pewnym momencie zespół powinien stać się bardziej niezależny, niczym wyprowadzające się z domu rodzinnego dzieci. Jak długo należy więc pozostać mamą lub tatą, a kiedy Scrum Master powinien przejąć rolę starszego brata lub dziadka?
“Zawsze się spóźniasz”, “Często wyglądasz na zdenerwowanego podczas spotkań” – czy kiedyś zdarzyło ci się otrzymać lub przekazać podobny feedback? Taki komunikat mógł się spotkać z niezrozumieniem lub ostrą reakcją jego odbiorcy. Jak w takim razie przekazać informację zwrotną, aby była wartościowa i mogła spowodować pożądany efekt?
Kryteria akceptacji (ang. acceptance criteria) to lista wymagań, które należy spełnić, aby historyjka użytkownika mogła zostać uznana za gotową z biznesowego punktu widzenia. Powinny zostać utworzone przez cały zespół scrumowy, na podstawie tego, czego oczekuje klient, najczęściej za pośrednictwem Product Ownera. Czy nie lepiej więc, jeśli zostaną przez niego zdefiniowane od razu szczegółowo i technicznie, aby zaoszczędzić czas?
Nawet jeśli nie jesteś managerem, zapewne zdarzyło ci się delegować zadania. Mogło to być polecenie służbowe, lub po prostu przekazanie swoich obowiązków, gdy musiałeś zająć się czymś innym lub szedłeś na urlop. Czy po wykonaniu zadania przez inną osobę, byłeś zadowolony z efektu? Czy przed przekazaniem zadbałeś o to, żeby zostało wykonane zgodnie z twoim oczekiwaniem?
