ScrumBut, czyli jak zwinnie zniszczyć Twój projekt

Nasze projektowe spotkania scru­mowe nie odby­wają się bądź są niezgodne z za­sadami metodyki. W efekcie tego za­chowania, człon­kowie zespołu nie przekazują sobie ważnych informacji. Często pod koniec iteracji nagle okazuje się, że nie wszystko jest zrobione tak, jak należy. Pamiętaj, że komunikacja to pod­stawa w wykorzystaniu możliwości SCRUM.

By uniknąć problemu braku spotkań, wy­starczy zaangażowanie twojego Scrum Ma­stera, który powinien zrobić wszystko by nasze piętnastominutowe spotkanie odbyło się bez przeszkód. Łatwo przewidzieć, że spotkania znikną niedługo z kalendarza, jeże­li zauważyłeś, że trwają za długo i odbywają się w losowych miejscach. Brak komunikacji często prowadzi też do spadku morale i bra­ku potrzeby aktualizacji statusu oraz opisu zadania. Na koniec iteracji może to spowo­dować poważne zamieszanie w projekcie, szczególnie gdy ktoś pracował z nieaktual­nymi danymi.

Retrospektywa to świetny sposób na powiedzenie sobie prawdy o tym, co warto poprawić. Nie­stety prawda często boli – więc nie każdy chce usłyszeć gorzkie słowa o sobie, projekcie czy procesach, które zawiodły w ostatniej iteracji. Często niedo­świadczony manager sugeruje opuszczenie sobie retrospekcji, „bo przecież iteracja się udała, a zaraz idzie druga”.

Buduje to tymczasowe poczucie, że wszystko jest w porządku. Jednak zawsze mści się to na członkach zespołu projektowego. Jeżeli drużyna tłumi w sobie uwagi i zauważasz, że po prostu nie narzeka – war­to zapytać, czy wszystko jest w porządku. Uwagi mogą przekazać anonimowo, jeżeli mają wewnętrzną blokadę przed jawnością. Następnym razem naciskaj na prawdziwą retrospektywę. Podstawą i największą zaletą SCRUM jest otwartość i jawność. Wykorzy­staj to!

Co za dużo, to nie­zdrowo. Sprawdza się to również przy planowaniu projekto­wych sprintów. War­to skupić się wtedy na krótkich, 14-dnio­wych okresach. W in­nym wypadku zadania mogą okazać się za duże, a niespodziewane problemy (choroby pracowników, zmiany wymagań) położą całą iterację. Krótsze sprinty to mniej zagrożo­nych zadań i większa szansa na „dowiezienie” ich klientowi. Pamiętajmy o tym, że chcemy oddawać małe, działające „paczki” naszego projektu do klienta.

Dzięki skróceniu iteracji częściej będziemy otrzymywać informacje zwrotne od inwe­stora na temat jakości naszej pracy. Takie informacje są na wagę złota. Szczególnie w pierwszych iteracjach, gdy jeszcze pozna­jecie się nawzajem. Przy za długim sprincie łatwo sobie wyobrazić reakcje zespołu na złe wieści dotyczące efektów ich dwumiesięcz­nego sprintu. Unikajmy takich rozczarowań, by utrzymać wysokie morale w drużynie.

Są projekty, w któ­rych Definition of Done to legenda. Ktoś gdzieś sły­szał, że warto to mieć. Nie mylił się. W dobrze zarzą­dzanym projekcie nie wystarczy powiedzieć „zrobiłem”. Ważne by w naszym zespole określić jasno czym jest DoD i przedyskutować to z zespołem. Za­zwyczaj nasz kod musi przejść przegląd, po­tem testy powinny sprawdzić jakość naszego produktu itd.

Niestety bez takiego podejścia przysło­wiowe „będzie Pan zadowolony” może być gwoździem do trumny naszego przedsię­wzięcia przedsię­wzięcia. Nie można pozwolić na brak jasnego i łatwego sposobu weryfikacji efektów pracy twoich programistów.

Trzeba to powiedzieć wprost – wielu Scrum Masterów pełni tę rolę z przypadku. Odbija się to oczywiście negatywnie na projektach. Zamiast 100% możliwości, jakie daje nam metodyka, możemy otrzymać potworka, który odbije się czkawką trudną do przewidzenia. Oczywiście warto dawać szansę naszym ludziom, jednak nie oczekujmy, że efekty ich pracy będą takie same jak profesjonalnego Scrum Mastera.

Wybieranie do realizacji w pierwszej kolejności tak zwanych low-hanging fruits kuszą każdego developera czy testera. Nie są jednak dobrą opcją do wyboru na początek iteracji. Jedną z podstawowych wartości SCRUM jest odwaga, więc nie bójmy się wyzwań.
Dzięki odważnemu podejściu uzyskamy o wiele więcej wiedzy, którą wykorzystamy w późniejszych iteracjach.

Praca w naszym projekcie idzie peł­ną parą. Jesteśmy już po kilku sprin­tach i nagle okazuje się, że kilka zadań nabrało nowego znaczenia. Mamy więcej informacji, wymagań i doświadczenia wynikającego z realizacji innych celów pro­jektu.

Właśnie wtedy warto przejrzeć zadania i spróbować estymować je na nowo. Sami zdziwicie się, jakie efekty może przynieść po­nowna dyskusja o zadaniach „łatwych” oraz tych „trudnych”.