Iterate

Wdrażanie Scrum – planowanie pierwszego Sprintu

Podczas pierwszej iteracji postanowiliśmy nie wykorzystywać żadnego programu wspierającego pracę za pomocą Scrum. Korzystaliśmy z dwóch kolorów popularnych Sticky Notes, różnych dla User Stories i dla Tasków. Naszym zdaniem rozpoczęcie pracy w taki sposób pomaga szybciej przyswoić sobie metodę pracy z Task Board oraz zrozumieć jakie informacje przedstawiają wykresy spalania. Rozpoczęcie pracy zespołu nie posiadającego doświadczenia z Agile Software Development z wykorzystaniem narzędzi programowych prowadzić może do nadmiernego skupienia się na „wyklikiwaniu” efektu bez zrozumienia samego procesu.

Podczas pierwszej sesji Sprint Planning przeanalizowaliśmy z Product Ownerem przygotowane przez niego User Stories. Były one dobrze sformułowane i każda posiadała wartość biznesową. Drobnym problemem był jedynie fakt, że nie został określony ich priorytet, czy też ROI. Była to jednak pierwsza iteracja i wszyscy byli świadomi, że w czasie jej trwania będziemy się dopiero uczyć sposobu pracy. Postanowiliśmy wspólnie, na bieżąco, wybierać kolejne User Stories nad którymi zespół mógłby pracować w czasie pierwszego sprintu. Wzajemny szacunek pozwala na bezpośrednią komunikację a w konsekwencji możliwość szybkiego zapobiegania najróżniejszym problemom. Ze względu na brak znajomości Velocity zespołu oraz w celu przedstawienia całości procesu obie części spotkania przeprowadziliśmy przy udziale Product Ownera. Postanowiliśmy wykorzystać Commitment Based Planning, czyli wybór zadań do wykonania na podstawie wyczucia zespołu. Po omówieniu liczby User Stories większej od tej którą spodziewaliśmy się zrealizować i ich relatywnej estymacji w Story Points, przystąpiliśmy do identyfikowania zadań i ich estymacji czasowej. Po zakończeniu tego zadania, współpracując z Product Ownerem, zespół określił co udać mu się może zrealizować w czasie rozpoczynającego się sprintu. Podczas planowania konieczne było dokładniejsze omówienie estymacji relatywnej. Wątpliwości dotyczyły między innymi wartości dostępnych na kartach do Planning Pokera. Zaznaczyć trzeba, że Product Owner był świadomy tego, że wybór User Stories oparty jest jedynie o wyczucie zespołu który wcześniej ze sobą nie współpracował. Wiedzieliśmy, że dopiero pierwszy Sprint dostarczy rzeczywistej estymacji Velocity zespołu. W trakcie tego spotkania wykonywaliśmy wiele dodatkowych czynności, takich jak doprecyzowywanie User Stories i przypisywanie im priorytetów, omawianie aktywności, oraz omawianie aspektów technicznych istotnych w dalszej perspektywie. W efekcie spotkanie to trwało ponad 8 godzin. Z tego względu, po ustaleniu teminu kolejnych spotkań, oraz godziny Daily Scrum, zdecydowaliśmy że Task Board stworzymy w następnym dniu. Dodam jeszcze, że przyjęliśmy długość sprintu równą 2 tygodnie. Taka długość iteracji zapewnić miała wystarczająco krótki czas pomiędzy kolejnymi spotkaniami, aby skutecznie odpowiadać na zmiany w wymaganiach, oraz czas wystarczająco długi, aby zespół nie odczuwał ciągłej presji, która w dłuższym terminie może mieć na niego niekorzystny wpływ.

Następnego dnia, podczas tworzenia fizycznego Task Board, ustaliliśmy zasady jego aktualizacji. Uzgodniliśmy, że będziemy go aktualizować na bieżąco, a Scrum Master będzie odpowiedzialny za to, aby każdorazowo po Daily Scrum wyznaczać na wykresach spalania postęp w pracy. Po dokonaniu tych uzgodnień, przystąpić mogliśmy wreszcie do pierwszego Daily Scrum. W trakcie kilku pierwszych aktywności tego typu, niektórym członkom zespołu dzielenie się informacjami o tym co będą robić, a w dodatku czynienie tego w pozycji stojącej, wydawało się nienaturalne. W późniejszym terminie stało się to czymś w rodzaju odruchu bezwarunkowego i można było zauważyć oczekiwanie na zbliżający się Standup. Po zakończeniu pierwszego Daily Scrum rozpoczęły się prace projektowe

