W poprzednim poście skoncentrowałam się na tym, jakie korzyści zespół może uzyskać z Daily oraz na ile ta wiedza jest współdzielona w zespole. Tym razem opiszę, jak sposób realizacji Daily wpływa na zespół – innymi słowy czego nie należy robić, jeśli chcemy, żeby zespół był odpowiedzialny i zaangażowany.
Autonomia jest niezbędna do tego, aby rozwijać bardziej wewnętrzną motywację, czyli żeby członkowie zespołu pracowali dlatego, że widzą sens w tym, co robią. Odwrotnością tego jest motywacja zewnętrzna, kiedy ludzie pracują dlatego, że muszą (w celu uniknięcia negatywnych konsekwencji) lub dla uzyskania korzyści. Dzisiejszy artykuł poświęcam autonomii, następny będzie właśnie o wewnętrznej i zewnętrznej motywacji.
Sprawdziłam korelację pomiędzy deklarowaną autonomią a korzyścią z Daily, jaką członkowie zespołu uważają za najważniejszą (dokładny opis tego, co i jak było badane jest tutaj). Wynik jest istotny statystycznie (tau Kendalla = 0,17; p < 0,05; N = 88), co oznacza, że istnieje powiązanie pomiędzy tym, jak ludzie spostrzegają swoją autonomię a tym, jakie widzą korzyści z Daily. Przy korelacji nie wiemy, co jest przyczyną, a co skutkiem. Może być tak, że ktoś, kto lepiej rozumie cel Daily, odczuwa większą autonomię, jak i tak, że ktoś, kto czuje się bardziej autonomiczny, ma też większą świadomość, jakie korzyści może mu przynieść Daily.
Moje doświadczenie pokazuje, że kiedy pracujemy nad podstawami Scruma, jakość Daily mocno wpływa na postrzeganą autonomię. Później, kiedy członkowie Zespołu już poczują, czym Daily może być, Deweloperom zależy na tym, żeby się dobrze synchronizować. Samoorganizacja wymaga wymiany informacji i sprawnego uzgadniania, a w zamian daje dużą swobodę w sposobie realizacji zadań, co zwrotnie przekłada się na większą doświadczaną autonomię.
Aby sprawdzić, jak wygląda wyżej opisana korelacja porównałam, jak oceniały swoją autonomię osoby, które widziały korzyści z Daily na konkretnym poziomie. Poniższy wykres przedstawia wyniki.
Porównując kolejne słupki, możemy zaobserwować zależność – deklarowana autonomia rośnie wraz ze wzrostem spostrzeganej wartości Daily. „Status” zdaje się być mało wartościowym sposobem prowadzenia tego spotkania, jednak nie odbija się w widoczny sposób na autonomii. Aby to uwzględnić policzyłam ponownie korelację pomiędzy średnią autonomią a korzyścią z Daily dla innych odpowiedzi niż “Status”. Współczynnik korelacji tym razem jest dosyć wysoki jak na nauki społeczne (tau Kendalla = 0,28; p < 0,01; N = 60), co pokazuje siłę omawianej zależności. Na wykresie widzimy, że obniżenie doświadczanej autonomii następuje dla Daily, którego główna korzyść to mówienie, co będzie robione w ciągu najbliższych 24 godzin. Może to być związane z lękiem przed byciem rozliczanym z tego, do czego się ktoś zobowiązał. Taka sytuacja często występuje w zespołach, w których na Daily są inni ludzie niż Zespół Deweloperski. Rozumienie Daily jako zdarzenia służącego rozwiązywaniu problemów jest na podobnym poziomie, co “Status”. Dopiero przejście na „jasną stronę mocy” i traktowanie Daily jako czasu na synchronizację i zastanawianie się przez Zespół, jak osiągnąć cel Sprintu, powoduje silniejszy wzrost spostrzeganej autonomii.
Z moich obserwacji wynika, że aby zespół mógł się czuć autonomiczny, jest niezbędne, żeby nie zachodziły na Daily pewne negatywne wzorce dotyczące współpracy z Właścicielem Produktu. W starym Scrum Guide było zdanie „Scrum Master egzekwuje zasadę, że tylko Zespół Deweloperski bierze udział w Codziennym Scrumie”. Zostało ono w najnowszym zamienione na „Codzienny Scrum jest wewnętrznym spotkaniem Zespołu Deweloperskiego. Jeśli inne osoby
są obecne, Scrum Master upewnia się, że nie zaburzają one jego przebiegu.”. Po raz pierwszy zdarzyło się, że nie zgadzam się ze zmianą wprowadzoną w Przewodniku po Scrumie. Dlaczego? Moim zdaniem prowadzi to do sytuacji, kiedy potrzeba kontrolowania okazała się silniejsza niż (dużo trudniejsze) budowani zaufania. Wielokrotnie spotykałam się z tym, że osoby, nawet dobrze znające Scruma, nie widziały, jakie są konsekwencje obecności Właściciela Produktu na Daily.
Wyobraźmy sobie sytuację idealną. Daily jest spotkaniem kompetentnych, odpowiedzialnych specjalistów, którzy w ciągu 15 minut mają zsynchronizować swoją pracę na najbliższy dzień, koncentrując się na tym, co jest celem sprintu. To właśnie Zespół Deweloperski odpowiada za wszystkie podejmowane przez siebie decyzje, wykorzystuje swoją wiedzę i doświadczenie, aby dostarczyć jak najlepszy Przyrost. Robi to zgodnie z ustalonymi wymaganiami, konsultując się z Właścicielem Produktu wszędzie tam, gdzie może to mieć wpływ na funkcjonalność biznesową produktu. Jednak za jakość, wydajność, bezpieczeństwo, architekturę i sposób wytworzenia oraz przetestowania odpowiada Zespół Deweloperski. Oczywiście uwzględnia ogólne wymagania (klienta, standardów firmowych, danego produktu) oraz szczegółowe założenia do każdego elementu w Backlogu.
Każda interwencja polegająca na odbieraniu Deweloperom prawa decydowania o tym, jak tworzyć Przyrost, będzie skutkowała obniżeniem ich zaangażowania, proaktywności i przyjemności z pracy. Nie da się kogoś kontrolować, ograniczać jego roli do “wyrobnika” wypełniającego czyjeś polecenia i jednocześnie oczekiwać, że ten ktoś będzie innowacyjny, przewidujący, związany z produktem i pełen zapału. Znaczy – da się oczekiwać, ale jest to kompletnie absurdalne i skazane na niepowodzenie.
Najczęściej jest tak, że to Właściciel Produktu chce uczestniczyć w tym spotkaniu. Powodem może być brak zaufania lub potrzeba kontroli. NIE ma sytuacji, kiedy obecność Właściciela Produktu byłaby konieczna na Daily. Jeśli zespół ma problem albo pytanie, to powinien z Właścicielem Produktu rozmawiać na bieżąco, a nie czekać do Daily. Jeśli Właściciel Produktu chce wiedzieć, jak postępują prace, to konieczna jest dobra wizualizacja tego, co dzieje się w Sprincie. W ćwiczeniu opisuję, jak można pracować nad budowaniem zaufania.
Często spotykałam się z sytuacją, że Daily było marnowane na dyskusje z Właścicielem Produktu. W efekcie nie następowała synchronizacja i ustalenie “planu gry”, tylko zaspokajane były potrzeby jednej osoby kosztem potrzeb Zespołu. Dobrym czasem na ustalenia z Właścicielem Produktu jest czas po Daily, może wtedy nastąpić replanowanie w gronie zainteresowanych osób. Oczywiście jestem jak najbardziej za tym, żeby dużo i często rozmawiać z Właścicielem Produktu, ale akurat te 15 minut służy innemu celowi – uzgodnieniu, co i jak trzeba zrobić, aby osiągnąć cel sprintu. Przypomnę, za Scrum Guidem, że “[Zespoły Deweloperskie] są samoorganizujące się. Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty gotowej do potencjalnego wydania funkcjonalności”.
Może być też tak, że to Zespół Deweloperski chce, żeby Właściciel Produktu był obecny na Daily. Najczęściej tak się dzieje, kiedy tylko on (albo ona) może podejmować decyzję dotyczące sposobu wytwarzania Przyrostu. Jednak jest to rodzaj pułapki – mniejsza odpowiedzialność (w zakresie podejmowania decyzji) to również mniejsze poczucie właścicielstwa (bo my tu tylko kodujemy, co nam każą). Powoduje to zmniejszanie spostrzeganej autonomii, a co za tym idzie również wewnętrznej motywacji.
Warto zaznaczyć, że wśród pytań, które składały się na skalę autonomii dwa stwierdzenia korelowały (na poziomie tendencji statystycznej) ze spostrzeganą korzyścią z Daily. Wskazują one na konkretne dysfunkcje Zespołu. Pierwsze to “Zwykle po prostu podporządkowuję się narzuconym mi obowiązkom.”, które wskazuje na brak samoorganizacji, natomiast drugie to “Pracuję w sposób odgórnie zaplanowany.”, które pokazuje mikrozarządzanie albo nadmierne planowanie. Należy zwrócić uwagę, że osoby, które odpowiadały “Zdecydowanie nie” i “Raczej nie” były tymi, które lepiej rozumiały, jakie korzyści Daily może przynieść Zespołowi i które pracowały z bardziej wewnętrznych pobudek oraz (oczywiście) czuły się bardziej autonomiczne.
Podsumowując – Daily odbywa się codziennie, więc, mimo że jest krótkie, ma duży wpływ na to, jak zespół spostrzega swoją sytuację i jak rozumie odpowiedzialność, jaka na nim spoczywa. Dlatego tak ważne jest, żeby właśnie to spotkanie odbywało się zgodnie z jego ideą, podkreślało samodzielność i kompetencję Zespołu Deweloperskiego. Jest to coś, o co musi walczyć każdy Scrum Master.
Oczywiście, zapewne nadal będą osoby, które zbagatelizują problem i będą uważały, że szkoda spowodowana przez obecność innych osób niż Zespół Deweloperski (i ewentualnie Scrum Master) na Daily jest pomijalna. Myślę jednak, że wiele osób zrozumie, jak ważna jest praca z zespołem w kierunku brania przez nich odpowiedzialności za dostarczany Przyrost, a pierwszym krokiem do tego jest właśnie samoorganizacja zespołu w czasie Daily.
W Scrumie bardzo ważne jest eksperymentowanie, dlatego, jeśli do tej pory Właściciel Produktu zawsze był obecny na Daily, to proponuję zrobić trzymiesięczny eksperyment, polegający na tym, że nie będzie na nie przychodził. Dzięki temu i on i Zespół nauczą się nowego sposobu współpracy, a po tym czasie będą mogli podjąć świadomą decyzję, czy wracają do poprzedniego modelu.
Budowanie zaufania z PO
Cel ćwiczenia:
- Ustalenie jakich informacji potrzebuje Właściciel Produktu, aby komfortowo pracować nad rozwojem produktu
- Ustalenie, jakich informacji potrzebuje Zespół Deweloperski, aby autonomicznie tworzyć Przyrost
- Popatrzenie na cykl życia elementu Backlogu pod kątem przepływających informacji
- Ustalenie, skąd te informacje się biorą i jak są porządkowane i wizualizowane
- Sprawdzenie, czy można coś zmienić, aby mieć większą swobodę pracy
Będą potrzebne:
- Kilka kartek
- Coś do pisania
- Dwa albo trzy stoły zestawione krótszymi bokami
- Taśma klejąca albo coś czym można podzielić stoły na trzy części
Na co zwrócić uwagę?
W tym ćwiczeniu dobrze jest patrzeć na cykl życia elementów Backlogu z perspektywy ról (Właściciela Produktu, Dewelopera). Ułatwia to oderwanie się od bieżącego sposobu pracy i poszukanie nowych, lepszych rozwiązań.
Ćwiczenie to służy zrozumieniu przez wszystkich członków Zespołu Scrumowego, że autonomia i samoorganizacja jest zawsze oparta o wiarygodne i aktualne informacje. Bez tego Właściciel Produktu nie jest w stanie planować pracy i wykonywać swoich zadań biznesowych, a Zespół Deweloperski wytwarzać Przyrostu. Proces budowania zaufania wymaga dłuższego czasu, ale może się zacząć dopiero wtedy, kiedy rozumiemy, czego druga strona potrzebuje i świadomie decydujemy się jej to dostarczyć. Trudno jest dawać długi kredyt zaufania, dlatego przy nadwyrężonych relacjach pomiędzy Właścicielem Produktu a Zespołem, nie można tego wymagać i należy ustalić takie sposoby monitorowania, które zapewnią wszystkim względne poczucie bezpieczeństwa. Ważne tu jest właśnie monitorowanie, a nie kontrolowanie. Na przykładzie wyjaśnię, czym to się różni. Jeśli Właściciel Produktu do tej pory był na Daily, żeby sprawdzić, czy “Zespół odpowiednio pracuje”, to od tej pory przestaje przychodzić na nie i daje tym samym Zespołowi możliwość samoorganizowania się i samodzielnego ustalania, jak chcą tworzyć Przyrost. Może za to przyjść po Daily, obejrzeć tablicę zespołu, odpowiedzieć na pytania, jakie się pojawiły w czasie Daily. Będzie w ten sposób wiedział, jak wygląda stan prac, a jednocześnie będzie zachęcał Zespół do przejmowania odpowiedzialności za Przyrost. W tym ćwiczeniu dążymy właśnie do tego typu rozwiązań.
Sposób wykonania:
W czasie ćwiczenia Zespół Scrumowy będzie symulował przejście przez cykl życia jakiejś funkcjonalności od idei do wdrożonego rozwiązania. Na początku ustalamy, że z lewej strony zestawionych stołów rozpoczyna się cykl życia elementu Backlogu, a z prawej kończy (droga przez stoły jest odpowiednikiem upływającego czasu). Następnie dzielimy stoły na trzy części (np. taśmą), które oznaczają kolejne etapy życia elementu Backlogu – czas do Planowania, Sprint i czas po Przeglądzie Sprintu. Kartki, symbolizujące najpierw element Backlogu, a potem wytworzoną funkcjonalność, będą przez cały Zespół przesuwane od lewej do prawej i uzupełniane o kolejne informacje.
Na początku Właściciel Produktu opowiada o tym, skąd się biorą elementy Backlogu – kto z nimi przychodzi, kto dostarcza mu jakich informacji. Najlepiej, żeby wybrał maksymalnie trzy typowe elementy Backlogu i do nich się odnosił. Często warto uwzględnić wśród nich zgłoszenie o błędzie. Należy przygotować tyle kartek, ile będzie omawianych elementów. Proponuję najpierw przejść cały cykl z jednym elementem, dopiero potem z kolejnym. Dzięki temu Zespół będzie wiedział na czym polega ćwiczenie i będzie mógł się skupić na metapoziomie (sposobie pracy), a nie na konkretnym elemencie.
Typowy początek życia elementu Backlogu wygląda tak, że Właściciel Produktu gromadzi pewne informacje, zanim Zespół rozpocznie doprecyzowywanie wymagań i estymowanie. Po tym, jak Właściciel Produktu stworzy i opisze elementy Backlogu, należy ustalić, jakie informacje są mu potrzebne do podejmowania decyzji albo rozmawiania z interesariuszami.
Teraz czas na pracę całego Zespołu. Na początek należy doprecyzować, jakich informacji potrzebują, aby uszczegółowić ten element Backlogu. Następnie Zespół Scrumowy powinien opowiedzieć o tym, jak zdobywa te informacje i w jaki sposób je gromadzi. To jest dobry moment, żeby sprawdzić, czy czegoś w tym procesie nie można ulepszyć. Najczęściej jest to praca wieloetapowa – wstępna, bardzo zgrubna estymata, gromadzenie wymagań biznesowych i technicznych, szacowanie wartości, zmienianie priorytetów, definiowanie kryteriów akceptacji, rozbijanie na mniejsze zadania. Zespół Deweloperski wraz z Właścicielem Produktu powinien zapisywać na kartce gromadzone informacje. Jednocześnie warto, żeby Właściciel Produktu tłumaczył zespołowi, kiedy i jak je wykorzystuje. Chodzi o to, żeby cały Zespół Scrumowy zobaczył, że tworzenie Backlogu jest rodzajem tańca, gdzie partnerzy nawzajem od siebie zależą i tylko wtedy będą to robić płynnie, kiedy będą znali kroki i figury. W pielęgnacji Backlogu, tak jak w tańcu na zapełnionym parkiecie, nie da się przewidzieć, co się będzie działo, dlatego trzeba elastycznie reagować na sytuację. To, jak bardzo Zespół Deweloperski jest zaangażowany w tworzenie elementów Backlogu, zależy od wielu czynników. W niektórych projektach ich rola będzie polegała głównie na zrozumieniu, na czym zadanie polega, w innych może wymagać wielu ustaleń dotyczących technologii, architektury, bezpieczeństwa, wydajności lub innych kwestii.
Pierwszy etap ćwiczenia kończy się, kiedy dany element Backlogu będzie gotowy do wzięcia do Sprintu. Należy przypomnieć, że Właściciel Produktu jest wyłącznym właścicielem Backlogu Produktu i on za niego odpowiada, jednak estymaty są zawsze tworzone przez Zespół Deweloperski.
Drugi etap ćwiczenia zaczyna się, kiedy zmienia się właściciel – Backlog Sprintu jest własnością Zespołu Deweloperskiego. Teraz należy omówić, jak element Backlogu jest uzupełniany o plan jego dostarczenia w czasie Planowania. Jest to dobry moment na sprawdzenie, czy ten proces przebiega w optymalny sposób.
Następnie, w czasie Sprintu, kartki symbolizujące elementy Backlogu mogą być symbolicznie uzupełniane o kolejne poznawane (lub tworzone) przez Zespół Deweloperski informacje. W rzeczywistości te informacje rzadko są dopisywane do elementu, raczej powstają jako innego typu byty, takie jak dokumentacja czy testy. Warto popatrzeć, co się dzieje w czasie Daily, jakie informacje są (lub powinny być) wtedy przekazywane.
Należy się dopytać, jakich informacji potrzebuje Właściciel Produktu w czasie Sprintu i sprawdzić, czy są one dostępne dla niego w łatwy sposób. Jest bardzo prawdopodobne, że dla Właściciela Produktu wygodniejsza jest sytuacja, kiedy może zobaczyć gotowe elementy bezpośrednio po tym, jak powstaną, a nie dopiero na koniec Sprintu. Należy dowiedzieć się, jak w najbardziej komfortowy dla Właściciela Produktu sposób poradzić sobie z sytuacją, że jakiś element Backlogu nie zostanie ukończony – kiedy i w jaki sposób chce być o tym informowany. Dobrze, żeby Właściciel Produktu wytłumaczył, jakie są konsekwencje niedostarczenia jakiegoś elementu (biznesowe, wizerunkowe, finansowe lub inne).
Drugi etap ćwiczenia kończy się na Przeglądzie Sprintu. Należy teraz zwrócić uwagę na to, jak w jego czasie przepływają informacje – zarówno te, dotyczące ukończonego właśnie Przyrostu, jak i te, mające wpływ na kolejne elementy Backlogu. Warto porozmawiać również o sytuacjach, kiedy feedback jest negatywny albo wymagane są zmiany.
Trzeci etap ćwiczenia to czas po Przeglądzie Sprintu. Często jest tak, że Właściciel Produktu dopiero po pewnym czasie decyduje się wdrożyć dany element Backlogu. Dobrze jest zobaczyć, jakie informacje pojawiają się na temat tego elementu oraz jak są one obsługiwane przez Zespół Scrumowy. Warto również prześledzić, co się dzieje w przypadku błędów, bo często jest to sytuacja, kiedy szwankuje zbieranie informacji.
Po prześledzeniu całego cyklu życia elementu Backlogu – od idei do wdrożonego rozwiązania – należy powtórzyć to ćwiczenie z następnym elementem. Ciekawym przypadkiem do omówienia może być zmiana w już istniejących funkcjach. Podczas drugiego “przebiegu” warto się skupić na tym, co można w całym procesie ulepszyć, a mniej na tym, jak Zespół robi to obecnie.
Na koniec ćwiczenia należy zaplanować wdrożenie znalezionych rozwiązań oraz czas, kiedy Zespół Scrumowy przeprowadzi ich ponowną inspekcję. Bardzo ważne jest, żeby po pewnym czasie podsumować korzyści i wady wprowadzonych zmian i zobaczyć, czy coś jeszcze wymaga usprawnienia. Szczególnie dotyczy to zapewnienia Właścicielowi Produktu potrzebnych mu do pracy informacji i wypracowania większej autonomii Zespołu. Dobra współpraca opiera się na zrozumieniu, a nie na kontroli.
Podsumowanie
Ćwiczenie jest długie i trudne, jednak pozwala popatrzeć na wytwarzanie Przyrostu od strony potrzebnych Zespołowi Scrumowemu informacji. Dzięki temu często łatwiej jest wyjść poza wcześniejsze nieporozumienia i znaleźć lepszy sposób współpracy, oparty na wzajemnym zrozumieniu swoich potrzeb.
W angielskim mamy rozróżnienie między attend a participate – w polskim przewodniku po scrumie zostało ono utracone. SM powinen zapewnić że tylko członkowie zespołu deweloperskiego uczestniczą, a więc zabierają głos na spotkaniu, pozostali -w tym PO – biorą udział (słuchają).
Z mojego doświadczenia wynika, że zezwolenie na przysłuchiwanie się dowolnym zainteresowanym osobom pozytywnie wpływa na przejrzystosc, a więc podstawową wartość scruma.
Dzięki za komentarz dotyczący tłumaczenia, bardzo przydatny.
Jeśli chodzi o przejrzystość, to się nie zgodzę z Tobą. Zespół ma tylko 15 minut, żeby dowiedzieć się o tym, co ważnego i wpływającego na ich pracę stało się przez ostatnie 24 godziny oraz ustalić plan gry na następne. To jest bardzo mało. Dobrze, żeby rozmawiali ze sobą w sposób możliwie efektywny, używali swojego żargonu i swojego codziennego sposobu komunikowania się (nawet jeśli jest to ponglish). To spotkanie jest tylko dla nich, a obecność innych będzie ich skłaniała do mówienia bardziej „po ludzku”, co wcale w tym wypadku nie jest korzyścią, tylko kosztem dla zespołu. Podsumowując – przejrzystość jest jak najbardziej jednym z filarów Scruma, ale nie widzę jej zastosowania w tym kontekście.
Za to zgodzę się, że obecność kogoś przenosi uwagę zespołu na sam sposób w jaki Daily jest prowadzone. Jeśli zespół się decyduje na to od czasu do czasu, to dobrze, bo dzięki temu zrobi sobie inspekcję i popatrzy na swoją pracę oczami innej osoby. Jednak traktujmy Zespoł Deweloperski z szacunkiem i nie zaburzajmy jego pracy. Konieczne jest, żeby Zespół zgodził się na taką wizytę. Czyli „zezwolenie” musi nastąpić z ich strony, jeśli uznają, że nie będzie im to w żaden sposób przeszkadzało. Często Zespoły są dumne z tego, jak pracują i chętnie pokazują np. innym Product Ownerom lub Deweloperom, jak wygląda dobre Daily. Jednak absurdem jest oczekiwanie, że ktoś postronny zrozumie o czym mówią. Jako SM takiego zespołu zadbałabym wcześniej, żeby „widz” miał tego świadomość, a Zespół nie czuł się zobowiązany do brania tej osoby pod uwagę.
Jest jeszcze jeden powód, dla którego obecność dowolnej osoby na Daily nie jest wskazana, ale o tym będzie w następnym artykule.
no czekam i czekam na ten następny artykuł i nie mogę się doczekać 🙂 kiedy publikacja?
Powoli się rodzi 🙂 Niestety, jeden taki wpis, to 40-50 godzin pracy i czasami trudno mi na to znaleźć wystarczająco dużo czasu w nawale innych obowiązków.
Pozdrawiam,
Jaga
Bardzo to ciekawe, super że opisałaś ćwiczenie (przetestujemy 😉
Czy badałaś jak poczucie autonomii wpływało na prędkość/przyrost?
Mam nadzieję, że będziecie zadowoleni z wyników 🙂
Badałam, ale z różnych powodów nie mogłam się posłużyć danymi o velocity zespołów. Zbierałam za to informację o tym, na ile procent każdy zrealizował cele sprintu i na ile zrealizował je cały zespół. Jednak dane wyglądają na tyle dziwnie, że nie odważę się na ich podstawie wyciągać ogólnych wniosków.
Bardzo bym chciała w następnych badaniach nie tylko zbadać to, z jaką prędkością zespoły dostarczają nową funkcjonalność, ale też zadowolenie klienta oraz jakość dostarczanych rozwiązań. Dobry zespół bierze pod uwagę wiele rzeczy – wydajność, bezpieczeństwo, łatwość utrzymania kodu i wprowadzania zmian, tworzy testy różnego rodzaju, dokumentuje kod. Dopiero te wszystkie czynniki wzięte razem pod uwagę, mogą mówić o prawdziwej prędkości tworzenia oprogramowania. Zrobienie czegoś szybko, często mści się po pewnym czasie i jakby policzyć czas poświęcony na tworzenie i utrzymanie, to często zespół pracujący wolniej, ale lepiej inżyniersko, jest znacznie bardziej wydajny niż ten, który robi na chybcika i potem musi gasić pożary. A czasami jest odwrotnie i bardziej się opłaca szybko zrobić coś, żeby sprawdzić ideę. Innym razem warto zrobić na początku badania z użytkownikami i dostarczyć coś lepiej dopasowanego, ale trochę później.
Więc podsumowując, chciałabym nie tylko sprawdzić, jak różne czynniki wpływają na prędkość tworzenia przyrostu, ale też jakiej jakości jest ten przyrost i na ile jest wartościowy dla klienta. Niestety ciężko to zbadać w jakiś ustandaryzowany sposób 🙂 Ale będę kombinować, więc jeśli ktoś ma jakieś pomysły, to bardzo chętnie porozmawiam.
Dałeś mi tym pytaniem motywację do tego, żeby posiedzieć wynikami i sprawdzić jeszcze raz to, co wydawało mi się dziwne w wynikach osób/zespołu. Odpowiadając Ci dwa dni temu nie rozumiałam pewnych wyników i wydawały mi się nonsensowne. Ale sprawdziłam to jeszcze raz i są w porządku. Obiecuję wrzucać te wyniki do kolejnych artykułów, bo wiem, że dla wielu osób to sprawa kluczowa – co wpływa na prędkość wytwarzania przyrostu.
widzę trochę błędne założenie, że w składzie zespołu „dowożącego” rozwiązanie są tylko developerzy, a co z UX, UI, SEO?
Nie mam takiego założenia. Zgodnie ze Scrum Guide każdy członek zespołu, niezależnie od wykonywanej pracy, nosi tytuł Dewelopera. Pracowałam z bardzo różnymi zespołami, ale najczęściej miały mocno zróżnicowany skład (najbardziej homogeniczny był zespół pracujący przy hurtowni danych, ale on z kolei był nietypowy pod innymi względami). Dziękuję, że zwracasz na to uwagę, bo nie pomyślałam o tym, żeby wyraźnie zaznaczyć, że pisząc Deweloper chodziło mi o każdego członka zespołu innego niż Product Owner i Scrum Master.
Rzeczywiście artykuł ten daje dużo do myślenia. Gratulacje! Przede wszystkim uchwyca to, co sucha jak przepis na ciasto metodyka Scrum pomija – aspekt psychologiczny. I uważam to za katostrofalny błąd skutkujący tym, że wiele osób stosuje Scruma bezmyślnie, powierzchownie a nawet błędnie i szkodliwie.
Co do meritum, to trzeba dobitnie jedną rzecz stwierdzić: samorganizacja i branie odpowiedzialności przez zespół nie jest abosultem odkrytym przez Scruma, który cechuje każdy zespół, wręcz przeciwnie – nie jest to naturalne i aby to osiągnąć trzeba to wypracować wkładając wiele wysiłku. Zespół deweloperski chętnie pójdzie na łatwizę zrzucając na Product Ownera wysiłek orgranizacji bieżących prac w Sprint’cie, a nieświadomy tego Product Ownera chętnie się tym zajmie, bo naturalnie to on w pierwszej lini odpowiada za projekt. Następnie Product Owner podejmie trudne decyzje (np. żeby zadanie zrobić najszybciej zamiast programistycznie najlepiej) niekoniecznie miłe dla zespołu i zaczynie się szefowanie a skończy Scrum. Podstawowym błędem jest ciche założenie przez wielu scrumowców, że zespół naturalnie będzie dążył do opymalizacji biznesowej projektu i osiągania kolejnych celów/etapów/sprintów najbardziej ekonmiczną ścieżką. W teori być może wydaje się to oczywiste, ale w praktyce często wiąże się to z wyżeczeniami np.: rezygnacją ze zdobycia doświadczenia bo nie ma czasu na poznanie lepszego narzędzia, czy użycie gorszych algorytmów, które na studiach były wykpiwane itp. Zespół deweloperski w dużej mierze nie chce odczuwać ciężaru opdowiedzialności za biznesowy aspekt projektu, bo też nie jest wymiernie nagradzany za jego optymalizację. Na tej płaszczyźnie naturalnie rysuje się konflikt interesów pomiędzy Product Ownerem a zespołem i dobry Product Owner musi przyjąć też rolę negocjatora uwzględniającego nieco odmienne punkty wiedzenia jego i zespołu oraz ich stopień zadowolenia i motywacji. I jestem przekonany, że Scrum za pomocą sprintów, planingu i review znakomicie w tym pomaga (czego nie widzę w Kanbanie) – właśnie planing jest miejscem na takie negocjacje a review na sprawdzam. Natomiast w trakcie sprintu o wszystkim decyduje tylko zespół i jakakolwiek ingerencja Prodcu Owenara czy to narzucona czy nawet pożądana przez zespół może spowodować, że zespół poczuje się zwolniony z odpowiedzialności za replanowanie, optymalizowanie wykonania zadań konieczne do osiągnięcia celu a zajmie się jedynie robieniem zadań z backlogu według indywidualnego widzimisie. Dodatkowo replanowanie to nierzadko żmudna, ciężka i nudnawa praca.
Teraz z zupełnie innej strony. Systemowy brak udziału Product Ownera i planowanie kolejnego dnia nierzadko połączone z replanowaniem sprintu, to dwie rzeczy praktycznie sprzeczne z sobą. Otóż niemalże z każdym dniem wychodzą istotne rzeczy, których ani zespół ani Product Owner nie byli świadomi podczas planowania. Naturalnie zespół ma ochotę, często za dużą, podzielenia się nimi z Product Ownerem i zweryfikowania, czy nie wpływają one istotnie na obraz inkrementu, który był uzgodniony podczas planingu. I notorycznie zdarza sie, że niektóre mają istotny a nawet krytycznie istotny (szczególnie w projektach inowacyjnych) i które to wymagają konsultacji z Product Ownerem. A skoro to daily ma być czasem na podsumowanie tych zdarzeń i replanowanie, to obecność Product Ownera może być bardzo pożądana. Może jego rola powinna być ograniczona jedynie do udzielania odpowiedzi i w ten sposób nie przejmie on inicjatywy. I znowu to jest teoria idealizująca rzeczywistość. W praktyce zespół replanuje na bieżąco i pyta Product Ownera natychmiast (choćby nawet mailowo) i chciałby decyzji na już nie czekając na następne daily. I bardzo dobrze robi! – w końcu tak wygląda samoorgnizacja. I jeśli jeszcze zastosować praktykę, którą wprowadziłem w moim projekcie, żeby na koniec każdego dnia zapisywać stan prac nad zadaniami w postaci komentarzy wJirze, to w ogóle nasuwa się pytanie po co to daily. I myślę, że tak powinno być: daily za bardzo niepotrzebne – ot chwila refleksji, wspólnego spojrzenia na backlog i wymiana tylko naistotniejszych informacji, aby mieć pewność, że wszyscy usłyszeli. I taką formę z pewnością można wpisać w 15 minut angażując cały zespół, bo nie wierzę, że w 15 minut da się replanowanować, czy merytorycznie dyskutować z Product Ownerem.
Dziękuję za komentarz. Cieszę się, że znalazłeś w artykule coś ciekawego dla siebie. Poruszyłeś bardzo dużo wątków w swojej odpowiedzi. Na część z nich prawdopodobnie odpowiedzią jest ostatni artykuł o Review http://www.scientificagile.com/2018/02/korzysci-z-review/, na część – odpowiedzią będzie następny, pokazujący, jak PO może budować motywację i odpowiedzialność w Zespole.
Teraz chciałabym Ci odpowiedzieć na to, co napisałeś o samym Daily. Oczywiście, jeśli wychodzą nowe rzeczy (takie które wpływają na to, czy Zespół da radę dostarczyć Przyrost albo czy ten Przyrost pozwoli osiągnąć cele biznesowe) to Zespół powinien informować PO natychmiast, aby można było podjąć jak najszybciej decyzję, co zrobić. Sensem Daily jest uzgodnienie przez Zespół współpracy między sobą, czyli rozmowy typu:
Janek: „Koło południa skończę to kodować, będzie można to przetestować”, Kasia: „Ja jeszcze testuję XXX”, Marek: „To w takim razie ja to zrobię”.
Albo inny scenariusz: Marek: „Żeby zrobić zdanie YYY musimy mieć dostęp do tamtej bazy, czy ktoś to załatwiał?”, Kasia: „Nie, ale i tak zaraz idę do tamtego zespołu, to z nimi to załatwię”.
I jeszcze jeden: Adam: „Wydaje mi się, że po tych problemach, jakie mieliśmy wczoraj z najważniejszym zadaniem w Sprincie jest możliwość, że nie zdąrzymy go skończyć”, Marek: „To w takim razie się podzielmy inaczej pracą, ja Ci pomogę z tym, a jeśli to się nam uda, to wrócę do poprzedniego zadania”, Kasia: „OK, to ja już zacznę poprawiać testy, żebyście mogli to od razu sprawdzać”, Janek: „A ja koło 13:00 wrócę ze szkolenia, to będę mógł Ci zrobić review kodu”.
W takim rozumieniu jest to spotkanie planistyczne – bo Zespół patrzy na to, jakie interakcje pomiędzy nimi będą potrzebne i planuje je po to, żeby przebiegały sprawniej i żeby nikt nie czekał z czymś ważnym. Z drugiej strony Zespół myśli o tym, czy nie trzeba w jakiś sposób zmienić sposobu swojej pracy, żeby osiągnąć Cel Sprintu i zrealizować najważniejesze zadania. Backlog Sprintu nadal jest spriorytetyzowany i Zespół powinien dostarczać zadania od góry, żeby to, czego ewentualnie nie będzie w stanie zrobić to były najmniej istotne rzeczy z samego dołu Backlogu. Po trzecie Zespół patrzy na zadania, które mu jeszcze pozostały i sprawdza, czy nie ma tam czegoś, czym należałoby się zająć z wyprzedzeniem.
Błędnym rozumieniem jest, że na Daily zgłasza się „impedimenty”. Odkrywa się nowe, te, które w przyszłości mogłyby zablokować pracę. Problemy, które ktoś odkrył w trakcie pracy muszą być zgłaszane i rozwiązywane na bieżąco.
Nie widzę natomiast żadnych korzyści z zapisywania statusu zadań na koniec dnia. Mogłoby to ewentualnie pomóc w sytuacji, kiedy ktoś by się następnego dnia rozchorował. Ale wtedy będzie prościej, jak osoba, kto będzie przejmowała jego zadanie, zadzwoni do niego. Zapisywanie jest bardzo słabym sposobem przekazywania informacji, telefon znacznie lepszym. Z kolei, jakby się komuś miało stać coś poważniejszego, uniemożliwiającego rozmowę, to Zespół i tak ma duży problem i będzie musiał się zastanowić, co w tej sytuacji jest w stanie dostarczyć. Generalnie to pachnie kontrolowaniem Deweloperów i traktowaniem ich jak dzieciaków, którym trzeba kazać zanotować, bo inaczej to… No właśnie, to co? W żadnym Zespole z którym pracowałam nie widziałam takiej praktyki. Jak zadanie jest skończone, to należy je zaktualizować na tablicy. Jak nie i ktoś chce sobie zrobić notatki, żeby o czymś następnego dnia nie zapomnieć, to niech sobie zrobi. Ale to jego sprawa gdzie i jak. Moim zdaniem ta praktyka wpływa bardzo negatywnie na morale Zespołu i ich poczucie odpowiedzialności.
O długu technicznym i odpowiedzialności za jakość rozwiązania napiszę innym razem 🙂