Dziś w kąciku praktycznego Scruma porozmawiamy o Celu Produktu i Celu Sprintu. Punktem wyjścia będzie dla nas pytanie, jak wyznaczać te cele, jeżeli nasz zespół zajmuje się milionem drobnych i niepowiązanych ze sobą rzeczy?
Wiele Rzeczy Na Raz
Jeżeli mamy problemy z definiowaniem Celu Produktu i Celu Sprintu, to do głowy przychodzą mi od razu dwa typy. Po pierwsze, być może w ogóle nie mamy do czynienia z zespołem. Po drugie, jest też szansa, że pracujemy bez żadnego celu, bo go po prostu nie mamy – realizujemy luźne i niepowiązane ze sobą rzeczy i klient nie zastanawia się, dokąd te prace zmierzają. Mamy wtedy problem, ale dość prosty do rozwiązania. Przecież po to mamy Product Ownera, aby reprezentował on klienta. Gdy ten ostatni nie przejawia chęci do tworzenia wizji, to PO go wyręcza.
W tekście „Co stanowi zespół?” postawiliśmy tezę, że zespół nieodłącznie związany jest ze wspólnym celem. To znaczy, że losowa grupa ludzi połączona osobą przełożonego to jeszcze nie jest zespół. Jeśli każdy ma „swoje zadania” i realizuje „swoje cele”, to trudno mówić o zespołowości, a tym bardziej o Scrum Teamie. Nagraliśmy nawet o tym film na YouTube.
Drugą przyczyną trudności w definiowaniu celów może być po prostu faktyczny brak celowości. I tu też mamy dwie przyczyny: Product Owner bez wizji (patrz: 3 Grzechy Product Ownera) lub zbytnie nagromadzenie rozłącznych tematów w backlogu.
Jeżeli PO przyjmuje od klienta wszystko „jak leci”, to trudno jest powiedzieć, żebyśmy rozwijali nasz produkt w jakimś konkretnym kierunku. Ot, po prostu rośnie. Jeżeli zaś w naszym Product Backlogu mamy czterdzieści dwa systemy oraz piętnaście „projektów” rozwojowych, to faktycznie trudno nam będzie wybrać „co jest najważniejsze”.
W przypadku Celu Sprintu lubię w takich sytuacjach przeprowadzać mały eksperyment myślowy. Wyobraźmy sobie, że stanie się coś, co uniemożliwi połowie zespołu pracę przez kilka dni. Które rzeczy naprawdę muszą dojechać, a które będziemy z mniejszym bądź większym żalem poświęcać?
Zastanowienie się nad tym, co możemy poświęcić na rzecz czego pomoże nam w wyznaczeniu Celu Sprintu. Ale wcale nie pomoże na bałagan w backlogu czy na brak określonej wizji dla naszego produktu. Na szczęście Scrum ma na to odpowiedź.
Jedna Rzecz Na Raz?
Jedną z Wartości Scrum jest Skupienie, a inną – Zaangażowanie. Podręcznik Scrum opowiada o nich w własnie kontekście Celów – Produktu i Sprintu. Jasno i wyraźnie mówi, że w jednym momencie można dążyć tylko i wyłącznie w jednym kierunku. Jeżeli chcemy iść gdzieś indziej, to możemy to zrobić po osiągnięciu poprzedniego celu bądź przy jawnej i świadomej rezygnacji z tegoż.
„The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.” – Scrum Guide
Wspomniane w cytacie cele, to oczywiście Cel Produktu i Cel Sprintu. To na nich skupiony jest Scrum Team i to właśnie te dwa cele chce jak najszybciej osiągnąć. A tak naprawdę powinniśmy powiedzieć, że chcemy osiągnąć Cel Produktu spełniając kolejne Cele Sprintu. No bo przecież nasz stary dobry Sprint Goal zazwyczaj będzie krokiem w kierunku Product Goal. Inaczej być nie może, bo w przeciwnym wypadku nigdy nie osiągniemy tego ostatniego.
Powiedzmy więc to jeszcze raz, bez powtarzania w kółko słowa „cel”. Chcemy osiągnąć jakiś konkretny stan naszego produktu. Aby to zrobić, potrzebujemy co Sprint realizować konkretne kroki w tym kierunku. Tylko dzięki temu, możemy mieć pewność, że w końcu nam się to uda. Jeżeli mamy „wiele różnych celów” albo co chwila je zmieniamy, to szansa na to, że gdziekolwiek dojedziemy są marne, a o skupieniu i zaangażowaniu możemy zapomnieć.
Tylko, że w „prawdziwym życiu” zwykle nie możemy robić tylko i wyłącznie jednej rzeczy. Na szczęście Scrum jest jak najbardziej życiowy i mówi, że możemy robić tyle różnych rzeczy, ile nam się podoba. Ale skupić mamy się tylko na jednej.
Jeden Priorytet Na Raz!
Do końca życia nie zapomnę rozmowy, w której zostaliśmy zapytani o pewne praktyczne zastosowanie „zwinnego podejścia”. Pytanie brzmiało: jak przy pomocy „agile’a” zapewnić efektywną pracę zespołów, które mają „skupić się” na kilkunastu projektach realizowanych na raz? Odpowiedź jest prosta: nie da się.
Niezależnie od tego czy to agile, czy waterfall, nie możemy „skupić się” na więcej niż jednej rzeczy. Film o multitaskingu nagraliśmy trzy lata temu i wyłączając aspekt techniczny nie zestarzeje się on nigdy. Nie da się efektywnie robić miliona rzeczy na raz, ani skakać od jednej rzeczy do drugiej. Tylko to wcale nie znaczy, że jesteśmy skazani na robienie tylko i wyłącznie jednego.
Po pierwsze, skupienie nie wyklucza robienia rzeczy mniej ważnych. To, że naszym Celem Produktu #białko jest aktualnie wydanie książki to wcale nie znaczy, że nie przeprowadzamy szkoleń Scrum, ani że nie uruchomiliśmy naszej listy mailingowej. Ba, czasami zdarzy się nam „Cel Sprintu”, który w ogóle nie dotyczy wspomnianej książki. Ale przynajmniej wtedy jasno wiemy, że robimy nie to, co chcemy, tylko np. to, co musimy. To boli, ale pozwala przeprowadzić późniejszą adaptację.
Pamiętajmy, że zwinne plany są także po to, żebyśmy widzieli od nich odstępstwa. I Cel Sprintu, który nie wspiera Celu Produktu powinien nas kłuć w oczy.
Po drugie i być może jeszcze ważniejsze, mamy inny sposób na zapewnienie zarówno skupienia jak i wielozadaniowości. Wystarczy przywołać tytuły takich tekstów jak „Twoje zespoły są za duże!” oraz „Jak dobrać wielkość zespołu?”, aby wszystko stało się jasne. Zamiast posiadać jeden-dwa duże zespoły borykające się z brakiem konkretnego celu, podzielmy je na trzy-pięć mniejszych, z których każdy będzie miał swoją specjalizację.
Te dwie techniki można zresztą zgrabnie połączyć. Nawet jeśli zespół ma swoją specjalizację i swój kawałek tortu zwanego backlogiem, to może też przecież robić inne rzeczy. Tylko wtedy nie są one jego celem, ani priorytetem. Pamiętajmy, że skupić możemy się tylko na czymś konkretnym. A skoro tak, to na pewno Cel Sprintu dla każdego z mniejszych zespołów będzie łatwy do określenia. A może nawet uda nam się zbudować Cel Produktu.
Tylko to wymaga odwagi, przebudowania zespołów i zerwania z nałogiem multitaskingu. Jesteście na to gotowi?
