Dlaczego warto pracować w Scrumie? 6 powodów i przykłady z praktyki

Każdy projekt w Scrumie zaczynamy od warsztatów biznesowych z klientem. Razem ustalamy ramy projektu, w tym najważniejsze funkcje aplikacji lub strony.

Często jednak pomysły rozmijają się z rzeczywistością. Pierwotne założenia mogą nie być w 100% trafne, bo od czasu ich ustalenia zmieniły się trendy na rynku.

Czasem trzeba zobaczyć funkcję, żeby zrozumieć, że nie ma sensu. I odwrotnie: czasem trzeba zauważyć, że jakiejś funkcji brakuje, żeby odkryć, że jest potrzebna.

W Scrumie na koniec każdego sprintu odbywa się demo produktu, na którym zespół pokazuje klientowi aktualną wersję. Razem zastanawiamy się, co jest potrzebne, co zbędne, a co warto poprawić.

Dzięki temu klient na bieżąco wpływa na przebieg prac. Nie kodujemy czegoś tylko dlatego, że zaplanowaliśmy to trzy miesiące temu. W Scrumie kodujemy tylko to, czego klient i jego klienci naprawdę potrzebują.

Przykład z projektu:

Klient z branży spożywczej zlecił nam odtworzenie starych wersji istniejących stron i zbudowanie dedykowanego CMS-a. Po warsztatach biznesowych ustaliliśmy, że wszystkie strony stworzymy od zera, korzystając z treści z poprzednich wersji.

Dzięki cotygodniowym spotkaniom dowiedzieliśmy się, że część starych stron zawiera bezużyteczne informacje i nieaktualne sekcje, których nie powinniśmy uwzględniać w zakresie prac. Oszczędziliśmy w ten sposób czas klienta i własny, a mogliśmy pomyśleć o czymś nowym, co przyda się użytkownikom.

Po warsztatach biznesowych z klientem tworzymy wstępną listę funkcji i zaczynamy kodować. Sprinty, w których pokazujemy efekty pracy i omawiamy kolejne kroki, trwają tydzień lub dwa. Więcej o naszym procesie przeczytasz w artykule How we do IT

Czasem jednak już po pierwszym lub drugim sprincie okazuje się, że produkt jest wystarczający. Dzięki szybkiemu feedbackowi niektóre projekty planowane na kilka miesięcy oddajemy dużo wcześniej, oszczędzając klientowi czas i pieniądze.

Przykład z projektu:

Dla klienta z branży energetycznej zaprojektowaliśmy nowy panel dla konsultantów firmy. W jednym z pierwszych sprintów przygotowaliśmy podstawową wersję, tylko żeby pokazać najważniejsze funkcje.

Okazało się, że wersja demo w zupełności wystarcza klientowi i jego pracownikom, więc zatrzymaliśmy dalsze prace nad UX. Dzięki temu klient zaczął używać panelu w firmie dużo wcześniej, niż planował.

Po kilku latach pracy w metodyce waterfall wiemy, że klienci najbardziej stresują się wtedy, gdy nie wiedzą, co dzieje się w projekcie. Czy wszystko idzie zgodnie z planem? Czy projekt zmierza w dobrą stronę? Czy wiem wszystko, co powinienem?

W Scrumie klient jest pełnoprawnym członkiem zespołu produktowego i uczestniczy w cotygodniowych demach. Dzięki temu dobrze zna postęp prac, bieżące problemy i możliwe zagrożenia.

Wiedza płynie między klientem a programistami bez przeszkód, nie ma niedomówień ani niejasności.

Przykład z projektu:

Branża finansowa. Żeby posuwać projekt naprzód, potrzebowaliśmy stałego dostępu do specjalistycznej wiedzy, którą miał tylko klient. Założyliśmy więc osobny kanał na Slacku, na którym na bieżąco wymienialiśmy się wiedzą ze specjalistami finansowymi po stronie klienta.

Dzięki temu klient dokładnie wiedział, nad czym i w jakim tempie pracujemy.

W projekcie scrumowym każdy musi wyjaśnić reszcie zespołu, czym zajmuje się w danym sprincie. Żaden programista nie pracuje w izolacji, a informacje o poszczególnych zadaniach krążą w zespole i są dostępne dla wszystkich. Jak pisaliśmy wyżej, klient też jest częścią zespołu produktowego.

Dzięki temu projekt jest odporny na urlopy i nieprzewidziane sytuacje, np. nieobecność z powodu choroby. Gdy nagle zabraknie testera, wszyscy wiedzą, co robić przy testach, i można pracować dalej bez opóźnień.

Przykład z projektu:

W Skandynawii lipiec to miesiąc długich urlopów. Nie inaczej było u naszego klienta z branży energii odnawialnej, który wyjechał na cały miesiąc.

Przed wyjazdem uczestniczył w spotkaniach demo, a cały zespół znał zadania każdego programisty, więc miesięczna nieobecność klienta nie zatrzymała projektu. Udało nam się nawet rozwiązać bez jego udziału problem, który zwykle leży po stronie klienta!

Daily Scrum to spotkanie, na którym cały zespół mówi o wczorajszej pracy i o tym, czym zajmie się dzisiaj. Programiści słuchają się nawzajem i dzielą z resztą zespołu informacjami, które mogą wpłynąć na zadania danego dnia.

Dzięki temu zespół pracuje płynniej. Nie stoimy w miejscu, bo czegoś nie wiemy. Nie robimy niepotrzebnej pracy, bo szybciej sprawdzamy, czy dane działania mają sens.

Daily Scrum pomaga korygować kurs projektu na poziomie codziennej pracy programistów.

Przykład z projektu:

Przy planowaniu sprintu w projekcie związanym z bezpieczeństwem jeden z programistów przygotował listę warunków do spełnienia. Omówiliśmy je jednak w zespole i doszliśmy do wniosku, że wymagają 2x dłuższej pracy.

Zaczęliśmy przedstawiać swoje pomysły na to, jak dowieźć projekt w ustalonym czasie. Razem wypracowaliśmy warunki, które udało się spełnić w terminie, i dostarczyliśmy produkt na koniec sprintu.

Wszystkie powyższe argumenty sprowadzają się do jednego, naszym zdaniem najważniejszego:

Scrum zachęca klienta i zespół programistów do ścisłej współpracy.

Razem budujemy produkt w oparciu o zaufanie, partnerstwo i otwartą wymianę informacji. Klient uczestniczy w procesie, więc może na bieżąco korygować kurs projektu. Może przekazywać feedback i zauważać, czy jakieś funkcje są mu potrzebne albo czy czegoś brakuje.

Z kolei zespół programistów też jest bardziej zaangażowany: koduje i współtworzy produkt z klientem. Członkowie zespołu słuchają pomysłów klienta i proponują własne. W ten sposób aktywnie uczestniczą w życiu projektu.

W efekcie produkt powstaje we współpracy i jak najlepiej odpowiada na potrzeby klienta.

Dlatego zdecydowaliśmy się pracować zwinnie i zachęcamy do tego wszystkich, z którymi współpracujemy.