Scrum to coś więcej niż tylko spotkania w twoim kalendarzu. Jak go wdrożyć i zrobić to dobrze?

Pracując w środowiskach IT i rozwijając produkty klientów, pomagamy zaspokajać ich dynamicznie zmieniające się potrzeby biznesowe. Wszystkim zależy na tym, aby produkt był szyty na miarę, a praca przynosiła jak najwięcej korzyści zarówno klientom, jak i zespołom realizującym dany projekt. Jakie możliwości mają firmy w dzisiejszych czasach, aby zwinnie zarządzać projektem i dostosować się do zmieniających się wymagań? Czy wdrażanie konkretnej metodologii albo ram postępowania jest rzeczywiście konieczne? Jakie opcje mogą wybrać firmy, aby zapewnić zadowolenie zarówno pracowników, jak i klientów?

Warto zacząć od zrozumienia, czym tak właściwie są potrzeby biznesowe. Najprościej rzecz ujmując, potrzeby biznesowe odnoszą się do wymagań lub celów, które firma lub organizacja musi spełnić, aby osiągnąć sukces. Te potrzeby mogą obejmować stabilność finansową, wzrost i ekspansję, spełnianie wymagań klientów i konkurencyjność na rynku.

Aby sprostać tym potrzebom, coraz więcej firm wdraża zwinne zarządzanie, decydując się m.in. na Scrum. Podejście agile pozwala na elastyczne reagowanie na zmieniające się potrzeby biznesowe klientów. Jednakże, nasuwa się pytanie: czy aby na pewno jesteśmy w stanie odgadnąć potrzeby klientów i czy klienci są świadomi, czego potrzebują? Zbierając wymagania przed rozpoczęciem projektu, często okazuje się, że klienci nie wiedzą jeszcze, jak powinien wyglądać finalny produkt. Zdarza się, że ich wymagania zmieniają się w trakcie trwania projektu. W takich sytuacjach z pomocą przychodzi Scrum.

Czym jest Scrum?

Ale czym właściwie jest Scrum? Definicja w Scrum Guide wskazuje, że „Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów„.

Scrum opiera się na trzech filarach empiryzmu: transparencji, inspekcji i adaptacji. 

Definiuje również pięć kluczowych wartości, jakimi są:

• zaangażowanie, 
• otwartość, 
• skupienie, 
• odwaga,
• szacunek. 

To dzięki nim, opisane poniżej składowe przynoszą pożądane efekty i pozwalają mówić o zwinnie zarządzanym zespole.

Scrum – zespół i ramy postępowania

Biorąc pod uwagę filary i wartości Scruma, warto zadać sobie pytanie, kto tak właściwie tworzy zespół scrumowy i kto ma się stosować do jego zasad. W zespole scrumowym wyróżniamy Product Ownera (reprezentanta biznesu), Scrum Mastera (odpowiedzialnego za wdrożenie Scruma oraz idącą za tym efektywność zespołu) oraz zespół developerski (obejmujący programistów, testerów i designerów). 

Scrum to ramy postępowania, a więc niezbędne są określone elementy, bez których nie możemy mówić o zwinnych zespołach. Nie bez powodu mówi się, że rutyna daje poczucie stabilizacji. Ważnym elementem są ceremonie scrumowe, czyli cykliczne spotkania, które wspierają zwinne zarządzanie zespołem.

Nim jednak napiszę o ceremoniach, chciałabym wprowadzić was do świata Scruma i opisać ważne składowe tych ram postępowania. 

Czym są sprinty?

Zacznijmy od sprintu, czyli inaczej iteracji. To nic innego jak krótki, ograniczony czasowo okres, w trakcie którego zespół scrumowy pracuje nad ukończeniem konkretnych zadań. Sprinty trwają maksymalnie miesiąc, ale często zdarza się, że ich okres wynosi 2 tygodnie. 

Dlaczego sprint trwa tak krótko i co to daje klientowi? Po krótkiej iteracji powinniśmy dostarczyć increment. To kolejna działająca wersja produktu, która pozwoli na zobrazowanie i zweryfikowanie, czy zespół buduje to, co trzeba, czyli to, co zaspokaja potrzeby biznesowe naszego klienta. W takim czasie zespół może wytworzyć tylko konkretną część danego produktu, kawałek po kawałku i jednocześnie otrzymywać informację zwrotną, jak reaguje na te zmiany klient. Mając na uwadze np. roczny projekt, łatwiej jest zmienić wymagania po jednym sprincie niż po roku, kiedy włożono już znaczną ilość czasu i wysiłku. Takie elastyczne podejście przynosi korzyści obu stronom. Klienci mogą dostosować swoje wymagania, a developerom łatwiej jest zarządzać zadaniami i zmieniać poszczególne elementy, kiedy praca podzielona jest na części.

Czym są user stories?

