Agile i co dalej? Czyli krótki poradnik dla tych, którzy rozpoczynają projekt w metodykach zwinnych cz. 3

W poprzednich artykułach wspominaliśmy o kontrastowych podejściach do Agile oraz o identyfikowaniu i realizowaniu wartości wyznaczonych w projekcie. 

W ostatniej części serii artykułów o Agile dowiesz się:

• W jaki sposób metodyka Scrum napędza pracę zespołu?
• Na jakich elementach projektu należy się skupić, pracując w Scrumie?

---

Scrum to istny silnik produktywności!

Zespół, który pracuje w metodyce Scrum szybciej dostarczy Ci produkt.

Aby zespół efektywnie pracował w Scrumie, należy narzucić wykonywanym pracom odpowiednie tempo. Najtrudniejszym elementem całej układanki jest fakt, iż owe „tempo” zależy od bardzo wielu czynników. Do najistotniejszych z nich należą:  

• zgranie zespołu i wiedza jego członków;
• podział pracy w zespole;
• sposób zarządzania backlogiem przez Product Ownera;  
• zbieranie feedbacku;
• zebranie użytkowników, którzy chętnie dzielą się informacją zwrotną; 
• organizacja, w której nie narzuca się ram pracy kolidujących z metodykami zwinnymi; 
• Scrum Master, który na bieżąco koordynuje pracę całego zespołu.

Każdy z tych elementów osobno brzmi banalnie, jednak kluczem do sukcesu jest poprawne działanie wszystkich.

Warunek 1: Multitasking musi odejść! 

Mnogość wątków nie służy produktywności i ze sporym prawdopodobieństwem stanowczo wydłuży proces wytwarzania produktu. Nie staraj się w pierwszej wersji swojego produktu zawrzeć wszystkiego (byłoby to skrajnie nieagileowe!). Skup prace na jednym, dominującym wątku. Pomoże Ci w tym regularne aktualizowanie roadmapy produktu oraz wytyczenie jasnych i zgodnych z wizją rozwoju produktu celów na kolejne sprinty. Dzięki temu unikniesz „rozgrzebania” wielu tematów i funkcji.  

Warunek 2: Dewelopuj tak, jakby ten sprint miałby być Twoim ostatnim

Staraj się układać zakres projektu w taki sposób, abyś miał możliwość zakończenia go dokładnie w momencie, kiedy poczujesz, że to, co zostało zrobione, w zupełności Ci już wystarczy. Wyobraź sobie sytuację, w której firma X zleca duży projekt wykonania aplikacji podwykonawcy. Prace toczą się wielowątkowo, a zadania nie są priorytetyzowane zgodnie z potrzebą biznesową. Dwa miesiące po starcie projektu, firma X zaczyna mieć problemy finansowe i musi zamknąć projekt. Jednakże nie jest w stanie w żaden sposób wykorzystać zainwestowanych pieniędzy. Gdyby pracę układać zgodnie z przykazaniami zwinności, po 2 miesiącach firma X miałaby już działającą i potencjalnie zarabiającą na siebie (choć trochę mniejszą od zakładanej) aplikację.  

Nie życzę nikomu sytuacji, w której jest się zmuszonym do przedwczesnego zamykania projektów. Natomiast każdemu życzę możliwości powiedzenia „stop” kiedy nie czuje już dalszej potrzeby wykonywania prac przy tworzeniu produktu (dlatego zostałam Scrum Masterem).  

Zastanów się, czy Product Owner będzie w stanie równie efektywnie współpracować z interesariuszami wielu elementów i równie skrupulatnie zbierać feedback od użytkowników. Mocną stroną Scruma jest iteracyjność, małe kroki, które jednak bardzo mocno przybliżają do osiągnięcia celu biznesowego. Korzystaj z tego!

„Scrum to prosty framework stworzony by pomagać małym, blisko współpracującym ze sobą grupom ludzi tworzyć złożone produkty”.

– Chris Sims

Gdyby to było takie proste, to nie powstałby ten artykuł! 🙂

Jest kilka elementów, o których należy pamiętać, aby Scrum rzeczywiście pomagał a nie przeszkadzał (zarówno Klientom, jak i zespołom developerskim).

Zasada 1: Myśl, próbuj i decyduj ŚWIADOMIE

„Robimy 2-tygodniowe sprinty, bo wszyscy takie robią”.

„Używamy systemu X do zarządzania backlogiem, bo wszyscy go używają”.

„Mamy Scrum Mastera jako oddzielne stanowisko, bo na tej konferencji mówili, że tak jest lepiej”.