Wdrażanie Scrum – pierwszy Sprint

Poniższe punkty przedstawiają wybrane zagadnienia związane z pierwszą iteracją.

• Modyfikacja Sprint Backlog przez Product Ownera podczas trwania iteracji
  
  Pierwszego dnia iteracji odebraliśmy email od Product Ownera mówiący o konieczności dodania do Sprintu jeszcze jednej User Story ze względu na jej wysoki priorytet. W celu podjęcia decyzji co zrobić w tej sprawie, zwołaliśmy krótkie spotkanie zespołu, w czasie którego przedyskutowaliśmy negatywny wpływ modyfikacji Sprint Backlog w trakcie iteracji. Jego celem było przedstawienie możliwych sposobów reakcji na podobne zachowanie w przyszłości, oraz wspólne podjęcie decyzji. Postanowiliśmy, że Scrum Master napisze email do Product Ownera opisujący zasady Scrum dotyczące tego zagadnienia, czyli względną stabilność Sprint Backlog, sposób wprowadzania zmian, możliwość anulowania sprintu, itp. Treść wiadomości przedstawiać miała także przykłady negatywnego oddziaływania ewentualnej modyfikacji Backlogu, takie jak utrata skupienia zespołu na realizacji celów, przełączanie się pomiędzy pracą nad zadaniami i omawianiem nowej US, itp. Uzgodniliśmy także, że tym razem, wyjątkowo, dodamy tą User Story do Sprintu. Zapewne wiele osób krytycznie spojrzy na takie rozwiązanie, ale decyzja ta podyktowana była kilkoma powodami: był to pierwszy dzień Sprintu, nie znaliśmy Velocity zespołu, PO był świadom iż przyjęta zawartość Sprint Backlog oparta jest jedynie o wyczucie i zgadzał się z tym iż po zakończeniu Sprintu pewna część zadań może pozostać nie skończona. Efektem pierwszej iteracji miało być przede wszystkim wdrożenie się w technologię oraz nowy sposób pracy i estymacja Velocity zespołu. W kolejnych iteracjach nie przyjęlibyśmy już takiego rozwiązania. Zaznaczyć trzeba iż sam Product Owner zainteresowany był przyjęciem zasad Agile Software Development i był otwarty na sugestie zgodnych z nimi rozwiązań, co znacznie ułatwiało proces wdrażania Scrum. W kolejnych iteracjach, jego przekonanie do tego sposobu pracy wzmacniane było dalej m.in. widocznym postępem w pracach.


