Jest poniedziałek rano. Miasto jeszcze śpi. W powietrzu ciągle jeszcze czuć aromat weekendu. Nawet szatan, co mieszka na Wildzie, jeszcze nie wstał z wyra. Tymczasem tramwajami, rowerami, hulajnogami, do swych biurek nadciągają deweloperzy, product ownerzy, scrum masterzy, aby zaplanować kolejny, nowy sprint.
Założę się, że w gronie naszych developerów są tacy, którzy pukają się w głowę, że to strata czasu, że „bez sensu”, etc. Widocznie nie mieli przyjemności doświadczyć dobrego, wartościowego planowania lub po prostu nie kumają, o co w tym wszystkim chodzi.
Scrum masterze, zrób coś z tym!
Gorzej, jeśli nasi product ownerzy nie widzą sensu kolejnego spotkania, na którym trzeba znowu zaplanować tydzień, dwa, czy może miesiąc roboty. Jeśli tak jest, to product ownerze szanowny, może nie potrzebujesz Scruma? Może lepiej by było, abyście zaczęli używać Kanbana?
Scrum masterze, zajmij się tym!
A co, w przypadku gdy scrum master, jadąc do roboty, gdzie czeka na niego kolejne planowanie, dostaje nerwowych tików na myśl o tym wydarzeniu? Włosy jeżą mu się na głowie a język ucieka do krtani? Znaczy to ni mniej ni więcej, że prawdopodobnie potrzebuje wsparcia.
I tu pojawiamy się MY! Drużyna doAgile!!! 🙂
A raczej ten post, w którym postaram się takowego wsparcia udzielić. Do dzieła!
Po pierwsze – CEL SPRINTU
Świadom swoich praw i obowiązków zaczynam od celu sprintu. Śmiem twierdzić, że jest on NAJWAŻNIEJSZY w dobrym planowaniu. Product owner, idąc na planowanie, oprócz tego że ma uporządkowany backlog produktu, powinien mieć też w głowie wizję kolejnego przyrostu – tego, co chciałby dostarczyć klientowi. Ta „wizja” może być zalążkiem dobrego celu, który koniecznie powinien spełniać wszelkie atrybuty CELU SMART. Cel zdefiniowany na początku planowania może być dla zespołu przewodnikiem, jakie elementy backloga należy wziąć do sprintu. Cel zdefiniowany na początku uchroni Was przed przepalaniem czasu na ewentualne dyskusje nad historyjkami, które (gdyby nie było celu) wzięlibyście do sprintu, ale w związku z tym, że nie wpisują się w niego – zostawiacie w backlogu na kolejne sprinty. Nie wspomnę o zaletach posiadania celu sprintu w trakcie prac i na podsumowaniu.
Po drugie – dobry refinement to podstawa.
Kumasz o co chodzi? Ano o to, że bardzo często można zaobserwować, jak planowanie samoistnie zamienia się w refinement. Backlog jest nieprzygotowany, historyjki opisane w sposób niewystarczający. Nie wiadomo co trzeba zrobić. Brakuje estymat, kryteriów akceptacji, etc. Zespół zamiast planować sprint skupia się na „dopieszczaniu” elementów backloga. No i co teraz? Czasu nie cofniesz. Teraz przynajmniej nazwij to, co się dzieje i uświadom drużynie, że robią kiepski refinement zamiast dobrego planowania. Dlaczego kiepski? Bo:
- często wychodzą tematy, które trzeba dogadać z osobami spoza zespołu, ale nie ma już na to czasu i do sprintu trafiają „niewiadome”,
- bo robimy go pod dużą presją czasu – przecież trzeba jeszcze zaplanować.
Mógłbym jeszcze sporo pisać, ale nie będę się pastwił. Po prostu, scrum masterze drogi, zadbaj o to, aby przed kolejnym i wszystkimi przyszłymi planowaniami zespół robił dobre refinementy. Jeśli historyjki, które będą wchodziły na planowanie, zostaną wcześniej dobrze opisane, wyestymowane, będą posiadały realne kryteria akceptacji, to planowanie będzie zwykłym przesuwaniem elementów backloga do sprintu. Bajka, prawda?
Po trzecie – weź i użyj DOR (Definition of Ready)
Jeżeli pytasz, a po cholerę nam ten cały DOR? Albo co gorsze, ulegasz wywodom product ownera, że przez to tracimy naszą zwinność, to jesteś kolego miły lub koleżanko droga, w czarnej d… Definition of Ready, czyli definicja gotowości podjęcia elementu backloga do realizacji powstała po to, aby pomóc zespołom efektywnie planować dobre sprinty. Jest to po prostu lista elementów, które muszą zostać spełnione, żeby wziąć historyjkę do sprintu.
Dla przykładu, jeżeli przyjmiemy i zaczniemy aktywnie przestrzegać następującego DOR:
- historyjka musi być wyestymowana w Story Pointach
- muszą być spisane kryteria akceptacji
- musi być informacja, po co to robimy (wartość biznesowa / business case)
- szkic ekranu musi być wcześniej uzgodniony z klientem i dołączony do historyjki,
to na planowaniu siądziemy do rewelacyjnie opisanego backloga i będziemy mogli skupić uwagę na zaplanowaniu sprintu zamiast na uzupełnianiu historyjek.
Po czwarte – nie przypisujcie już na starcie osób do wszystkich historyjek w sprincie.
Na litość faraona, nie róbcie tego! Jest to bardzo ryzykowne, zwłaszcza w zespołach, które jeszcze nie do końca połknęły bakcyla team workingu. Dlaczego? Gdyż:
- za każdą historyjkę wziętą do sprintu kolektywnie odpowiada CAŁY ZESPÓŁ DEWELOPERSKI, a nie wyłącznie osoba przypisana.
- jeżeli przypiszecie historyjkę do osoby, która dajmy na to się rozchoruje, to istnieje spore prawdopodobieństwo, że zespół do końca sprintu się tą historyjką nie zainteresuje i „uwali” sprint.
- jeżeli przypiszecie historyjkę X do Tomka, który będzie miał na sobie osiemnaście innych historyjek, to istnieje ryzyko, że Mateusz, który wcześniej skończy swoją pracę, nie zabierze się za historyjkę X, bo przecież ona jest „u Tomka”. Mateusz prawdopodobnie będzie szukał pracy w backlogu produktu, zamiast zespołowo pracować nad celem i backlogiem sprintu.
Od tego macie daily, aby codziennie móc przypisywać nieprzypisane historyjki do odpowiednich osób. Pomóż zespołowi użyć tego mechanizmu.
Po piąte – nie musicie, do licha, rozkminiać na mega niskim poziomie wszystkich historyjek.
Zróbcie to wyłącznie dla historyjek, które planujecie wykonać w pierwszej kolejności, w ciągu najbliższych dni. Pamiętaj scrum masterze szanowny i przypominaj o tym swojemu zespołowi, że w Agile jedyną stałą jest zmiana. Być może historyjki, które dzisiaj rozkminicie do ostatniego detalu, a chcecie się nimi zająć w drugiej połowie sprintu, trzeba będzie z różnych przyczyn zaorać lub analizować ponownie.
Po szóste – nie pozwól developerom udać się w objęcia Morfeusza.
Na ile się da, wprowadzaj, scrum masterze miły, takie formy, aby zaangażować cały zespół developerski. Pracujcie w podgrupach, w parach, na karteczkach. Rób przerwy, gdy atmosfera gęstnieje. Spotkanie zaczynaj od jakiegoś energetyzującego ćwiczenia (najlepiej fizycznego). Najgorsze co możesz zrobić, to pozwolić, aby deweloperzy odpłynęli ze swoimi smartfonami do wirtualnej krainy nicości. Jeśli masz kilka historyjek do rozłożenia na technologiczne czynniki pierwsze – wprowadź równoległe prace. Podziel zespół na podzespoły, tak aby każdy rozkminiał swoją historyjkę, a na koniec niech opowiedzą i przedyskutują całym teamem, co zmajstrowali.
Po siódme – goście, a jeszcze lepiej – ich brak.
Pewnie zaprotestujesz, bo nawet w Scrum Guide wyraźnie stoi, że zespół deweloperski może sobie zaprosić gości na planowanie. To prawda. Może. Lecz niekoniecznie musi. Zwróć uwagę, że jeżeli wprowadzicie w życie DOR, to każdy element backloga, który będzie miał trafić do sprintu, musi spełniać pewne kryteria. Dobrze, gdyby w ramach DOR był też skonsultowany z odpowiednimi osobami spoza zespołu. Konsultując temat przed planowaniem, macie na to więcej czasu, więcej swobody, możecie to robić iteracyjnie, może się okazać, że w wyniku konsultacji z wcześniej zidentyfikowanym gronem osób trzeba będzie jeszcze porozmawiać z innymi. Uwierz, że lepiej robi się to przed planowaniem niż na. Ponadto każdy gość zewnętrzny na sesji planowania, to duże ryzyko wydłużenia czasu trwania lub nawet porażki, czyli zakończenia bez planu. Wystarczy, że zaprosimy gadułę, która postanowi przejąć nasze spotkanie i katastrofa gotowa.
Po ósme – pomóż zespołowi powiedzieć „JUŻ DOŚĆ!”
Ile razy zdarzyło się Wam wziąć do sprintu tak dużo pracy, że nie podołaliście? Pewnie sporo, co? Nie ma w tym nic złego pod warunkiem, że wyciągacie wnioski. Mierzycie pojemność zespołu i po kilku iteracjach doskonale wiecie, na ile Was stać. Jeżeli zauważysz, że product owner naciska na zespół, aby do sprintu wziąć kilka historyjek więcej, ponad możliwości drużyny, to scrum masterze drogi, stań z developerami ramię w ramię i pomóż im powiedzieć „NIE”. Pomóż też product ownerowi zrozumieć, że próbuje zaklinać rzeczywistość, oszukując sam siebie, bo przecież plan, który chce przeforsować, jest z założenia nierealny. Jedna ważna uwaga – jeżeli zespół mówi „NIE”, to powinien poprzeć to konkretami: wykresem prędkości, niedostępnościami kluczowych specjalistów w sprincie, etc. Z drugiej strony, nie możesz dopuścić do sytuacji, w której developerzy asekuracyjnie będą gotowi na podejmowanie zbyt małej liczby historyjek, poniżej ich capacity. Bądź czujny i opieraj się na faktach. To bardzo delikatny temat.
Po dziewiąte – zróbcie sobie daily
Serio! Na koniec planowania, zanim się rozejdziecie, zróbcie sobie daily. Dlaczego? Niejednokrotnie byłem świadkiem sytuacji, w której członkowie zespołu po powrocie z planowania nie wiedzieli, czym się zająć w pierwszej kolejności. Chodzili, dopytywali, szukali zależności. Pół biedy, kiedy wszyscy pracują w jednej lokalizacji. Gorzej, jeżeli część zespołu pojechała do swojego miasta i będzie z nimi można porozmawiać dopiero następnego dnia. A wystarczyło przed rozejściem się zrobić rundkę, w której każdy powiedziałby, czym się zajmie po powrocie do biurka. Jak na standardowym daily.
Po dziesiąte – nie bądź sekretarką
Jeśli dasz się wmanewrować w rolę sekretarki na planowaniu, będziesz pisał karteczki, czy pochłonie Cię JIRA lub inne narzędzie, którego akurat używa Twoja drużyna – przegrałeś. Nie pomożesz zespołowi przeprowadzić efektywnego spotkania. Nie zauważysz, gdy zaczną odpływać. Nie będziesz w stanie dać im coraz lepszych planowań, bo po prostu twoje zmysły zajmą się pisaniem, zamiast czujnie obserwować przebieg spotkania i reagować, gdy zachodzi potrzeba.
To wszystko, czym mogłem się dzisiaj z Tobą podzielić. Weź dla siebie to, co uważasz za przydatne. Postaw łapkę w górę na Facebooku lub LinkedInie, jeśli coś z tego wpisu weźmiesz dla siebie. Jeśli coś jest niejasne lub się nie zgadzasz – napisz komentarz. Podyskutujmy.
Miłego dnia!