„Product Owner jest pracownikiem firmy klienta, bo przecież tak się robi”.

Kiedy słyszysz takie głosy od kogokolwiek, zatykaj uszy i nie słuchaj! Wróć do sloganu i jeszcze raz zastanów się nad jego przesłaniem. Nie bez powodu mówi się, że Scrum to framework, bo przecież zostawia całą masę pól, w których metodykę możesz dopasować do potrzeb swojego projektu.

Mówią Ci, że 2-tygodniowy sprint jest najlepszy? Możliwe, że dla Ciebie również!  Ale podejmij decyzję o długości sprintu świadomie. Pracujesz z nowym zespołem – może warto wybrać krótszy sprint, aby dać im więcej szans na „dotarcie się” i przystosowanie tempa pracy? W projekcie zachodzi sporo bieżących zmian, więc trudno jest Ci zaplanować pracę na dłuższy czas. Skrócenie iteracji pozwoli na większą przewidywalność zakresu najbliższego sprintu! System X do zarządzania backlogiem jest popularny, ale wydaje Ci się zbyt rozbudowany dla Twoich potrzeb? Zacznij od flipcharta lub tablicy – w tej kwestii także warto zastosować iteracyjny rozwój, zanim wydasz dodatkowe pieniądze na licencje dla użytkowników. 

Zasada 2: Chodzi o PRODUKT

Tak, w całym Scrumie chodzi tylko i wyłącznie o jedno – produkt. Wszystko, co dzieje się w każdej metodyce zwinnej, ma na celu doprowadzenie do powstania jak najlepszego produktu. Daily Sprint trwa już 5 minut dłużej niż przewidziano i boisz się, że przez to już nie pracujesz w Scrumie? Bzdura! Potraktuj to jako sygnał do sprawdzenia, czy dyskusja jest rzeczowa, realnie potrzebna na tym etapie i czy wszyscy, którzy się tam zebrali powinni być uwzględniani na spotkaniach. Oczywiście takie dyskusje to już nie daily, ale nie czuj presji by przeganiać ludzi ze spotkania tylko dlatego, że gdzieś napisano, że już skończył się czas.  

Wszystkie spotkania Scrumowe (planowanie, przegląd, daily, retrospekcja) mają na celu zorganizowanie pracy przy budowaniu produktu. Jeśli przed planowaniem zespół świetnie przygotował się do kolejnego sprintu (zapoznał się i doprecyzował zadania, zadał konieczne pytania i uzyskał na nie odpowiedzi, a wszyscy wiedzą, jak rozłożyć sobie prace w kolejnej iteracji), to może się zdarzyć, że planowanie będzie trwało o wiele krócej od tego zakładanego w Scrum Guide. Pamiętaj, że sztandarowa samoorganizacja zespołów zwinnych nie ma na celu „rozpuszczenia” zespołu deweloperskiego. Ma natomiast za zadanie umożliwienie tej grupie ludzi podjęcia samodzielnej decyzji, co im najbardziej ułatwia pracę i w jakim trybie najbardziej efektywnie wytwarza im się PRODUKT.   

Wróćmy jeszcze na chwilę do sloganu. Mówi on jasno o złożonych produktach. Scrum, mimo swojej zakładanej prostoty, to całkiem spora (i całkiem kosztowna) machina, przy uruchamianiu której trzeba się zastanowić czy warto w nią inwestować. Nie każdy produkt potrzebuje takiej organizacji pracy, więc nie staraj się za wszelką cenę dopasować projektu do zwinności, tylko dlatego, że wszystko teraz jest takie „Agile”. Kiedy zaczynasz pracę nad nowym produktem, zapoznaj się z różnymi metodykami i znajdź taką, która będzie służyć zarówno Tobie, jak i produktowi. 

Sloganów propagujących Agile znajdziesz i usłyszysz jeszcze bardzo wiele. Pamiętaj, że za każdym z nich stoi równie wiele warunków, bez których te “złote Graale” zwinności będzie o wiele trudniej osiągnąć. Mam nadzieję, że udało mi się przedstawić tych kilka elementów, o których należy pamiętać na początku drogi ku zwinności. Pamiętaj tylko, żeby na nich nie skończyć!

Analizuj, testuj, zastanawiaj się, pamiętaj o produkcie i podejmuj decyzje świadomie – tylko wtedy będziesz mógł zbierać realne korzyści z bycia Agile. Powodzenia!

Jeżeli zainteresował Cię ten artykuł, zachęcam do zapoznania się z pierwszą oraz drugą częścią cyklu o Agile.