5 przestróg dla początkującego zespołu scrumowego

Zespół, który rozpoczyna pracę Scrumem, może łatwo wpaść w pierwszych sprintach w typowe pułapki i zepsuć sobie efekty wykorzystania metody, zupełnie nieświadomie. Oto moja subiektywna lista przestróg, która powstała w trakcie wsparcia kolejnego zespołu zaczynającego swoją przygodę ze Scrumem u jednego z moich klientów.

  1. Nie rezygnuj ze Sprint Review choćby nie wiem co – „Mamy słaby rezultat sprintu (albo nie udało się zrealizować niczego), odwołajmy Sprint Review”, „Interesariuszy zaprosimy jak już się nauczymy Scruma” – pomysły tego typu padają, gdy zespół nie ma pewności albo śmiałości. Część nauki, jaką przebyć musi każdy zespół scrumowy, jest pokonanie obaw o to, jak interesariusze odbiorą rezultaty pracy zespołu i jak zareaguje na gorsze momentu. Naturalnym zjawiskiem jest to, że początkujący zespół scrumowy może źle ocenić swoje moce przerobowe, a jednoznaczne DoD okaże się większym wyzwaniem, niż ktokolwiek pomyślał startując sprint. I tak, i tak trzeba podsumować sprint w momencie, w którym na początku planowaliśmy i zebrać owoce, porozmawiać o dalszych planach, zacząć przejrzyste informowanie o prawdziwych postępach.
  2. Nie rezygnuj z Retrospektywy Sprintu, choćby nie wiem co – „Czeka nas trudna rozmowa na Retrospektywie, nie róbmy jej” – tego to akurat początkujący zespół na pewno nie powie głośno, ale gdy ktokolwiek w zespole wpadnie na pomysł odwołania „retro„, zdarza się że wszyscy błyskawicznie temu przyklasną. Czasem chodzi o brak otwartości w zespole (co przy startującej grupie ludzi jest naturalne), czasem o brak pewności, jak takie retro zorganizować i jak to będzie przebiegać. Przyczyną niechęci do przemyślenia usprawnień może też być panująca w organizacji krótkowzroczna presja na produktywne parcie z pracami do przodu za wszelką cenę i unikanie marnowania czasu na jakieś niepotrzebne spotkania. A czasem wszyscy przez skórę czują, że jest o czym gadać i że na najwyższa pora mierzyć się z niedoskonałościami procesu i problemami komunikacyjnymi, czego nikt nigdy do tej pory w firmie nie mówił, wygodniej było udawać że się tematu oficjalnie nie widzi. Potrzeba odwagi, przypomnienia sobie głośno po co chcemy się usprawniać, na jakich zasadach rozmawiamy o usprawnieniach i odważnego do poprowadzenia pierwszej sesji retrospektywnej.
  3. Dąż do uzyskania działającego produktu na koniec każdego sprintu – „Bardzo trudno uzyskać przyrost na koniec sprintu, zróbmy półprodukty albo analizę” – jeśli zespół powstaje na bazie waterfalla (albo water-scrum-falla) albo w firmie funkcjonował kult bycia zajętym (znane pod hasłem 100% utylizacja zasobów), naturalnym odruchem może być chęć kontynuowania w sprintach dotychczasowych stylów funkcjonowania – analityk analizuje, programista koduje, tester testuje – wszyscy zajęci, kompletnie niezsynchronizowani, a na końcu sprintu nie ma niczego gotowego (albo pokazane są efekty sprzed wielu miesięcy, które wreszcie tester skończył testować). Częścią różnicy, jaką robi Scrum jest to, że zespół bierze mniej pracy zrównoleglonej, ale dzięki intensywnej współpracy to, co zostanie podjęte, jest najczęściej zrealizowane wcześniej i lepiej. Co sprint można wdrożyć produkt, który został wytworzony, skorygować kurs, jeśli jakieś wymagania zostały źle zrozumiane albo realia rynkowe się zmieniły, co sprint można też kompletnie przebudować priorytety bez straty dla firmy w postaci zapasu częściowo wytworzonego rozwiązania.
  4. Wciągnij w usprawnianie cały zespół i otoczenie wokół zespołu – Jeśli już uda się przezwyciężyć strach przed wprowadzeniem retrospektywy, następnym popularnym poziomem problemu może być obawa przed koniecznością usprawniania codzienności zespołu i świata wokół niego. Wszyscy wiemy, że potrzebujemy zmian, żeby pracować lepiej, ale bezpieczniej będzie utrzymać status quo. Czasem będzie to wynikało z jakichś zaszłości (np. wspomnienie nieudanych prób zmiany rzeczywistości w przeszłości), czasem z braku świadomości, że można inaczej – niektórzy nie znając innego świata niż w danej firmie nie mają nawet wyobraźni, żeby sobie wymarzyć lepszy świat. Długofalową korzyścią Scruma jest zainicjowanie procesu ciągłego usprawniania się całej firmy, na bazie konkretnych wniosków z pracy konkretnych zespołów, które potrzebują konkretnych zmian, by pracować lepiej (szybciej dostarczać rozwiązania lepszej jakości i wyższej wartości).
  5. Stosuj metodę w całości, taką jaką ona jest – popularny odruch u początkujących zespołów „Mamy trudność z jakimś elementem frameworka, pomińmy go albo zróbmy hybrydę” (brak Codziennego Scruma, brak Backlogu Produktu, brak wyznaczenia Scrum Mastera). Warto sobie zdać sprawę, że metody, takie jak Scrum, funkcjonują już od lat – Scrum podlega ewolucji i naprawdę zawiera wszystkie potrzebne elementy i nie zawiera żadnego, który dla początkującego zespołu jest zbędny. Oczywiście na początkowym etapie będziemy popełniać błędy, niektóre próby będą z perspektywy czasu pociesznie nieudane, ale w szczególności nie próbujmy omijać wszystkiego co nam sprawia trudność. Jak w tej anegdocie o początkującym kierowcy, który ponieważ boi się skręcania na skrzyżowaniach w lewo, zawsze stara się dobrać trasę tak, że by skręcać tylko w prawo (nawet, jeśli pojedzie bardzo okrężną drogą). I podobnie jak w prawdziwym życiu – gdy już będziemy naprawdę zaawansowani, może się okazać, że coś w tym jest w tych odruchach chęci zmiany metody, ale na razie zbyt wcześnie, żeby zdawać sobie z tego sprawę i podjąć świadomą decyzję o sposobie, w jaki pracujemy.

Źródło zdjęcia: Andreas Levers „Slippery slope” https://flic.kr/p/6Pf16K na licencji CC BY-NC 2.0

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x