• Pozytywne i negatywne cechy wykorzystania tablicy jako Task Board w porównaniu z wykorzystaniem oprogramowania wspierającego pracę za pomocą Scrum.
  
  Cechy pozytywne:
  • Zespół nie posiadający doświadczenia w Scrum, poprzez wykorzystanie fizycznego Task Board, ma możliwość szybszego przyswojenia sobie tego procesu.
  • Fizyczny Task Board umożliwia zwiększenie stopnia zaangażowania całości zespołu podczas tworzenia, modyfikacji i priorytetyzacji zadań. Równoległy i nie moderowany dostęp do Task Board nie ogranicza inwencji zespołu. Żaden z członków zespołu nie posiada dodatkowej możliwości forsowania swoich pomysłów poprzez dostęp do klawiatury.
  • Wykorzystanie tablicy może także wpływać pozytywnie na ducha zespołowego. Jest ona miejscem gdzie zespół gromadzi się, dyskutuje i pracuje „ruchowo”.
  • Tablica nie wymaga wcześniejszego przygotowania odpowiedniej aplikacji wspierającej pracę za pomocą Scrum i charakteryzuje się mniejszą złożonością podstawowych czynności modyfikacji takiego Task Board. Nie jest konieczne logowania się, klikanie i przeciąganie.
  • Fizyczny Task Board ma także tą pozytywną cechę, że jest on stale dostępny. Stan Sprintu oraz zadań jest ciągle widoczny. Jest to szczególnie przydatne podczas Daily Scrum. Zespół może analizować i modyfikować zadania o których dyskutuje.
  
  Cechy negatywne:
  • Istotnym minusem wykorzystania tablicy jest jej ograniczona dostępność. Żaden z członków zespołu nie ma możliwości aktualizacji Task Board z innego miejsca niż pokój zespołu. Nie jest to więc dobre rozwiązanie w przypadku pracy zdalnej. Podobne ograniczenie dotyczy analizy stanu iteracji przez Product Ownera. Wykorzystanie wspomagających proces aplikacji webowych nie wprowadza takich ograniczeń.
  • W przypadku korzystania z ręcznie zapisywanych notatek bardzo przydaje się czytelne pismo oraz od czasu do czasu pewne zdolności rysunkowe. W przypadku nie posiadania takich zdolności pojawiać się mogą problemy z odczytaniem wcześniej zapisanych informacji.
  • Oparcie się o fizyczny Task Board utrudnia dostęp do informacji o przebiegu minionych iteracji, zrealizowanych już User Stories, itp.
  • Szczegółowa aktualizacja Task Board i wykresów spalania na tablicy jest też bardziej podatna na przeoczenia i błędy. Jednym z rozwiązań tego problemu może być aktualizacja Task Board jedynie podczas Daily Scrum. Efektem tego jest jednak fakt, że przez większą część dnia może on przedstawiać nieaktualne informacje, co może obniżyć efektywność zespołu. Rozważmy przypadek, gdy zadanie B łatwiej jest wykonać po ukończeniu zadania A, a standup odbywa się późnym rankiem. Jeśli zadanie A rozpoczęte jest przez pracującego wieczorem pana Sowę, to rozpoczynająca pracę rano, pani Poranny Ptaszek nie posiada informacji o tym czy zadanie A zostało już rozpoczęte a może nawet już ukończone. Może się tego dowiedzieć dopiero podczas Daily Scrum, przed którym w pracy pojawia się pan Sowa. W czasie poprzedzającym Standup, decyzja o rozpoczęciu pracy nad zadaniem B jest utrudniona . Z drugiej strony, aktualizacja Task Board na bieżąco wymaga każdorazowego notowania daty ukończenia zadania. Informacja ta umożliwia Scrum Masterowi przeliczenie liczby zrealizowanych punktów i pozostałego czasu zadań oraz aktualizację wykresów spalania. Niestety, proces ten jeszcze bardziej się komplikuje w przypadku pojawiania się nieprzewidzianych zadań, zmiany estymacji czasowej, czy też ponownego otwierania zamkniętych uprzednio zadań.
  • Nawet największa tablica udostępnia nam jedynie ograniczoną ilość powierzchni. Biorąc pod uwagę fakt, że wielkość zapisków odręcznych jest zdecydowanie większa od tekstu drukowanego, w pewnym momencie może nam na niej po prostu zabraknąć miejsca.
  
  Podsumowanie: Podczas projektu fizyczny Task Board wykorzystywaliśmy tylko podczas pierwszego Sprintu. Miało to przede wszystkim na celu szybkie przyswojenie sobie zasad Scrum, oraz zapewnienie dostępności wszystkich informacji podczas Daily Scrum. W trakcie kolejnych iteracji korzystaliśmy z aplikacji Jira z wtyczką Greenhopper. Rozwiązanie programowe umożliwia szczegółową analizę sprintu bez konieczności wykonywania dodatkowych zadań przez zespół i Scrum Mastera. Udostępnia ono także dodatkowe informacje, takie jak na przykład dokładność estymacji czasowej zadań. W dłuższej perspektywie odczuwalnym problemem był jedynie brak widoczności i możliwości aktualizacji Task Board w czasie standup. Dostęp do programu wymaga niestety, aby cały zespół nachylał się przy jednym komputerze. Rzutnik może być częściowym rozwiązaniem tego problemu. Jednak ze względu na ograniczoną rozdzielczość, modyfikację z użyciem myszki i klawiatury oraz brak możliwości wyświetlenia całości, programowy Task Board jest rozwiązaniem odpowiadającym wygodzie tablicy.


