Ten post jest częścią cyklu Pierwsze Dni Scrum.

Wczoraj rozmawialiśmy o tym, jak ważną rolę w Scrum pełni Właściciel Produktu i jego główne narzędzie komunikacji, jakim jest Backlog Produktu. Dzisiaj przyjrzymy się temu, jak powinien wyglądać Backlog, żeby dobrze pełnił swą rolę.

Do czego właściwie służy Backlog?

Backlog Produktu jest narzędziem planowania. Planowanie to ma dwa główne cele:

1. pomagać zespołowi jak najszybciej dostarczać największą możliwą wartość,
2. ułatwić organizację pracy i śledzenie jej postępów.

Jakie są cechy dobrego backlogu?

Aby skutecznie realizować wyżej wymienione cele Backlog powinien być:

1. Zrozumiały dla PO, zespołu i odbiorców – tylko wtedy może stymulować i wspierać rozmowy, które są niezbędne do określenia gdzie leży wartość i jak zespół może ją dostarczyć uwzględniając ograniczenia osobowe, techniczne i organizacyjne.
2. Uporządkowany z uwzlędnieniem wartości, pracochłonności i ryzyka, w taki sposób, żeby jego sukcesywne realizowanie przynosiło organizacji największe możliwe korzyści. Nie istnieje jednoznaczny algorytm pozwalający pogodzić wszystkie te czynniki: odpowiednie ich wyważenie powinno wyłaniać się z komunikacji między PO, zespołem i odbiorcami.
3. Żyjący – Backlog powinien ewoluować wraz z wzrastającą wiedzą wszystkich zainteresowanych. Wymagania “na teraz” powinny być GOTOWE (patrz niżej), a dalsze plany mogą być jedynie naszkicowane. Powinniśmy unikać przeinwestowania w szczegółowe rozpisanie backlogu na wiele miesięcy do przodu, bo praca ta zostanie zmarnowana przez nieuniknione zmiany.

Nie tylko historyjki

W zwinnych zespołach elementy backlogu najczęściej mają formę historyjek użytkownika (którymi zajmiemy się jutro). Nie jest to jednak obowiązek. Elementy backlogu mogą mieć też inne formy:

1. Hasłowe określenie tematu historyjki, o ile jest zrozumiałe dla wszystkich zainteresowanych.
2. Bardziej szczegółowy opis funkcjonalności np. w formie pełnych przypadków użytkownika (use case)  lub wręcz siatek poszczególnych widoków. Takie podejście ma swoje wady, ale czasem jest właściwym rozwiązaniem.
3. Defekt odkryty po zakończeniu sprintu (warto zainwestować w jakość wewnątrz sprintu, by było ich jak najmniej).
4. Eksperyment techniczny nie będący realizacją konkretnej funkcjonalności, ale pozwalający odpowiedzieć na ważne pytania i podjąć lepsze decyzje co do dalszego rozwoju produktu.
5. Cel biznesowy bez określenia sposobu jego realizacj. W takim przypadku warto określić:
   • wartość jaka nas interesuje np. łatwość użycia, responsywność lub konwersja,
   • miarę, która pozwoli nam zmierzyć tą wartość np. % wykonania zadania z sukcesem w testach z 20 użytkownikami, czas oczekiwania na otwarcie danej strony lub konwersja (w tym przypadku wartość jest jednocześnie miarą).
   • punkty odniesienia np. w przypadku responsywności: zastępowany system: 1 min, obecna wersja nowego systemu: 30 sek, główny konkurent: 15 sek, nasz cel: 10 sek.

Ta ostatnia metoda zostawia najwięcej swobody zespołowi, co pozwala najskuteczniej wykorzystać pełen zakres kompetencji i kreatywności jego członków, lecz jest też najbardziej wymagająca z punktu widzenia psychologicznego i organizacyjnego.

Co to znaczy, że element backlogu jest GOTOWY?

Elementy backlogu zakończone przez zespół w danym sprincie muszą być zrobione “na gotowo” (czyli spełniać Definicję Ukończenia, ang. Definition of Done). W przeciwnym wypadku Właściciel Produktu nie może ich zaakceptować i nieskończone elementy smutno wracają do Backlogu by być zrepriorytetyzowane (i być może porzucone). Tak samo historyjki przedstawiane przez PO do realizacji powinny być GOTOWE do realizacji.

Co to znaczy gotowe? Dobrze opisuje ten problem Roman Pichler w artykule “The Definition of READY”. Według Romana najważniejsze jest by GOTOWE elementy backlogu były:

1. zrozumiałe i jednoznaczne (clear) – wszyscy zainteresowani muszą rozumieć o co chodzi,
2. testowalne – musi się dać jednoznacznie odpowiedzić na pytanie czy dany element działa poprawnie,
3. realistyczne – muszą być możliwe do zrealizowania przez zespół w jeden sprint, uwzgledniając też przewidywane zaburzenia w pracy (urlopy, święta, wydarzenia firmowe, nagłe ataki zimy, itd.).

To dobre kryteria, jednak zawsze powinny być przez Was uzupełnione i dostosowane do Waszych potrzeb. Wynikająca z tych ustaleń Definition of Ready powinien być zapisany w powszechnie dostępnym miejscu tuż obok Definition of Done, a zespół powinien mieć prawo (i obowiązek) by nie przyjmować do realizacji historyjek, które nie są GOTOWE.

Kiedy w Scrum zajmujemy się Backlogiem?

Z powyższych rozważań wynika, że wytworzenie i utrzymanie dobrego backlogu może być bardzo pracochłonne. Wysiłek ten jednak zwraca się z nawiązką już po kilku sprintach i dlatego warto zarezerwować w procesie odpowiednio dużo czasu na pracę nad backlogiem. W Scrum przyjmuje to formę następujących wydarzeń:

1. Planowanie Wydania – obejmuje wzmożoną pracę PO, który wspólnie z zespołem i w porozumieniu z odbiorcami musi przygotować listę rzeczy do zrobienia wykraczającą tak daleko w przyszłość, jak jest to niezbędne (zwykle kilka sprintów lub kwartał) i doprowadzić najbliższe zadania do stanu GOTOWOŚCI.
2. Planowanie Sprintu – to ostatnia szansa na dopracowanie najpilniejszych historyjek. Obejmuje szczegółowe omówienie ich znaczenia oraz proponowanego rozwiązania oraz przyjęcie danego elementu przez zespół do realizacji.
3. Backlog Grooming (pielęgnacja lub “czesanie” backlogu) – to worek na mniej obciążające prace równomiernie rozprowadzone między pozostałe prace. W ramach pielęgnacji backlogu PO sam ulepsza, przepisuje i zmienia kolejność elementów backlogu, deleguje część tych zadań na zespół oraz potwierdza trafność i aktualność nadchodzących zadań z odbiorcami systemu. Dobrą praktyką jest zarezerwowanie około 10% czasu zespołu na pielęgnację backlogu. Jeśli zespół poświęca na to mniej czasu to backlog będzie zbyt oderwany od realiów ich pracy, a jeśli dużo więcej to zaburzy realizację bieżacych zadań.

Pytania dla Was:

1. Czy macie jedno miejsce, w którym zebrane są wszystkie źródła wymagań dla pracy zespołu?
2. Czy Wasz backlog jest zrozumiały dla wszystkich zainteresowanych?
3. Czy zawsze na szczycie listy znajdują się rzeczy najważniejsze?
4. Czy na bieżąco pielęgnujecie backlog uwzględniając najświeższe informacji?
5. Czy wymagania na szczycie backlogu są GOTOWE?

6. Kiedy Wasz backlog działa najlepiej?
7. Co moglibyście zrobić, żeby częściej działał w ten sposób?

Co dalej?

Jutro przyjrzymy się bliżej historyjkom użytkownika, w czwartek omówimy Planning Poker – popularną metodę wymiany informacji ukrytą pod postacią metody szacowania, a w piątek zajmiemy się długofalowym planowaniem.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Jeśli zespół jest sercem Scrum a sprinty są rytmem, w jakim ono bije to elementy backlogu są krwią, którą to serce pompuje.

… a za Backlog w pełni odpowiedzialny jest Właściciel Produktu.

Jego rola jest najbardziej odpowiedzialną i zarazam najbardziej niedocenianą rolą w Scrum. Według współtwórcy Scrum Jeffa Sutherlanda, niskiej jakości backlog może łatwo doprowadzić do obcięcia tempa zespołu o połowę. Przyjmijmy oszczędnie, że mamy zespół, który kosztuje firmę coś w okolicach 50 tys. zł miesięcznie. Ile warto zainwestować, żeby upewnić się, że zespół pracuje nad tym, co rzeczywiście ma największe przełożenie na biznes? Ile nas będzie kosztowała walka ze źle podzielonym, niejasnym, nietrafnym backlogiem?  Zgodnie ze znaną zasadą Garbage In, Garbage Out nawet świetny zespół nie wyprodukuje nic wartościowego na bazie słabego backlogu. Dobry backlog to też podstawa pomiaru i adaptacji – musimy dobrze rozumieć co i po co budujemy, żeby móc skutecznie śledzić postępy i właściwie reagować na nowe informacje.

Scrum Guide
Definicja reguł Scrum – Scrum Guide – mówi, że: “Właściciel Produktu (ang. Product Owner) jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.” oraz “Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.” Dodaje też: “Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje.”.

Oznacza to, że PO musi łączyć głęboką wiedzę dziedzinową ze zrozumieniem technologii stosowanej przez zespół, by móc skutecznie wyjaśniać kontekst biznesowy pracy zespołu i zarazić członków zespołu empatią dla odbiorców systemu i entuzjazmem dla rozwiązania ich problemów. Jak podkreśla Scrum Guide musi też posiadać odpowiednią dozę autorytetu wobec innych jednostek w organizacji.

Wszystko to oznacza, że Właścicielem Produktu powinna być najwyżej postawioną osobą, która jest dostępna dla zespołu. W relacji Klient-Dostawca najlepiej, gdyby był nim ktoś po stronie Klienta. Stoi to jednak w sprzeczności z potrzebą zainwestowania dużej ilości czasu i energii w “inżynierię wymagań” przez regularną pielnęgnację formy i treści poszczególnych historyjek.

Dlatego tak ważne jest odpowiednie uformowanie relacji między PO a zespołem w taki sposób, by zespół mógł wesprzeć Właściciela Produktu w porządkowaniu backlogu z zachowaniem pełnej głębi jego biznesowej wizji.

Rola PO według Henrika Kniberga

Henrik Kniberg – znany Agile Coach ze Szwecji, obecnie pracujący w Spotify, nagrał ostatnio bardzo dobry filmik trafnie podsumowujący rolę PO.

Wybrane spostrzeżenia Henrika z jego prezentacji:

1. Głównym zadaniem PO jest określenie “Jaki problem powinniśmy rozwiązać i dla kogo?”.
2. Największym wyzwaniem jest zarządzanie oczekiwaniami odbiorców poprzez umiejętną selekcję pomysłów i życzeń umieszczanych w backlogu.
3. O ile misją PO jest maksymalizacja wartości pracy zespołu to wartość ta nie zawsze ma postać funkcjonalności dostarczanej klientom – często wartością jest wiedza pozwalająca zminimalizować ryzyko:
   • biznesowe (że produkt nie będzie naprawdę przydatny),
   • osobowe (że nasz zespół nie będzie w stanie zbudować produktu),
   • techniczne (że wybrana technologia nie sprosta wyzwaniu),
   • oraz budżetowo/harmonogoramowe (że nie zdążymy zbudować produktu na czas i poniesiemy dodatkowe koszty).

To tylko wybrane spostrzeżenia, cały filmik trwa tylko 15 minut i jest wart obejrzenia w całości:

[youtube http://www.youtube.com/watch?v=502ILHjX9EE]

Lean Startup

Marek Kirejczyk, współzałożyciel firmy Aenima i grupy Agile Warsaw nazwał go zaginionym podręcznikiem Product Ownera. Główną tezą Lean Startup (oraz wcześniejszej metodologii Customer Development, z której czerpie inspirację) jest, że tworząc nowy produkt naszym pierwszym zadaniem powinno być nie tyle zbudowanie jak największej liczby funkcjonalności, co raczej zweryfikowanie założeń biznesowych stojących za pomysłem na produkt.

W kontekście produktów na rynek masowy główne pytanie brzmi: Czy nasz model biznesowy jest powtarzalny i (opłacalnie) skalowalny? W kontekście projektów dla pojedyńczego odbiorcy pytanie sprowadza się do: Czy na pewno rozumiemy prawdziwe potrzeby Klienta?

Lean Startup dostarcza też narzędzi do poszukiwania odpowiedzi na te pytania. Wśród nich wyróżnia pętlę Build-Measure-Learn, czyli znaną pętlę tworzenia gotowego produtku po każdym sprincie rozbudowaną o rygorystyczny pomiar skuteczności produktu w osiąganiu założonych celów (przyciągania uwagi klientów, konwersji, utrzymania, …). Lean Startup nazywa wiedzę zdobytą w ten sposób wiedzą zweryfikowaną (Validated Learning) a wśród stosowanych miar wyróżnia tzw. Actionable Metrics, na podstawie których można podejmować trafne decyzje co do dalszych działań oraz Vanity Metrics, które służą co najwyżej do połechtania ego twórców.

Dowiedz się więcej na stronie ruchu Lean Startup.

Zadanie dla Was:

Dla Właściciela Produktu: Co jest najważniejsze dla naszych Klientów? Wypisz trzy najważniejsze wartości i omów je z zespołem – jak możecie dostarczyć jeszcze więcej tej wartości tym samym, albo mniejszym nakładem pracy?

Dla zespołu: Jak możecie pomóc PO przygotowywać lepszy backlog? Bardziej przejrzysty i zrozumialy? Pozwalający łatwiej śledzić postępy prac? Pozwalający szybciej dostarczyć realną wartość?

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Co chcesz wiedzieć o swoim projekcie?

W trakcie trwania projektu prawdopodobnie najważniejsze pytania to:

• Jak szybko nam idzie? Czy się wyrobimy na czas?
• Czy nasz produkt ma odpowiednią jakość?
• Czy to co budujemy jest rzeczywiście potrzebne?

Kiedy chcesz to wiedzieć?

• Jak najprędzej!

Dla naszych dzieci niedorzeczne będzie, że kiedyś zdarzało nam się czekać na koniec wielomiesięcznych projektów, żeby zweryfikować fundamentalne założenia na ich temat. Dlaczego ktokolwiek miałby na ślepo podążać ścieżką, nie wiedząc czy jest to ta właściwa? Dlaczego nie zawsze inwestujemy w wykrywanie i usuwanie błędów natychiast po ich powstaniu wiedząc, że koszt ich późniejszego usunięcia pnie się do góry z każdym upływającym dniem?

Niektóre projekty są wystarczająco przewidywalne, by nie przejmować się zbytnio koniecznością zmiany kierunku w trakcie ich trwania. Im więcej jednak w naszym projekcie ryzyka i niepewności tym bardziej potrzebujemy silnych mechanizmów pomiaru (obserwacji) i adaptacji do zdobytej w ten sposób wiedzy.

Twórca Scrum, Jeff Sutherland, jako były pilot wojskowy przytacza czasem analogię między Scrum a nowoczesnymi myśliwcami z systemem Fly-by-Wire. Przez lata inżynierowie lotniczy wyśrubowali osiągi swoich maszyn do tego stopnia, że bezpośrednie kontrolowanie samolotu przez pilota jest już niemożliwe. Przy prędkościach osiąganych przez te maszyny nawet najdrobniejsza turbulencja mogłaby spowodować całkowitą utratę kontroli. Nad stabilnością lotu musi czuwać komputer, który kilkaset razy na sekundę mierzy jego parametry i dopasowuje kierunek ciągu i ustawienie sterów.

Tak samo Scrum dostarcza szeregu mechanizmów pozwalających “w locie” korygować nasze plany. Trzy najważniejsze to:

1. Pod koniec każdego Sprintu musimy mieć gotowy kawałek funkcjonalności – jest to jedyna realna miara postępu.
   • Dzięki temu, że regularnie dostarczamy gotowe ulepszenia możemy zmierzyć (a nie jedynie oszacować) tempo pracy zespołu i szybko dowiedzieć się, czy jesteśmy na dobrej drodze do zakończenia projektu przed wyznaczona datą, czy już teraz powinniśmy kupować bilet do jakiegoś odległego zakątka ziemi, żeby uciec przed niezadowolonymi Klientami.
   • Możemy też szybko dostarczyć gotowy fragment i sprawdzić, czy to czego chciał Klient na początku projektu jest rzeczywiście tym, czego najbardziej potrzebuje.
2. Standupy (Codzienny Scrum) pozwalają zespołowi odświeżyć plan (Backlog) sprintu, odpowiednio wcześnie wykryć i usunąć problemy, które mogłby zagrozić realizacji celu sprintu a w ostateczności wcześnie zgłosić się do Właściciela Produktu celem renegocjacji zakresu prac.
3. Retrospekcja pod koniec każdego sprintu pomaga zespołowi przyjrzeć się szczegółom swojej własnej pracy, zidentyfikować ew. problemy i zaplanować ulepszenia.

Nawet jeśli nie stosujesz Scrum, zastanów się, jak mógłbyś skorzystać z pomiaru i adaptacji. Jakich problemów w swoim ostatnim projekcie mógłbyś uniknąć, gdybyś wiedział o nich odpowiednio wcześnie? Co mógłbyś zrobić (jeszcze) lepiej?

Ćwiczenie dla Was:

Sprawdźcie jakie korzyści przynosi dzielenie pracy na małe kawałki i domykanie zadań przed rozpoczęciem kolejnych przeprowadzając eksperyment z pakowaniem kopert.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Przyjrzyjmy się opowieści Agnieszki, nowej trenerki Fluid Circle, która wcześniej pracowała w CERN:

“Będąc członkiem zespołu programistycznego w CERN miałam okazję brać udział we wdrożeniu Scrum w mojej grupie. Wraz ze zmianą sposobu myślenia o naszym zespole (z fabryki na żywy organizm) pojawiło się wiele spontanicznych inicjatyw, prowadzących w naturalny sposób m.in. do większego zaangażowania naszych użytkowników.

W dawnym, fabrycznym modelu, po umieszczeniu nowej wersji aplikacji na serwerze do użytkowników automatycznie wysyłany był mail, który zazwyczaj bez czytania lądował w koszu. Po wdrożeniu Scrum, wyszliśmy z pomysłem: Jeśli w każdym Sprincie produkujemy gotową część systemu to dlaczego nie pochwalić się naszą pracą i nie zrobić demonstracji dla użytkowników?

Zaczęliśmy więc zapraszać wszystkich 100 użytkowników do dużej sali z rzutnikiem, gdzie na żywo demonstrowaliśmy nowe funkcjonalności w systemie. Często podczas takich demonstracji “klikali” i prowadzili nas za rękę użytkownicy. Pokazywane funkcjonalności musiały być więc w pełni wykończone.

Użytkownicy śmiało podpowiadali sobie jak klikać, pojawiały się spontaniczne komentarze i duch współpracy. Dało to całej grupie odwagę do tego żeby coraz więcej rozmawiać. Szybko okazało się, że to co użytkowników najbardziej blokuje, to często dla programistów 5min pracy, a zmiany nad którymi programiści siedzą czasem kilka dni dni dla użytkowników są nieważne i niewidoczne.

To danie użytkownikom szansy na zaangażowanie, wypowiedzenie się, obserwowanie jak pracują z systemem oszczędziło nam wiele dni pracy.”

Takie wyniki nie są odosobnionym przypadkiem. Procedury, zasady i inne formalne systemy są przydatne, ale podstawową metodą dojścia do porozumienia jest nadal bezpośrednia rozmowa! Jak mawiają anglosasi “All good things happen when people talk.”.

Rozpoczęcie rozmowy jest dużym krokiem do przodu, ale niestety nie jest to koniec problemów. Każdy z nas nosi ze sobą mnóstwo opowieści o problemach komunikacyjnych, nieporozumieniach, niepotrzebnych konfliktach.

Jednym z narzędzi, pomagających zdać sobie sprawę z poziomu naszej własnej wiedzy i wiedzy innych jest koncepcja Okien Johari. Wyróżnia ona cztery okna w zależności od stopnia percepcji rzeczywistości przez uczestników:

• Obszar świadomy (Open Arena): “Ja wiem, inni wiedzą”
• Obszar ukryty (Fasada): “Ja wiem, inni nie wiedzą”
• Ślepy punkt (Blind Spot): “Ja nie wiem, inni wiedzą”
• Obszar nieznany (Unknown). “Ja nie wiem, ani inni nie wiedzą”

Miarą jakości naszej relacji z Klientem jest rozmiar Areny. Im więcej rozmawiamy tym bardziej zwiększa się nasza świadomośc i redukuje Ślepy Punkt. Arena zwiększa się również kiedy to my udzielamy informacji zwrotnej – maleje wtedy Fasada.

Jak duże są w Twoim przypadku obszary ślepy i nieznany? Z modelem trudno się nie zgodzić, ale jak często w interakcjach z innymi aktywnie myślimy o tym, czego nie dostrzegamy? Jak często jesteśmy rzeczywiście otwarci na inny punkt widzenia, a jak często sprowadzamy rozmowę do oczekiwania na możliwość wypowiedzenia swoich, z góry założonych tez?

Zbyt często!

Zdrowa relacja powinna więc być oparta na obustronnym zaangażowaniu, czyli częstym otrzymywaniu i udzielaniu informacji zwrotnej. Jak mówi mój (Michała) osobisty bohater Stephen Covey: “Seek first to understand, then to be understood.” czyli najpierw zrozum rozmówcę, a następnie podziel się swoją opinią.

Ale to nie wszystko!

Główna część komunikacji to nie tylko słuchanie, ale i obserwacja. Antropolog Albert Mehrabian odkrył, że w procesie komunikacji interpersonalnej jedynie 7% informacji przekazują słowa, 38% – brzmienie głosu i aż 55% – zachowania niewerbalne. Prawdziwą sztuką jest wykorzystanie chwil kiedy dana osoba mówi nie tylko na słuchanie, ale na obserwację całej mowy ciała, gestykulacji, emocji. Według Coveya należy “słuchać oczami”. W takiej głębokiej rozmowie kryterium sukcesu nie jest dojście do przekonania, że rozumie się rozmówcę. Sukces odnosimy dopiero wtedy, gdy to rozmówca czuje się zrozumiany! Aby to osiągnąć warto własnymi słowami powtórzyć to co powiedział rozmówca.

Zadanie dla Was:

Skąd wiecie, czy Wasza praca ma rzeczywistą wartość dla Klienta? Kiedy ostatnio z nim (którymś z nich) rozmawialiście? Czy jesteście zadowoleni z jakości komunikacji wewnątrz zespołu? ze Scrum Masterem? z Product Ownerem? ze współpracownikami poza zespołem? z wyższym kierownictwem?

1. Przećwiczcie w zespole empatyczne słuchanie:
   • Jedna osoba opowiada krótką opowieść i/lub wypowiada opinię.
   • Rozmówca parafrazuje wypowiedź partnera.
   • Czy pierwsza osoba czuje się wysłuchana?
2. Przedyskutujcie w zespole jakie techniki efektywnej komunikacji znacie?
3. Czy te formy komunikacji są efektywne, dlaczego?
   • “Powiedz mi co o tym myślisz?”
   • “Jesteś słaby z SQL’a, prawda?”
   • “Czyja to wina?”
   • “Myślę, że Apple popełnił ostatnio wiele błędów; czyż nie?”

(Współautorzy: Michał Parkoła i Agnieszka Orlewicz)

Ten post jest częścią cyklu Pierwsze Dni Scrum.

W pierwszym odcinku skoncentrowaliśmy się na tym, jak duży wpływ na efektywność ma motywacja zespołu, wczoraj rozmawialiśmy o tym co o motywacji mówi współczesna nauka. Dzisiaj skoncentrujemy się na drugim krytycznym czynniku efektywności jakim jest właściwa organizacja pracy.

Współpraca dużych grup działających w złożonym środowisku zwykle charakteryzuje się dużą nieefektywnością. Problem ten dotyka nawet firmy doskonalące się od dziesięcioleci, takie jak Toyota, która jest źródłem nowego sposobu myślenia, na bazie którego powstał Scrum. Tam efektywność (rozumiana jako stosunek działań bezpośrednio tworzących wartość do wszystkich niezbędnych prac) wynosi około 50%. W wielu gorzej zorganizowanych firmach analiza efektywności (np. metodą Value Stream Mapping) daje wynik jednocyfrowy. Jest zatem dużo do ugrania.

Nie ma niestety uniwersalnego wzorca efektywnej organizacji, które można by bezrefleksyjne zaimplementować. Istnieje natomiast dużo dobrych praktyk, które warto wypróbować. Co najważniejsze: źródłem ulepszeń w sposobie zorganizowania bieżącej pracy jest w Scrum sam zespół, który w toku otwartej dyskusji jest w stanie najlepiej zidentyfikwać co go blokuje i co można ulepszyć. Ulepszenia narzucone z zewnątrz są w zasadzie z góry skazane na niepowodzenie.

Przyjrzyjmy się bliżej kilku przykładom, gdzie relatywnie łatwo udało się osiągnąć wyraźną poprawę efektywności:

Przykład 1: Sposób przydzielania zadań

Pozornie drobne poprawki w stosowanych metodach pozwalają czasem osiągnąć zaskakująco dużą poprawę. Weźmy przykład jednego z zespołów, któremu niedawno pomagaliśmy. W trakcie jednego z kolejnych sprintów członkowie zespołu postanowili nieco zmienić metodę planowania zadań. Zamiast z wyprzedzeniem rozdzielać prace między poszczególnych członków zespołu każdy brał kolejne zadanie dopiero po zakończeniu poprzedniego. W ten sposób wykorzystane zostały dwa mechanizmy: po pierwsze położony został większy nacisk na samo domykanie zadań według uzgodnionych kryteriów akceptacji a po drugie żmudne zadania były realizowane dużo szybciej, w nadziei na doczekanie się atrakcyjniejszych prac czekających niżej w kolejce. Ta drobna zmiana spowodowała w subiektywnej opinii Scrum Mastera tego zespołu potrojenie jego efektywności!

Przykład 2: Unikanie błędów

Błędów programistycznych nie da się całkowicie wyeliminować. Można natomiast minimalizować ich liczbę dzięki odpowiednim praktykom technicznym i organizacyjnym. Czy opłaca się w to inwestować? Czy nie lepiej oszczędzić czas na testach automatycznych, programowaniu w parach czy szczegółowych przeglądach kodu, skoro w tym czasie można zbudować dodatkową funkcjonalność?

Odpowiedź może zależeć od konkretnego przypadku, jednak warto poważnie zastanowić się nad tym pytaniem: błąd odkryty od razu można naprawić relatywnie tanio. Z kolej błąd odkryty po dostarczeniu funkcjonalności Klientom kosztuje dużo, dużo więcej, szczególnie jeśli między zakończeniem zadania a odkryciem uchybienia minęło więcej niż kilka dni.

Sprawdźmy w Twojej sytuacji:

Jak obsługa błędów wpływa na Waszą pracę?

W gronie zespołu odpowiedzcie na pytania:

1. Licząc w godzinach pracy, ile kosztuje Twój zespół naprawienie:
   • Błędu odkrytego natychmiast (np. przez automatyczny test lub partnera programującego z Tobą w parze)?
   • Błędu odkrytego przez kogoś innego przed dostarczeniem produktu?
   • Błędu w dostarczonej funkcjonalności?
2. Uwzględniając liczbę błędów, z którymi mieliście do czynienia przez ostatnie dwa miesiące: ile czasu warto byłoby zainwestować, żeby przenieść błędy z kategorii trzeciej do pierwszej?

Powyższe przykłady koncentrują się na ulepszeniach w pracy samego zespołu. Jeszcze większe korzyści można osiągnać eliminując marnotrawstwo na poziomie całej organizacji:

Przykład 3: Maksymalizuj ilość pracy nie wykonanej

Znowu przykład z życia: zespół od wielu miesięcy zmagał się z katalogiem setek zadań zebranych w systemie śledzenia ticketów. Czy każde z tych zadań niosło ze sobą aktualną wartość dla odbiorców systemu? Oczywiście nie! Gdy zespół zaczął opisywać zadania w formie historyjek użytkownika i wyraźnie odpowiadać na pytanie kto jest beneficjentem danej pracy i jakie korzyści rzeczywiście mu ta praca przynosi, okazało się, że dużą część zadań została po prostu odrzucona.

Od tego momementu zespół po każdym dwutygodniowym sprincie był gotowy dostarczyć kolejne ulepszenia dobrane pod kątem maksymalnej wartości. Ta priorytetyzacja nie wpłynęła bezpośrednio na liczbę zadań realizowanych przez zespół, ale sprawiła, że wartość wybranych zadań była wielokrotnie wyższa w porówaniu z sukcesywnym odhaczaniem zgłoszeń w trackerze. Dodatkowo fakt, że nagle zespół był w stanie sprint po sprincie zobaczyć wyniki swojej pracy w rękach zadowolonych klientów bardzo pozytywnie wpłynął na motywację i pośrednio wpłynął na wzrost także surowej produktywności.

Przykład 4: Dotarcie do Klienta

Kolejnym przykładem jest sytuacja, gdy zespół regularnie przygotowuje nowe funkcjonalności według wymagań Product Ownera, lecz o tych funkcjonalnościach niewiele wiedzą sprzedawcy, którzy bezpośrednio kontaktują się z Klientami. Ten mały szczegół może obniżyć wartość biznesową, skądinąd skutecznego zespołu praktycznie do zera.

Zadanie dla Was:

Kto jest głównym beneficjentem Waszej pracy? Co jest dla Waszych odbiorców najważniejsze? Co mógłbyś zrobić, żeby dostarczyć im jeszcze więcej tego, czego potrzebują?

1. Wypiszcie na tablicy beneficjentów czerpiących wartość z Waszej pracy.
2. Dla każdego z nich wypiszcie co najmniej jedną rzecz, która jest dla niego Ważna.
3. Jeśli to możliwe, sprawdźcie, czy dobrze rozumiecie ich potrzeby.
4. Czy rozumiejąc potrzeby odbiorców możecie coś zmienić, żeby dostarczyć więcej wartości, tym samym lub mniejszym wysiłkiem?

Zapraszamy do dyskusji w komentarzach i do zobaczenia jutro!

Podsumowanie:

1. Większość organizacji nie w pełni wykorzystuje swój potencjał.
2. Drobne zmiany mogą mieć zaskakująco duży wpływ na efektywność.
3. Pomysły i decyzje co do organizacji bieżącej pracy powinny pozostać w gestii zespołu. Rolą managerów jest natomiast ukształtowanie organizacji, by stworzyć dobre warunki dla efektywnego zespołu i zmakymalizować biznesową wartość jego pracy.
4. Koszt błędu gwałtownie rośnie wraz z czasem miedzy jego wprowadzeniem a usunięciem – często warto zainwestować w utrzymanie wysokiej jakości od początku niż zaciągnąć dług techniczny, od którego odsetki zabiją wszelkie bieżące oszczędności.
5. Klucz do efektywności często leży poza zespołem. Aby dostarczać więcej wartości końcowym odbiorcom musimy przyjrzeć się całemu łańcuchowi (lub sieci) wartości.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Wczoraj rozmawialiśmy o tym, skąd bierze się wzrost produktywności obserwowany przez organizacje, które z sukcesem zastosowały Scrum. Skoncentrowaliśmy się na jednym z głównych źródeł, jakim jest motywacja i zaangażowanie zespołu.

Wszyscy wiedzą, że dla chcącego nic trudnego, jednak wielu firmom zaskakująco trudno jest wyzwolić tą siłę w codziennej pracy. W zgiełku rozmów o wizjach, misjach, strategiach, premiach, nagrodach, Scrum, Agile i innych modnych tematach managerowie często zapominają, że w ostatecznym rozrachunku ludzie chcą być po prostu szczęśliwi.

Najczęściej stosowanym motywatorem są po prostu pieniądze. To fakt, że bez pieniędzy nie może być mowy o zdrowym środowisku pracy, jednak czy zawsze jest to najskuteczniejsza metoda? Tradycyjne podejście mówi, że tak. Chcemy, żeby ludzie bardziej się starali? Obiecajmy im się premię. Chcemy, żeby unikali błędów? Zagroźmy karą.

A co na temat motywacji mówi współczesna nauka? Daniel Pink w książce “Drive” wymienia najważniejsze czynniki wpływające na motywację pracowników umysłowych. Warto przeczytać, a jesli nie masz na to czasu to polecam tę świetną prezentacją video ilustrującą główne przesłanie książki.

Pink pisze, że w przypadku kreatywnej pracy umysłowej motywacja wewnętrzna jest praktycznie zawsze silniejsza niż zewnętrzna. W przytoczonych przez niego badaniach nagroda pieniężna nie sprzyjała lepszym wynikom w zadaniach o charakterze umysłowym, a jeśli była wystarczająco wysoka to wyniki były wręcz gorsze niż bez żadnej nagrody! No dobrze, skoro pieniądze nie wystarczą to na czym pownniśmy się koncentrować? Według “Drive”, motywacja wewnętrzna wyrasta przede wszystkim z trzech czynników:

1. autonomia – wszyscy lubimy mieć poczucie kontroli nad swoją pracą i swoim bezpośrednim otoczeniem. Czy jest coś bardziej demotywującego niż szef, który wszystko wie lepiej, szczegółowo określa co i jak wykonać nie zostawiając nam żadej swobody w organizacji własnej pracy? Pewnie jest, ale opisana sytuacja jest jednym z najczęściej przytaczanych demotywatorów.
2. kompetencja – prawdopodobnie nie znam Cię osobiście, ale założę się, że firma, w której pracujesz zatrudniła Cię dlatego, że posiadasz wiedzę i umiejętności, których nie mają inni. Jesteś kompetentny w swojej dziedzinie i jeśli czytasz ten artykuł to znaczy, że ciągle się rozwijasz. Zdrowe organizacje doceniają tą potrzebę i dopasowują się tak, by maksymalnie sprzyjać jej realizacji.
3. cel – co jest dla Ciebie bardziej motywujące: klepanie zadań, bo ktoś w firmie je zlecił czy tworzenie czegoś nowego, bo jest to wartościowe dla Twoich odbiorców? Odpowiedź wydaje się oczywista, lecz wciąż wiele organizacji nie stosuje tej zasady w praktyce.

Jak Scrum sprzyja motywacji?
Scrum sam w sobie nie gwarantuje wysokiej motywacji. Pomaga jednak wytworzyć środowisko sprzyjające jej wydobywaniu.

1. Wprowdzenie zasady samoorganizacji zespołów wokół wspólnych celów daje poczucie autonomii, w wyniku której zespoły biorą dużo większą odpowiedzialność za swoją pracę i dużo bardziej angażują się w jej pomyślne zakończenie.
2. Aktywna współpraca przy tworzeniu wymagających technicznie i wartościowych biznesowo produktów daje poczucie kompetencji, które zachęca do ciągłego doskonalenia własnych umiejętności, żeby móc pomóc zespołowi, dorównać innym lub wręcz wyrosnąć na merytorycznego lidera w wybranej dziedzinie.
3. Widok gotowych funkcjonalności, szybko i często dostarczanych w ręce oczekujących Klientów daje namacalne poczucie celu – pracując w ten sposób nie musimy czekać wiele miesięcy aż efekt naszych wysiłków ujrzy światło dzienne.

Zadanie dla Was:

A jaka jest sytuacja wokół Ciebie? Jak trzy wymienione źródła motywacji mają się do motywatorów, które odkryliście wczoraj?

Odpowiedzcie na te pytania całym zespołem:

Zbierzcie informacje o aktualnym stanie motywacji (jawnie lub tajnie). Niech każda osoba określi swój poziom zadowolenia w rozbiciu na źródła, w skali od 1 do 10, gdzie 1 oznacza poziom krytyczny a 10 doskonałe zadowolenie:

1. Autonomia – Czy mam wystarczająco dużo swobody w organizacji własnej pracy (w kontekście celów, metod i organizacji najbliższego otoczenia)?
2. Kompetencja – Czy w codziennej pracy mam okazję wykorzystać mój talent, wiedzę i umiejętności? Czy mam możliwość dalszego rozwoju w obszarach, które są dla mnie ważne?
3. Cel – Czy wiem, że moja praca jest wartościowa dla jej odbiorców? Czy cele organizacji są zbieżne z moimi (nie identyczne, ale kompatybilne)?
4. Ogólnie – Czy jestem zadowolony ze swojej aktualnej pracy (niezależnie od tego, gdzie się widzę docelowo)?

Zapraszamy do dyskusji i do zobaczenia jutro!

Podsumowanie:

1. Dla chcącego nic trudnego – dobra motywacja jest niezbędna dla wysokiej efektywności.
2. Motywacja wewnętrzna jest silniejsza niż zewnętrzna.
3. Motywacja wewnętrzna dla pracy umysłowej wyrasta z trzech czynników: poczucia autonomii, kompetencji i celu.

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Scrum jest coraz bardziej popularny. W konsekwencji wiele organizacji przykleja sobie etykietkę zwinnych bez głębszej refleksji i trudnych zmian, jakie są niezbędne by osiągnąć znaczny wzrost efektywności. Celem 30 Dni Scrum jest bliższe przyjrzenie się różnym jego aspektom i zilustrowanie ich głębszego znaczenia, by ułatwić Wam, drodzy czytelnicy, poprawne jego zastosowanie.

Scrum może przynieść wiele korzyści, ale jego głównym celem jest zwielokrotnienie efektywności zespołów tworzących złożone produkty. Zastosowanie Scrum można uznać za udane, jeśli co najmniej podwoi skuteczność Waszej pracy. Twórcy Scrum przytaczają zaś przypadki aż dziesięciokrotnego wzrostu efektywności.

Takie przechwałki brzmią nierealistycznie. Jest przecież wiele zespołów, które “zastosowały Scrum” i zaobserwowały co najwyżej inkrementalny wzrost produktywności. Skąd zatem może brać się tak radykalna poprawa?

W pewnym uproszczeniu są dwa główne źródła wzrostu efektywności w Scrum:

• po pierwsze Scrum pomaga wyzwolić motywację i kreatywność zespołów,
• po drugie Scrum dostarcza mechanizmy pozwalające systematycznie usuwać przeszkody spowalniające zespół i doskonalić wszystkie aspekty pracy.

Dzisiaj skoncentrujmy się na motywacji:

W rozumieniu wielu firm motywacja pracowników polega na przydzielaniu i odbieraniu premii za dobrą pracę. W firmach bardziej pozytywnie podchodzących do tematu można liczyć na firmowe ubezpieczenie medyczne lub kartę Multisport. Czy te metody rzeczywiście przekładają się na motywację? Każdy lubi dostać premię, ale inne tematy są dużo ważniejsze!

Weźmy przykład jednego z zespołów, z którym niedawno pracowaliśmy. Na początku współpracy przyglądaliśmy się podsumowaniu etapu prac. Kierownik zespołu po kolej przechodził przez listę zadań, którą mieli do wykonania i z całym zespołem omawiał, które się udało zakończyć, a które przechodzą na następny okres. Większość zadań miała charakter mniej lub bardziej techniczny. Każde z nich było w taki czy inny sposób uzasadnione, ale sądząc chociażby po tonie rozmów, żadne nie było dla zespołu ekscytującym wyzwaniem.

Przeskoczmy kilka miesięcy wprzód. Zespół zaczął stosować Scrum. Nie było już wyodrębnionego kierownika odpowiedzialnego za organizację pracy i podejmowanie decyzji. Był za to Właściciel Produktu, który miał dobierać zadania pod kątem maksymalnej wartości i dbać o to, żeby zespół był jej w pełni świadomy.

Na Planowaniu Sprintu uzgodniony został cel dodania do produktu możliwości śledzenia wykorzystania nowych funkcji, żeby móc ocenić ich rzeczywistą wartość dla użytkowników. Na początku stanęło na najprostszym możliwym rozwiązaniu – do bazy danych miała zostać dodana odpowiednia tabela, a do poszczególnych ekranów wywołania rejestrujące fakt ich otwarcia. Gdyby zespół trwał w trybie wykonywania zleconych zadań pracowdopodobnie na tym by się skończyło.

Jednak teraz sytuacja była inna – cel biznesowy został wyjaśniony, ale sposób jego osiągnięcia leżał ostatecznie w gestii zespołu. Dzięki temu niedługo po rozpoczęciu sprintu jeden z członków zespołu wpadł na zupełnie inny pomysł! Zauważył on, że aby osiągnąć podobny efekt wystarczy wykorzystać istniejące funkcje systemu, który służy do śledzenia efektywności kampanii reklamowych! Dzięki temu po pierwsze nie trzeba było za dużo kodować, a po drugie zyskiwało się dodatkową możliwość poinformowania użytkowników o nowych funkcjach za pomocą specjalnie dopasowanej kampanii. W porozumieniu z Właścicielem Produktu szybko zostały dopasowane kryteria akceptacji zadania i na Przeglądzie Sprintu, zespół mógł pochwalić się dostarczeniem większej wartości, mniejszym kosztem.

Wydarzenie to wyzwoliło w zespole niesamowitą dumę i poczucie osobistego zaangażowania w rozwój produktu, a Właścicielowi Produktu i przyglądającemu się całej sytuacji wyższemu kierownictwu dobitnie pokazało, że zgrany zespół nie potrzebuje nadzorcy, żeby efektywnie pracować.

Efekt ten można oczywiście pielęgnować także bez wykorzystania Scrum, lecz nie da się stosować Scrum bez niego!

O drugim źródle możliwego zwielokrotnienia efektywności porozmawiamy w jednym z kolejnych odcinków a tymczasem zadajmy sobie pytanie: Dlaczego nie wszystkim udaje się osiągnąć oczekiwane korzyści?

Najczęściej odpowiedź brzmi: bo nie są gotowi włożyć niezbędnego wysiłku!

W opisanym przykładzie wyzwaniem dla organizacji była zgoda na powierzenie odpowiedzialności zespołom traktowanym jako całość. Mimo wątpliwości decydenci postanowili zaufać doświadczeniom innych użytkowników Scrum, a obecnie mogą już obserwować pozytywne efekty w praktyce. Także sam zespół musiał umieć i chcieć przyjąć odpowiedzialność, którą gotowa mu była dać firma. Samoorganizacja nie gwarantuje prawdziwego zaangażowania; usuwa jedynie przeszkodę, która często je wyklucza.

Zadanie dla Was:

A jak to wygląda w Twoim zespole? Co sprawia, że robicie to co robicie? Kiedy praca sprawia Wam najwięcej satysfakcji? W jakich warunkach nie trzeba w żaden sposób Was “motywować”, bo sami robicie wszystko co konieczne, żeby odnieść sukces?

Odpowiedzcie na te pytania całym zespołem:

1. Wspólnie zróbcie listę, ważnych dla Was, źródeł motywacji (każdy może zgłosić swoje zapisując je po jednym na żółtych karteczkach i przyklejając karteczki do tablicy).
2. Połączcie ew. powtórzenia.
3. Przeprowadźcie głosowanie kropkowe, czyli niech każdy z Was ma dwie kropki, które może przypisać wybranym motywatorom (obie kropki dla jednego lub po jednej dla dwóch).
4. Dla najbardziej popularnego motywatora zastanówcie się, jak można by go wzmocnić w Waszej codziennej pracy?
5. Czego od Was wymaga to zadanie? Poszerzonej wiedzy? Nowych umiejętności? Samodyscypliny? Wytrwałości? Zaufania? Odwagi?

Podziel się swoją opowieścią w komentarzach i do zobaczenia w kolejnym odcinku!

Podsumowanie:

1. Scrum to metoda organizacji zespołowej pracy twórczej.
2. Celem Scrum jest zwielokrotnienie efektywności zespołów i organizacji.
3. Scrum osiąga to poprzez:
   1. wyzwolenie motywacji członków zespołu
   2. oraz systematyczne usuwanie przeszkód i innych źródeł marnotrawstwa.
4. Scrum jest nieskomplikowany, ale trudny – wymaga samodyscypliny, długofalowego wysiłku i odwagi zarówno od zespołu, jak i od osób odpowiedzialnych za całość organizacji.

Na świecie nie brakuje informacji o Scrum. Na osoby chcące go poznać czeka mnóstwo książek, serwisów internetowych, blogów i prezentacji. Dobrych informacji jest tak dużo, że czasem trudno jest odnaleźć to, co jest najbardziej potrzebne, by rozpocząć stosowanie Scrum we własnej organizacji. Z drugiej strony nawet doświadczone zespoły często pomijają kluczowe elementy niektórych praktyk i przez to zamykają sobie drogę do pełnego wykorzystania potencjału, jaki mógłby im dać Scrum.

By osiągnąć płynność w stosowaniu Scrum nie wystarczy umieć przejść przez wszystkie kroki w kontrolowanych warunkach. Niezbędne jest też zrozumienie zasad stojących za praktykami oraz nabycie nawyków, które pozwolą utrzymać wysoki poziom pracy także pod presją niecierpliwych Klientów, upływającego czasu i nieuniknionych problemów technicznych.

Właśnie dlatego powstał cykl “Pierwsze Dni Scrum”.

Przez 6 tygodni, poczynając od 7 stycznia,  krok po kroku przejdziemy przez wszystkie elementy Scrum. Każdego dnia tygodnia przedstawimy Wam porcję teorii, z życia wziętą opowieść ilustrującą dany temat oraz ćwiczenie pozwalające uczestniczącym zespołom przybliżyć się o krok do skutecznego wykorzystania Scrum.

Czego możesz się spodziewać po Pierwszych Dniach Scrum?
Po 6 tygodniach nie staniesz sie mistrzem, ale poznasz Scrum lepiej niż czytąjac pojedyńcze posty lub książki. Wyjmiesz jednak tylko tyle ile włożysz wysiłku w wypróbowanie ćwiczeń oraz systematyczne i odważne zastosowanie tych metod we własnej pracy.

Zapraszmy do udziału!

Ćwiczenie

Zwinne zespoły nie lubią czekać bezczynnie, dlatego już dzisiaj przygotowaliśmy dla Was pierwsze zadanie!

Jeśli jesteście zespołem, który dopiero poznaje Scrum, Waszym zadaniem jest uważnie przeczytać Scrum Guide – zwięzłą definicję całej metodyki stworzona przez twórców Scrum: Jeffa Sutherlanda i Kena Schwabera.

Jeśli już stosujecie Scrum, Waszym zadaniem jest ocenić swoją implementację pod kątem Scrum Checklist‘y przygotowanej przez znanego trenera i coach’a Agile – Henrika Kniberga.

Do pobrania

• Scrum Guide
• Scrum Checklist

Uwaga! Konkurs

Podziel się z nami opowieścią o doświadczeniach Twojego zespołu podczas 30 dni Scrum! Zespół, którego opowieść będzie najciekawsza otrzyma:

1. Specjalnie przygotowany warsztat dopasowany do indywidualnych potrzeb zespołu (w Waszej siedzibie, jeśli w Polsce) lub miesięczny program rozwoju Scrum Master’a/Agile Coach’a (4 sesje po 2h, w zależności od lokalizacji, na żywo lub zdalnie).
2. oraz możliwość zaprezentowania się na naszej stronie (w formie artykułu lub studium przypadku)

Do zobaczenia w styczniu!

Uaktualnienie 2012-12-30:  Polepszenie nagród w konkursie.