Odezwał się do mnie ostatnio zaprzyjaźniony CEO z jednej z Polskich firm technologicznych z następującym pytaniem:
“Jacek, co zrobić, gdy management ma odczucie, że zespoły pracują za wolno?”.
Temat jest wielowymiarowy i przy niemal zerowej znajomości kontekstu, wszystko na co mogę sobie pozwolić, to luźne hipotezy i wskazanie obszarów, od których zacząłbym eksplorację problemu.
Poniżej zebrałem swoje przemyślenia na ten temat, które mogą pomóc spojrzeć szerzej na to zagadnienie.
Pierwsza myśl. Co to znaczy za wolno?
To, co przychodzi mi do głowy w pierwszym odruchu, to chęć pogłębienia tego, co znaczy za wolno. Opcji bowiem jest wiele, czy chodzi o:
- Porównanie z konkurencyjnymi firmami, które pomimo posiadania mniejszych możliwości (mniej osób w zespole, mniejsze możliwości finansowe) są w stanie wytworzyć podobny produkt zdecydowanie szybciej?
- Zupełnie subiektywne odczucie, że coś, co powinno powstać w dwa tygodnie, ciągnie się od dwóch miesięcy?
- Czas liczony od momentu, gdy ktoś (biznes, interesariusze, klient) zgłosi pomysł do realizacji do momentu, kiedy rozwiązanie jest dostępne dla użytkowników?
- Ilość zrealizowanych elementów Backlogu Produktu lub Story Pointów per Sprint dla konkretnej pojemności Zespołu Deweloperskiego?
Druga myśl. Środowisko pracy
Domyślnie jestem ufny w stosunku do ludzi i wierzę, że co do zasady, chcą dobrze.
Na bazie swoich doświadczeń, nieco mniej entuzjastyczny jestem jeśli chodzi o doskonałość tego, jak zbudowane są środowiska, w których przychodzi im pracować.
Spotykam się z przypadkami, w których czysta praca Dewelopera trwa krótko, ale otoczenie, w którym pracuje, drastycznie wydłuża czas od podjęcia zadania do osiągnięcia stanu, w którym może zostać wdrożone na środowisko produkcyjne.
Poniżej kilka przykładów zagadnień, które mogą mieć wpływ na sumaryczny czas trwania pracy:
- Zależności zewnętrzne z innymi zespołami/działami/komponentami/dostawcami
- Długi proces zapewniania jakości, np. osadzony poza zespołem dział QA, działający na zasadzie “okienek testowych”
- Braki sprzętowe, np. za mało środowisk testowych lub środowiska są współdzielone, co powoduje, że nie zawsze są dostępne dla konkretnego zespołu
- Opieranie procesu zapewniania jakości na testach manualnych, przy znikomym lub zerowym zaangażowaniu testów automatycznych
- Niedostępny/proxy Product Owner, przez co Zespół Deweloperski długo czeka na decyzje oraz odpowiedzi na zadane pytania
- Zaciągnięty dług technologiczny, uniemożliwiający realizację szybkich zmian
- Silosy kompetencyjne w zespole, np. tylko jedna osoba z zespołu potrafi zaimplementować konkretną funkcjonalność, tylko jedna osoba testuje itp.
- Błędy z produkcji, które wracają do zespołu i powodują, że członkowie zespołu porzucają bieżącą pracę, żeby naprawiać błędy
Trzecia myśl. Backlog Produktu.
Do zbadania jest temat jakości przygotowania Backlog Produktu — zwykle kiepska kondycja Backlogu Produktu ma bardzo negatywny wpływ na tempo prac. W takiej sytuacji bowiem, Zespół Deweloperski pracuje w Sprincie nad elementami, które są obarczone dużym ryzykiem, ze względu na ich powierzchowne zrozumienie.
Dodatkowo spojrzałbym na rozmiar elementów zawartych w Backlogu Produktu. Niemal w każdej firmie, z którą współpracowałem, istniała przestrzeń na to, aby dzielić User Stories na mniejsze części. Nieduży rozmiar elementów w Backlogu Produktu pozwala uniknąć stanu, w którym praca ciągnie się przez kilka Sprintów.
Czwarta myśl. Znajomość produktu w Zespole Deweloperskim
Jeżeli zespół nie rozumie jak działa produkt i dlaczego właśnie ten sposób, nie zna procesów biznesowych i nie rozumie potrzeb użytkowników, to trudno oczekiwać, żeby praca była realizowana w wydajny sposób.
Nieznajomość produktu prowadzi najczęściej do błędów w implementacji, które wracają do zespołu do Zespołu Deweloperskiego jak bumerang, zabierając czas, który mógłby być poświęcony na rozwój produktu.
Kiepska wiedza o produkcie cementuje również silosy kompetencyjne i osłabia przepływ pracy w zespole. Jeżeli tylko jedna lub dwie osoby rozumieją, jak działa produktu, to zwykle tylko one są w stanie rzetelnie zapewnić jakość produktu i przeprowadzić wiarygodne testy.
Piąta myśl. Szara strefa
Możemy mówić też o sytuacji, w której Właściciel Produktu wie tylko o części prac, które wykonuje Zespół Deweloperski. Oprócz pracy wskazanej przez PO, realizowana jest inna, dodatkowa praca, która może pochodzić od klienta, interesariuszy, innych Zespołów Deweloperskich albo być generowana przez zespół.
W konsekwencji powstaje tzw. szara strefa produktowa, z której osoby, nie zaangażowane bezpośrednio w rozwój produktu, nie zdają sobie sprawy. Realna prędkość zespołu w takiej sytuacji pozostaje nieznana, ponieważ dodatkowe zadania, mimo że są realizowane, nie pozostawiają po sobie żadnego śladu. To sytuacja, w której zespół być może i pracuje z maksymalną wydajnością, ale nie nad tematami, które są priorytetowe.
Szósta myśl. Morale w zespole
Doświadczałem sytuacje, w której zachowanie jednej osoby potrafiło negatywnie wpłynąć na kondycję całego zespołu. Jeżeli komuś się nie chce, mentalnie zrezygnował już z pracy, sieje zamęt, przesadny sarkazm lub jest – jak to określiła kiedyś moja koleżanka z HR — “na wewnętrznej emigracji”, trudno oczekiwać, że odbije się to pozytywnie na kondycji Zespołu Deweloperskiego.
To rzadkie przypadki, jednak w ciągu tych kilkunastu lat pracy w IT, spotkałem się kilkoma takimi osobami i widziałem, jakie zniszczenie powodowały one w zespole.
Co możemy z tym zrobić?
Wracając do głównego pytania – gdybym usłyszał, że produkt jest rozwijany za wolno, to spojrzałbym w pierwszej kolejności na wyżej wymienione aspekty.
Co konkretnie można zrobić w tych obszarach?
- Porozmawiać z osobami, które zgłosiły problem – zrozumienie, dlaczego w czyimś odczuciu praca przebiega za wolno, pozwoli zrozumieć perspektywę drugiej strony i może być wartościowym wkładem do dalszej eksploracji tematu.
- Przeanalizować środowisko pracy – nawet najlepszy zespół osadzony w kiepsko przygotowanym środowisku, będzie tak efektywny, jak jego najsłabsze ogniwo. Przykładowym sposobem zidentyfikowania słabych punktów środowiska może być przeprowadzenie porządnej retrospektywy, w której udział mogliby wziąć reprezentanci zespołu/ów oraz managementu firmy
- Spojrzeć na aktualną rolę managera w firmie – być może tak bardzo potrzebna praca managerska, związana z tworzeniem efektywnego środowiska pracy dla zespołów nie występuje, ze względu na nawał pracy operacyjnej i ciągłe gaszenie pożarów
- Skupić się na doskonaleniu Backlogu Produktu – Moje doświadczenie jest następujące: czas zainwestowany w porządne przygotowanie Backlogu Produktu zwraca się w Sprintach, które rzadziej “wybuchają”, są bardziej przewidywalne a praca w nich przebiega płynniej
- Rozbudować zrozumienie produktu w Zespole Deweloperskim – może to uzyskać m.in. poprzez angażowanie zespołu w product discovery, testowanie w parach (osoba dobrze znająca produkt w parze z osobą, która nie zna produktu) oraz zespołowe sesje doskonalenia Backlogu Produktu
- Uwidocznić całą pracę wykonywaną przez Zespół – umowa w zespole, że cała praca, którą się zajmujemy (nawet ta najmniejsza), trafia na widoczną dla wszystkich tablicę, może być dobrym punktem startu do dalszych analiz.
- Zbadać morale w zespole – Istnieje wiele sposobów, aby zdiagnozować morale w zespole. Rozmowa z całym zespołem, rozmowy 1×1 lub narzędzia badające nastroje w zespole, to przykładowe możliwości.
- Zorganizować spojrzenie osoby z zewnątrz. Zaproszenie ktoś, aby z boku zespołu spojrzał na to, jak pracuje zespół. Taka osoba patrząca z boku (inny Scrum Master niż zespołowy, inny Product Owner, inny Deweloper, zewnętrzny Agile Coach) może zaobserwować zachowania, których Zespół Deweloperski samodzielnie nie jest (już) w stanie dostrzec.
A Ty od czego zaczynasz, gdy ktoś stwierdza, że praca idzie za wolno?
Chętnie podyskutuję w komentarzach.
Photo by Makarios Tang on Unsplash
2 odpowiedzi
Interesujący artykuł. Dobra lista referencyjna przy badaniu efektywności pracy zespołu. Dodałbym do tego jeszcze presję ze strony klienta lub managera. Spotkałem się z przypadkiem, kiedy nacisk ze strony klienta powodował, że programiści zaczęli dostarczać rozwiązania szybciej, ale niestety zaowocowało to większą liczbą błędów na produkcji. Sytuacja ta oczywiście nie spotkała się z zadowoleniem klienta, który zauważył nagły wzrost czasu raportowanego na poprawianie błędów. W związku z czym zespół przestał raportować czas konieczny na dokonanie poprawek „wmasowując go” w czas realizacji zadań podstawowych. Tym samym produktywność zespołu jeszcze bardziej spadła co pogorszyło i tak już złe morale. Ostatnim gwoździem do trumny było publiczne porównanie prac zespołu do pracy innych zespołów co było o tyle bezzasadne, że inne zespoły ogarniały zupełnie inny – mniej newralgiczny – obszar zadań i miały inną specyfikę pracy.
Na koniec małe code review:
„Opcji bowiem jest wiele, czy chodzi bowiem o” – powtórzenie
„(nawet na najmniejsza)” – literówka
Cześć Zbigniew. Bardzo ciekawa historia i ciąg przyczynowo-skutkowy, wpisujący się w poruszane zagadnienie. Dziękuję, że się tym podzieliłeś, no i za Twoje code review :) Poprawione.