• Stopień wykorzystania przygotowanej wcześniej dokumentacji.
  
  Przed rozpoczęciem projektu stworzona została dokumentacja zawierająca opis funkcjonalny systemu i pewne aspekty techniczne, w tym kilka schematów UML. Podczas projektu okazało się jednak, że nie jest ona wcale wykorzystywana. Już przed pierwszą iteracją Product Owner zasygnalizował, że od czasu jej sporządzenia wizja projektu uległa pewnym zmianom i że nie będzie naciskał na jej wykorzystywanie. Jaką wartość miało więc stworzenie tego dokumentu? Zespół projektowy z niego nie korzystał. Proces tworzenia tej dokumentacji wpłynąć mógł jednak na zwiększenie poziomu świadomości klienta o produkcie jaki chce stworzyć. Wartość tego dokumentu zależała więc w zasadzie głównie od tego aspektu. Nie jest wykluczone, że wcześniejsze analizy wpłynęły na to, że podczas planowania iteracji Product Owner miał niektóre kwestie związane z funkcjonalnością aplikacji lepiej przemyślane, niż w przypadku, gdyby dokument ten nie powstał. Podsumowując, wartość tej dokumentacji trudno oszacować i zależy od tego ile pracy włożono w jej przygotowanie i na ile jej stworzenie pogłębiło wiedzę klienta o tworzonym produkcie.


• Połączenie roli Scrum Mastera z rolą członka zespołu
  
  Istnieją różne podejścia do implementacji roli Scrum Mastera. W przypadku tego projektu osoba pełniąca tę funkcję była jednocześnie członkiem zespołu projektowego. Rozwiązanie takie wymaga umiejętnego podziału swojego czasu pomiędzy pracę nad realizacją zadań oraz obowiązki wynikające z funkcji Scrum Mastera. Podział taki nie jest jednak łatwy w realizacji. Scrum Master powinien dbać o to, żeby opinia każdego członka zespołu była brana pod uwagę podczas dyskusji. Będąc jednak jednocześnie członkiem zespołu sam posiada on obowiązek dzielenia się swoimi pomysłami. Wymaga to pewnych umiejętności interpersonalnych i wyczucia. Dobrym podejściem jest przedstawianie swoich pomysłów w formie pytań i propozycji. Podobnie, podejmowanie przez Scrum Mastera zasadniczych decyzji dotyczących procesu powinno być poprzedzone ich omówieniem. W efekcie zespół powinien wspierać te zmiany. Najgorszym możliwym podejściem jest działanie argumentowane poprzez „tak, bo tak”, „tak i musicie się z tym pogodzić”, lub „tak bo ja tak mówię”. Taki sposób „przekazywania wiedzy” znacznie zmniejsza możliwość wykorzystania zalet metodyk zwinnych, takich jak samoorganizacja, poczucie odpowiedzialności za tworzony produkt, efektywna praca zespołowa i optymalizacja sposobu pracy. Scrum Master – członek zespołu musi pełnić rolę strażnika procesu oraz pomocnej dłoni zespołu nie narzucając jednocześnie swojej woli i biorąc udział w dyskusjach i pracy podobnie jak inni. Jednym z problemów jakie może on napotkać jest brak czasu na efektywne wykonywanie wszystkich tych czynności. Kolejnym problemem może być utrata pewnego przydatnego dystansu w czasie spotkań. Na przykład, podczas Daily Scrum pełnić on musi jednocześnie rolę członka zespołu rozmawiającego o bieżących problemach, synchronizacji pracy i planowaniu oraz zewnętrznego obserwatora, prowadzącego analizę współpracy i poszukującego potencjalnych problemów lub metod zwiększenia efektywności pracy zespołu. Temat wyzwań jakim czoła stawić musi osoba łącząca te dwie funkcje i jej preferowanych cech osobowych jest w całości osobnym zagadnieniem. Pełnienie roli Scrum Mastera i członka zespołu w umiejętny sposób zapewnia jednak dodatkową możliwość oddziaływania na zespół. Osoba taka może wpływać na zespół poprzez swój sposób pracy, stanowiąc przykład na różnych płaszczyznach. Dotyczy to sposobu komunikowania się z innymi członkami zespołu, sposobu wykorzystywania możliwości identyfikacji najlepszych rozwiązań w oparciu o dyskusję, otwartości na propozycje innych, sposobu programowania zgodnie z przyjętymi przez zespół standardami, czy tak prozaicznej sprawy jak aktualizacja Task Board. Taka implementacja roli Scrum Mastera zapewnia także możliwość poczynienia pewnych spostrzeżeń wynikających z obecności w samym sercu realizacji projektu, które rekompensować mogą po części utratę perspektywy.