Potrzeby biznesowe powinny zostać spisane jako user stories. Najprościej ujmując, user stories to wymagania biznesowe spisane w historie, dzięki którym zespół będzie wiedział, kto jest odbiorcą zmiany, jakie są oczekiwania klienta, i jaką wartość dodaną dana zmiana ze sobą niesie. To pozwala zespołowi zrozumieć, jak tę zmianę wdrożyć.

Istotnym wydarzeniem scrumowym jest refinement, czyli przygotowanie backlogu do planowania kolejnego sprintu. To na tym spotkaniu developerzy mogą dopytać o szczegóły, jakimi muszą się zająć, poznać konkretny cel nadchodzącego sprintu, omówić wszelkie niejasności, zarówno biznesowe jak i techniczne oraz uzupełnić brakującą wiedzę. To moment, w którym zespół może zrozumieć cel sprintu i jego wartość. Jest to też okazja do zgłaszania wątpliwości i konsultacji z innymi członkami zespołu, jak powinny wyglądać zadania, które będą szczegółowo zaplanowane.

Scrum – ceremonie

Scrum opisuje konkretne ceremonie, w jakich uczestniczy zespół. Po pierwsze, sprint planning, czyli planowanie konkretnych zadań na nadchodzący sprint. Podczas tej ceremonii Product Owner potwierdza, jaki jest cel – może być taki sam, jaki był przedstawiony na refinemencie, ale może się zmienić ze względu na zmianę potrzeb biznesowych. Podczas planowania sprintu zadania są ustalane i priorytetyzowane a zespół ocenia realność wykonania celu, biorąc pod uwagę kompleksowość zadań oraz dostępność członków zespołu.

Po drugie, daily Scrum, czyli 15-minutowe codzienne spotkanie, które ma na celu omówienie planu działania na najbliższe 24 godziny, a także inspekcję wykonania celów sprintu. Warto dodać, że daily Scrum to spotkanie przeznaczone głównie dla developerów. Oczywiście, zarówno Product Owner jak i Scrum Master mogą być obecni podczas tego spotkania, niemniej to developerzy powinni je prowadzić. Jest to czas, kiedy developerzy mogą zasygnalizować ewentualne problemy, z jakimi borykają się podczas wykonywania zadań. Spotkanie to daje transparentność całemu zespołowi.

Po trzecie, sprint review. Ta ceremonia ma na celu podsumowanie i demonstrację rezultatów ubiegłego sprintu, innymi słowy jest to inspekcja incrementu. 

Po czwarte, sprint retrospective, potocznie nazywane retro. Ta ceremonia zamyka cykl spotkań opisanych w Scrum Guide. Ma na celu inspekcję pracy zespołu – dyskusję o procesach, komunikacji, efektywności i planowaniu ulepszeń w kolejnym sprincie.

Czy Scrum jest łatwy do wdrożenia?

Opisana przeze mnie teoria wydaje się być łatwa do wdrożenia, ale rzeczywistość bywa inna. Weźmy pod uwagę zespoły, które przez lata wypracowały sobie pewne nawyki przy tworzeniu oprogramowania. Ciężko im będzie dopasować się do zmian, jakie na nich czekają. Liczba spotkań opisanych w Scrum Guide i czas, jaki trzeba na nie przeznaczyć, może niektórych przytłoczyć. Developerzy mogą nie widzieć sensu tych spotkań i traktować je jako stratę czasu.

Z drugiej strony możemy mieć Product Ownera, który spotykając się z biznesem, nie potrafi znaleźć czasu na to, aby współpracować z resztą zespołu właśnie podczas tych spotkań. W takich sytuacjach Scrum Master odgrywa kluczową rolę. Powinien on pokazać zespołom korzyści płynące z przestrzegania metodyki Scrum – zarówno dla biznesu, jak i dla samych developerów. Warto zachęcać zespół do próbowania nowości. Każda z ceremonii scrumowych jest ważna i przybliża zespół do wykonania celu. Im lepsza komunikacja, im większa transparentność, tym łatwiej zaspokoić potrzeby klientów i spełnić oczekiwania biznesowe.

Nie wszystkie zmiany należy wprowadzać naraz. W wymagających tego przypadkach dobrze jest zacząć od małych zmian i przekonywać stopniowo zespół, że są one wartością dodaną do ich pracy. Jeśli Scrum Master będzie początkowo facylitować spotkania, wskazywać, jak powinny one wyglądać, z czasem zespoły zauważą korzyści.

Reasumując, Scrum jest jedną z opcji, które firmy mogą wykorzystać przy spełnianiu celów biznesowych. Zwinne podejście zakłada, że zespół dysponuje konkretnymi kompetencjami i jest zmotywowany do pracy. Oferuje elastyczność i akceptację zmian wymagań, eliminuje konieczność definiowania całego produktu na samym początku, wzmacnia samodzielność i odpowiedzialność zespołu. Co więcej, koncentruje się na satysfakcji klienta, a tym samym przybliża klienta do spełnienia potrzeb biznesowych.