Zespół gotowy do pracy, Scrum Master na pokładzie, a Product Owner już zaciera ręce na myśl o nowych strategiach, błyskawicznych efektach i – ostatecznie – sukcesie całego projektu. Wszędzie fruwają kolorowe karteczki, ruszamy z kopyta, a ze Scrum’em podbijemy świat!
Brzmi jak sielanka, plan idealny. Tyle tylko, że w praktyce raczej nie bywa tak bajkowo. Scrum – pomimo całej swej wartości – nie sprawi, że wszystko pójdzie gładko, a problemy znikną jak za dotknięciem czarodziejskiej różdżki. To nie panaceum na wszelkie bolączki trawiące Zespół, lecz jedynie framework, który odpowiednio wdrożony może poprawić system i organizację pracy.
Na Zespół Scrumowy składają się 3 role: Scrum Master, Product Owner i Deweloperzy. Praktyka pokazuje, że jedna osoba nie powinna łączyć dwóch lub (o, zgrozo!) trzech z tych funkcji, a wynika to z banalnej kwestii – konfliktu interesów.
Istotą całego Zespołu jest jego interdyscyplinarność. Nie znaczy to, że każdy członek musi posiadać wiedzę potrzebną do samodzielnego zrealizowania projektu (nonsens!), lecz Zespół jako całość powinien dysponować możliwościami, umiejętnościami i chęciami do rozwoju, by ostatecznie być w stanie uzyskać pożądany, w pełni funkcjonalny produkt.
Podstawą organizacji pracy w Scrum jest Sprint, na który składają się typowo wytwórczy proces oraz następujące wydarzenia:
– Planowanie Sprintu – określające cel i sposób pracy na całą iterację (Sprint),
– Daily Scrum – codzienne spotkania korygujące stan/zakres prac, systematyzujące zadania na najbliższe 24h,
– Przegląd Sprintu – stanowiący inspekcję wykonanej pracy oraz będący źródłem informacji zwrotnej pochodzącej od interesariuszy,
– Retrospektywa Sprintu – czyli analiza dotychczasowego sposobu pracy, wzajemnych relacji, czas na przemyślenia i wyraźne artykułowanie możliwych do wprowadzenia usprawnień.
Umożliwiają bieżącą weryfikację sposobu pracy, realizacji założeń, itp. oraz sprzyjają szybkiemu reagowaniu na pojawiające się wątpliwości czy wprowadzaniu zmian. Istotą powyższego jest to, by wszelkie modyfikacje i ich przyczyny były jasne, przejrzyste dla całego Zespołu, a także, by każdy rozumiał je dokładnie tak samo.
Backlog Sprintu to uporządkowany spis tego wszystkiego, co w danym momencie wiadome i uznawane za wartościowe w kwestii rozwoju produktu. Analogicznie funkcjonuje Backlog Sprintu odnoszący się do konkretnej iteracji. Precyzuje pracę, którą należy wykonać, aby osiągnąć Cel Sprintu. Przyrost to zgodna z Definicją Ukończenia wartość pracy wykonanej podczas danego Sprintu i sumy wszystkich poprzednich.
Już ScrumGuide mówi o tym, że Scrum jest lekki i łatwy do zrozumienia, ale jednocześnie dodaje, że trudny do opanowania. I choć wyżej wymienione założenia wydają się banalne, to zaaplikowanie ich Zespołowi bywa problematyczne. A czasami pierwotna ekscytacja zamienia się w rozczarowanie wynikające z niefrasobliwego wdrażania framework’u.
Poniżej kilka problemów często pojawiających się na początku pracy w Scrum:
Nagminnie zapomina się o istotności komunikacji. Brak konkretnych działań podejmowanych w celu sprawdzenia rozumienia ułożonego planu doprowadza do tego, że już w trakcie pracy albo (co gorsza!) po skończeniu pewnego etapu okazuje się, iż nastąpił dysonans, a każdy wykonał zadanie zgodnie ze swoja wizją, niekoniecznie wspólną dla wszystkich i najlepszą w kontekście rozwoju produktu. Dlatego warto, by zawsze jedna osoba podsumowała na forum przygotowany plan, co w fazie wstępnej zweryfikuje – z założenia ponadjednostkową – koncepcję.
Wiadomo, że na początku trudno określić to, ile rzeczywiście Zespół jest w stanie wykonać w trakcie Sprintu. Jest jednak zapał i energia, dlatego dorzucanie kolejnych zadań przychodzi z łatwością. A później to już kwestia przyzwyczajenia, że Backlog Sprintu pęka w szwach…
Nadmiar obowiązków, nadgodziny, narastająca frustracja albo po prostu rezygnacja i utrata satysfakcji z wykonywanej pracy… I po co komu ten Scrum?
Właśnie po to, by na spokojnie przedyskutować możliwości Zespołu, dostrzec i od razu poprawić błędy, zweryfikować dotychczasowe sposoby pracy, porozmawiać. Po to, by uniknąć wypalenia wywołanego przeciążeniem i wykonaniem bezsensownej pracy.
To po prostu unikanie trudnych, niewygodnych, niezręcznych tematów. Tabu. Zespół ma świadomość, że coś niepokojącego wisi w powietrzu, jednak nikt oficjalnie tego nie przyzna, nie rozpocznie rozmowy, bo przecież nikt nie chce być inicjatorem przygnębiającego wytykania niedoskonałości. I tu właśnie doskonale wpisuje się rola Scrum Mastera, którego zadaniem jest takie zmoderowanie dyskusji (głównie podczas retrospektywy), by oswoić przysłowiowego słonia. Otwarte omówienie problemu zaowocuje zarówno oczyszczeniem atmosfery, jak również poprawą komfortu pracy i ostatecznie lepszym produktem.
Scrum opiera się na kilku podstawowych zasadach, których obligatoryjnie należy przestrzegać. Daje jednak też dużą swobodę w podejmowaniu działań. Pozwala zorganizować pracę w taki sposób, aby na bieżąco ją weryfikować, usprawniać i uzyskiwać namacalne efekty w krótkim czasie. Ta zwinność wspomaga nie tylko sam proces wytwarzania produktu, zapewniając porządek i generując lepsze rezultaty, wpływa także na relacje, które przecież w dużym stopniu mogą wpływać na sukces. Jednakże Scrum nie jest magicznym systemem, który wyleczy Zespół ze wszystkich bolączek. Nie dla wszystkich przyniesie wymierne korzyści. Stanowi on jedynie określone ramy postępowania, zaś sam sposób implementacji zależy przede wszystkim od Zespołu, specyfiki projektu oraz zrozumienia empirycznego podejścia. I na tym właśnie polega cała trudność prostej koncepcji Scrum.
Autor: Joanna Dawidowska
Źródła:
Komentarze (0)