Wdrażanie Scrum – zakończenie pierwszego Sprintu

Na ostatni dzień pierwszego sprintu zaplanowane mieliśmy dwa spotkania. Spotkanie Sprint Review z Product Ownerem, na którym mieliśmy zaprezentować zrealizowaną funkcjonalność oraz Sprint Retrospective służące analizie procesu i jego optymalizacji. Podczas Sprint Review przekazaliśmy Product Ownerowi, że nie udało nam się niestety ukończyć wszystkich User Stories, przyjętych do realizacji podczas pierwszego Sprint Planning. Możliwość taką sygnalizowaliśmy już w trakcie iteracji, w oparciu o obserwację naszego postępu, dzięki czemu fakt ten nie był dla Product Ownera zaskoczeniem. Przyjęte to zostało ze zrozumieniem, podobnie jak wcześniej z życzliwością przyjęto brak pełnego przygotowania User Stories przez Product Ownera, czy próbę zmiany Backlog podczas pierwszego sprintu. Wzajemny szacunek jest kluczem do dobrej współpracy. Większość zadań udało się jednak zrealizować, dzięki czemu po dwóch tygodniach od rozpoczęcia prac Product Owner mógł wypróbować rzeczywistą aplikację, z czego, wydaje się, był zadowolony. Umożliwiło mu to skonfrontowanie wcześniejszych założeń z rzeczywistością i dostosowanie projektu do dostrzeżonych zmian w wymaganiach. Podczas spotkania Sprint Review omawiane było wiele kwestii. W efekcie trwało ono dość długo i skończyło się późno. Co więcej, wcześniej zespół intensywnie pracował nad realizacją zadań praktycznie do samego spotkania. Z tego względu, co niektórzy mogą uznać za naganne, postanowiliśmy tym razem zrezygnować ze spotkania Sprint Retrospective. Wiele kwestii udało nam się na szczęście rozwiązywać od ręki podczas iteracji. Pamiętać też trzeba, że wprowadzanie zbyt wielu zmian jednocześnie okazać się może czasem bardziej szkodliwe niż tymczasowe odstępstwo od zasad. Przypomnę, że z początku dla członków zespołu dziwnym było rozmawianie na temat bieżącej pracy podczas Daily Scrum. Spotkanie Sprint Retrospective po męczącym dniu kończącym ich pierwszy Sprint nie przyniosło by zapewne wielu przyczynków do optymalizacji sposobu pracy. Co więcej, okazało się, że pomimo wcześniejszych zapewnień o wspieraniu nowego podejścia przez zarząd, w trakcie pierwszych iteracji zauważyć można było pewną dozę sceptycyzmu względem niektórych zasad i praktyk. Dotyczyło to na przykład Daily Scrum, Retrospective, oraz emergent/pull-driven architecture i samoorganizacji zespołu. Zgodnie z twierdzeniem Kena Schwabera „a dead Scrum Master is a useless Scrum Master”, postanowiliśmy więc wdrażać proces stopniowo. Zmniejsza to prawdopodobieństwo pojawienia się zdecydowanego oporu, który jest charakterystycznym zjawiskiem w przypadku wprowadzania zbyt wielu zmian jednocześnie. Ustaliliśmy więc, że następnym razem termin Sprint Retrospective poprzedzać będzie Sprint Review, dzięki czemu spotkanie odbyło się i omówiono kilka spraw które należało rozwiązać. Po zakończeniu sprintu dysponowaliśmy już znacznie większą wiedzą na temat technologii i architektury aplikacji, co pozwalało nam na dokładniejszą estymację zadań. Zespół zdobył także sporo praktycznej wiedzy dotyczącej pracy za pomocą Scrum. Poznaliśmy też pierwszą estymację Velocity zespołu. W kolejnych iteracjach, zaufanie zarządu do zespołu i przekonanie do wykorzystywanego procesu zwiększało się co pozwalało zespołowi na zwiększanie stopnia wykorzystania zalet Agile Software Development.