Wprowadzenie do pracy w metodologii scrum nie zajmuje wiele czasu. Zaczynamy od stworzenia zespołu specjalistów o różnych umiejętnościach, który liczy zwykle poniżej 10 osób. Eksperci dzielą całą pracę na mniejsze, łatwe do rozplanowania i wykonania części i realizują ją przyrostowo, w iteracjach zwanych sprintami. Po każdym sprincie zespół weryfikuje efekty pracy i dostosuje plan dalszych działań, aby dostarczyć jak najbardziej wartościowe treści.
Brzmi prosto, prawda? Dlatego wciąż, po 20 latach od opublikowania słynnego Manifestu Zwinnego Tworzenia Oprogramowania (Manifest Agile), metodologia scrum stanowi numer jeden dla zespołów programistycznych na całym świecie.
Jakkolwiek łatwo jest zacząć pracę w scrumie, efektowne wykorzystywanie tej metody pracy wymaga wprawy, doświadczenia i błędów, na których można się uczyć. Poniżej opisane zostały wybrane najczęstsze mity i błędne przekonania dotyczące scruma. Liczymy, że ich poznanie sprawi, że skutecznie ich unikniesz.
1. Agile i metodologia Scrum służą tylko do projektowania oprogramowania
To oczywiście nieprawda! Chociaż ruch Agile wywodzi się z prac nad oprogramowaniem, nic nie stoi na przeszkodzie, aby zaadaptować go na rzecz innych obszarów. Twórcy scruma wręcz zachęcają do stosowania go w innych sferach – wszędzie tam, gdzie trzeba wykonać skomplikowaną, wieloetapową pracę. Odnotowano udane wdrożenia pracy metodą Agile w takich dziedzinach jak sprzedaż, HR i marketing. Podejście to sprawdziło się nawet w branży samochodowej – Tesla uważa zwinny rozwój produktu za kluczowy czynnik swojego sukcesu rynkowego.
Co jest istotne przy adoptowaniu metodologii scrum poza branżą IT? Przede wszystkim wyjście poza techniczne środowisko i zrozumienie, jakie są 3 najważniejsze zalety scruma: przejrzystość procesów, możliwość ich weryfikacji i adaptacji. Mając to na uwadze, możemy spojrzeć na wiele złożonych procesów i zastanowić się, jak usprawnić je przy pomocy takiego typu pracy.
- Możemy zwiększyć przejrzystość procesów i dzięki temu podejmować bardziej świadome, zorientowane biznesowo decyzje, oparte na faktach, a nie na założeniach.
- Dzięki okresowej inspekcji, możemy się na bieżąco upewniać, że cele są nadal aktualne. Daje to również możliwość odkrycia problemów na wczesnym etapie, kiedy ich naprawa nie jest wymagająca
Te dwie rzeczy idą ze sobą w parze – jak mówi Scrum Guide: „Przejrzystość umożliwia inspekcję. Inspekcja bez przejrzystości jest myląca i nieekonomiczna”.
- I wreszcie, możemy dostosowywać plan pracy za każdym razem, gdy dowiadujemy się czegoś nowego, co ma wpływ na nasz cel.
Kluczowe wnioski:
- Scrum wywodzi się z branży programistycznej, ale jego zastosowanie do niej nie ogranicza
- Twórcy scruma aktywnie zachęcają do stosowania tej metodologii pracy w projektach i przy produktach nie związanych z oprogramowaniem
- Z roku na rok coraz więcej organizacji zaczyna stosować scrum – ten trend będzie się utrzymywał
- Obecnie liderzy patrzą na projekty przez pryzmat korzyści scruma i szukają możliwości, aby uczynić tradycyjnie zarządzane procesami bardziej efektywnymi
2. Daily Scrum czyli raportowanie statusu
Obecnie to dość powszechna część organizacji pracy. Zespół spotyka się w ustalonym miejscu i czasie, każdy dzieli się swoimi raportami o statusie pracy, którą wykonał poprzedniego dnia. To przestrzeń do komunikacji w stylu „Pracowałem nad tym nowym API do uwierzytelniania; prawdopodobnie będę to kontynuował dzisiaj”. Każdy członek zespołu dzieli się informacjami, a potem wszyscy wracają do swoich zajęć.
To rozwiązanie działa, ale jest dalekie od doskonałości. Co można poprawić, by uczynić daily scrum bardziej efektywnymi? Warto skupić się na celu sprintu i zintensyfikować działania, które pozwolą go osiągnąć. Nie bój się dyskutować, proś o wyjaśnienia, jeśli czegoś nie rozumiesz. Z obserwacji zespołów osiągających najlepsze efekty wynika, że ich Daily Scrum przebiega jak rozmowa pomiędzy sportowcami z tej samej drużyny. Skupiają się na ustaleniu zwycięskiej strategii (pozwalającej przybliżyć cel sprintu), a nie na mechanicznym odpowiadaniu na zadane pytania.
Inny punkt widzenia
Jest jeszcze inny punkt widzenia na tę kwestię – jest on bardziej skoncentrowany na dynamice relacji w miejscu pracy. W metodologię scrum wpisujemy codzienne spotkania, wydarzenia dla deweloperów z zespołu. W praktyce w spotkaniach tych uczestniczą również inni pracownicy, często jako słuchacze lub aktywni uczestnicy. Może to przynieść korzyści, ale może też sparaliżować pracę zespołu.
Obecność product ownerów, scrum masterów czy managerów może onieśmielać członków zespołu i powodować, że będą mieć opory przed mówieniem o problemach, których doświadczają. Strach przed oceną i wizerunkiem osoby niekompetentnej jest realny i bardziej powszechny niż nam się wydaje. Dlatego należy dołożyć wszelkich starań, aby daily scrum był bezpieczną przestrzenią do dyskusji. Scrum Masterzy, obserwujcie relacje w zespole i dostrzegajcie takie kwestie.
Z drugiej strony, Product Owner i interesariusze mogą obawiać się utraty kontroli nad projektem. Czują, że MUSZĄ być na każdym spotkaniu, aby upewnić się, że wszystko idzie zgodnie z planem. W takim przypadku deweloperzy powinni skupić się na budowaniu zaufania. Istotne jest pokazanie, że rozumieją kontekst biznesowy projektu i można na nich polegać.
Kluczowe wnioski:
- Zespół powinien współpracować podczas daily scrum – dyskusje są mile widziane
- Daily Scrum nie powinien polegać jedynie na raportowaniu statusu do menedżerów
- Scrum Master i Product Master nie są nawet zobowiązani do uczestnictwa w spotkaniach
- Scrum Masterzy: starajcie się stworzyć bezpieczne, przyjazne środowisko.
- Narzędzie do zarządzania projektami powinniśmy codziennie aktualizować, tak aby kierownicy i interesariusze znali aktualny status pracy
3. Zespół musi wywiązać się ze wszystkich zobowiązań przypisanych do danego sprintu
Planujemy ukończyć 7 historyjek użytkownika (user stories) w tym sprincie, więc dostarczenie czegokolwiek mniej jest porażką, przecież tylko całkowite wykonanie planu jest naszym celem, prawda? Otóż nie.
Dążymy do osiągnięcia celu sprintu, a nie tylko ukończenia wszystkich pozycji w backlogu. Zakres sprintu może ulec zmianie, w momencie gdy pojawiają się nowe informacje na temat zagadnienia, nad którym pracujemy. Często na początku prac nie sposób przewidzieć złożoności danego zadania.
Ponieważ scrum promuje ideę samoorganizacji, deweloperzy powinni mieć autonomię, aby wybrać najlepszy sposób na osiągnięcie celu produktowego. Jeśli po rozmowie z użytkownikami końcowymi dowiadujemy się, że obecne plany nie mają sensu z biznesowego punktu widzenia, zakres sprintu może i powinien zostać zmodyfikowany. Należy pamiętać, aby być transparentnym w tej kwestii i umieć uargumentować swoje decyzje na wypadek konfrontacji z interesariuszami.
Koncentracja na celu sprintu oznacza również, że niektóre pozycje o niższym priorytecie, znajdujące się w backlogu sprintu, mogą nie zostać ukończone – jest to jak najbardziej w porządku, jeśli nie mają wpływu na cel. Scrum polega na dostarczaniu wartościowych treści, a nie na mechanicznej realizacji kolejnych pozycji z listy rzeczy do zrobienia.
Kluczowe wnioski:
- Cel sprintu jest najważniejszy
- Zakres sprintu stanowi bardziej prognozę niż nieprzekraczalne zobowiązanie
- Zakres sprintu może ulec zmianie i to jest w porządku, jeśli cel sprintu zostanie osiągnięty
- Deweloperzy powinni mieć autonomię w pracy, aby wybrać najlepszy sposób na osiągnięcie celu sprintu
4. Na backlog produktu składają się user stories
Na pewno user stories stały się popularne w zespołach agile. Ukazują one realny scenariusz z perspektywy użytkownika i zachęcają do dyskusji, aby wypracować najlepszy sposób na osiągnięcie zaplanowanego celu. Niektóre zespoły mogą jednak uważać, że wszystko, co znajduje się w backlogu produktu musi być opisane w ten sposób. Przyjrzyjmy się tej kwestii.
Po pierwsze, user stories nie są częścią metodologii scrum, a jedynie kolejnym narzędziem do pracy. Poza oczywistymi typami pozycji w backlogu, takimi jak błędy, należeć do nich mogą też te czysto techniczne zagadnienia – czasami pewien moduł wymaga po prostu refaktoryzacji. Innym przykładem jest implementacja dostosowana do nowych wymagań prawnych produktu. W takich przypadkach nie ma sensu męczyć się i wymyślać user story – wystarczy dobrze opisany zestaw oczekiwań. Warto poświęcić chwile i tworzyć możliwe do oszacowania pozycje backlogu, którymi można zarządzać.
Pamiętaj, że backlog produktu jest wciąż modyfikowanym tworem, nie dokumentem typu „one-and-done”. Dobrze jeśli najważniejsze pozycje będą wyróżnione i szczegółowo opisane, a pozycje o niższym priorytecie będą mniej dokładne. W miarę postępów zespołu i poznawania kontekstu biznesowego, pozycje z backlogu produktowego zmieniają się w konkretne user stories i zadania.
Kluczowe wnioski:
- User stories nie stanowią wymogu metodologii scrum
- Tworząc pozycje backlogu, należy zastanowić się nad najbardziej efektywnym sposobem przedstawienia wymagań
- Pozycje backlogu nie powinny być zbyt rozbudowane
- Backlog produktu jest ciągle ewoluującym dokumentem, zmieniającym się przez cały cykl życia produktu
5. Scrum sprawdza się jedynie w fazie wdrożenia
W niektórych organizacjach istnieje schemat dopasowania scruma do istniejącego procesu predykcyjnego. Zazwyczaj pracę poprzedza faza planowania i analizy. Wtedy doprecyzowujemy szczegóły projektów, a także powstają dokumenty zawierające spisy wymagań. W tym samym czasie interesariusze i zespołu mogą spędzać tygodnie lub miesiące na długich rozmowach mailowych. Kiedy uzgodnimy pewne rzeczy, menedżer lub dyrektor tworzy zespół scrum, a deweloperzy otrzymują przytłaczającą liczbę dokumentów projektowych.
Wydaje się, że zespół jest na dobrej drodze do sukcesu. Faza analizy i projektowania została przeprowadzona w oparciu o każdą ewentualność, dzięki czemu wyszczególniono specyfikacje techniczne. W rzeczywistości jednak, po kilku sprintach projektu często okazuje się, że 50-70% tych szczegółowych wytycznych nie ma już znaczenia.
Zjawisko to nazywane jest czasem Water-Scrum-Fall i stanowi częściowe wdrożenie scruma. W optymistycznym scenariuszu, organizacja może wykorzystać nową wiedzę od zespołu scrumowego do dostosowania produktu, choć czasami oznacza to całkowitą zmianę kierunku. Bardziej pesymistyczny zaś scenariusz mówi, że firma pozostaje przy początkowych założeniach i marnuje fundusze na tworzenie niepotrzebnych rozwiązań.
W firmie, która używa metody Water-Scrum-Fall, musimy zastosować zmiany nie tylko na poziomie zespołu, ale i organizacji. Dlatego ważne jest, aby scrum masterzy nie skupiali się jedynie na wykonaniu zadań związanych z projektem, ale spojrzeli ze swojej perspektywy na organizację pracy całej firmy i starali się znaleźć sposób na uczynienie jej bardziej zwinną.
„Nie pozwól, aby oprogramowanie było jedynie produktem ubocznym specyfikacji technicznych. Wykorzystaj adaptacyjną naturę scruma i wykorzystaj sposoby tworzenia wymagań produktowych, takie jak Product Discovery czy Design Sprint.”
Kluczowe wnioski:
- Nie używaj scruma jako modnego elementu pomiędzy fazą projektowania a fazą wdrażania
- Dowiedz się więcej o problemie podczas pracy nad nim
- Zadaj sobie pytanie: jaki jest minimalny zestaw wymagań, aby rozpocząć pracę?
- W analizie skup się na celach i potrzebach użytkownika, a nie na szczegółowym planie wykonania
- Bądź gotowy na zmianę początkowych założeń
6. Scrum Master nie odgrywa istotnej roli
Obowiązki scrum mastera nie są tak oczywiste, gdy zaczynasz używać tej metodologii pracy, lub gdy tworzysz nowy zespół. Niektórzy uważają, że ta osoba tylko moderuje spotkania i zadaje pytania typu „co poszło dobrze w tym sprincie?”, podczas gdy inni zajmują się „prawdziwą pracą”.
Te wątpliwości są czasem uzasadnione. Niektórzy z nas mieli po prostu złe doświadczenia z scrum masterami. Może scrum master, z którym pracowaliśmy, nie nadawał się do tej roli, lub był to po prostu przemianowany team manager z kontrolującym nastawieniem? Przykładów anty-wzorców może być wiele, nie pozwól jednak, aby kształtowały opinię końcową o roli tej osoby.
Jest jedna wspólna rzecz, którą możesz zauważyć podczas pracy z dobrymi Scrum Masterami– dążą oni do stworzenia środowiska, w którym członkowie zespołu mogą osiągać najlepsze wyniki. To może oznaczać wiele rzeczy: identyfikowanie i usuwanie przeszkód, które ograniczają tempo pracy zespołu, praca z interesariuszami w celu budowania zaufania i zrozumienia procesu, czasami nawet coaching poszczególnych członków zespołu lub pełnienie roli mediatora, gdy pojawia się konflikt. Zdolny scrum master wie, jak dostrzec potencjalne problemy i działa proaktywnie!
Kluczowe wnioski:
- Scrum Master jest prawdziwym liderem odpowiedzialnym za efektywność zespołu
- Dobry scrum master może podnieść produktywność zespołu poprzez optymalizację procesów i stworzenie sprzyjającego środowiska pracy
- Mądre organizacje wykorzystują scrum masterów do usprawniania działań na poziomie całej firmy
Kilka słów na koniec
To tylko kilka przykładów na to, jak zagadnienia z zakresu agile i scrum mogą być źle rozumiane. Jeśli zauważyłeś, że niektóre z tych przypadków pasują do obrazu Twojego zespołu lub organizacji, nie wpadaj w panikę! Pierwszym krokiem do rozwiązania każdego problemu jest świadomość i zauważanie problemu. Postaraj się edukować, dzielić wiedzą i dobrymi praktykami z innymi. Podjęcie wyzwania, aby zmienić coś na lepsze, może być niesamowitą szansą na rozwój kariery.
Jeśli chcesz kierować swoją organizacją z wykorzystaniem podejścia agile, rozważ nasze usługi, aby zatrudnić wykwalifikowanych specjalistów agile jako konsultantów do swojego kolejnego przedsięwzięcia. Jesteśmy dumni, że możemy współpracować z liderami branży, takimi jak OneSpan, Gentherm, Capula, pomagając im prowadzić wielomilionowe projekty.
Skontaktuj się z nami, aby dowiedzieć się, jak możesz skorzystać na współpracy. Chętnie podzielimy się z Tobą historiami naszych sukcesów.
Przeczytaj więcej na temat Scrum Guide i aktualizacji z 2020 roku, oraz 5 najważniejszych zmianach związanych z tą aktualizacją tutaj.