Co zrobić, gdy zespoły pracują za wolno?

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:

  • Czas liczony od momentu, gdy ktoś (biznes, interesariusze, klient) zgłosi pomysł do realizacji do momentu, kiedy rozwiązanie pojawia się na produkcji?
  • Ilość elementów Backlogu Produktu / Story Pointów zrealizowanych per Sprint dla konkretnej pojemności Zespołu Deweloperskiego?
  • Zupełnie subiektywne odczucie, że coś, co powinno powstać w jeden Sprint, ciągnie się od kilku Sprintów?

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

Nagranie mojej prezentacji o product discovery z Agile By Example 2018

Od pewnego czasu dostępne jest nagranie mojej prezentacji „How to build the right product using Product Discovery techniques”, którą miałem okazję zaprezentować podczas październikowej konferencji Agile By Example.

Warto obejrzeć, bo prezentacja jest zwięzła (~13 minut), oparta na trzech praktycznych przykładach z życia i pokazuje, jak można skorzystać z product discovery w codziennej pracy.

Z techniki product discovery* korzystam od kilku lat – zarówno w pracy z klientami, jak i do tworzenia własnych produktów, takich jak warsztaty, książka czy podcast (nagrywany wspólnie z Kubą). Niezmiennie zaskakuje mnie, jak rzadko podejście to jest stosowane w praktyce w firmach, które pracują lub chcą pracować w zwinny sposób.

Zachęcam do obejrzenia video i podzielenia się wrażeniami w komentarzach.

* ktoś zna lepsze tłumaczenie „product discovery” niż „odkrywanie produktu”?

Jak biznes może wspierać zwinne Zespoły Deweloperskie?

Pracując  u klienta, otrzymałem ostatnio pytanie od osoby z biznesu: “W jaki sposób my — czyli biznes — możemy wspierać Zespoły Deweloperskie?”. Jest to moim zdaniem bardzo dobre pytanie, bo łatwo mówić ogólnie o współpracy, a trudniej jest wskazać konkretnie, jak może to wyglądać w praktyce. W tym wpisie podzielę się kilkoma przykładami, co moim zdaniem może zrobić biznes, aby wesprzeć zespoły wytwarzające. Czytaj dalej

Premiera podcastu „Porządny Agile”

Logo podcastu „Porządny agile”

Dzisiaj swoją premierę ma podcast “Porządny agile, który będę współtworzył z Kubą Szczepanikiem. Pierwszy, premierowy odcinek dotyczący roli Scrum Mastera, możecie odsłuchać na stronie podcastu.

W podcaście będziemy dyskutować o szeroko rozumianej zwinności, sięgając do naszych doświadczeń, obserwacji oraz przemyśleń.

Mamy hipotezę, że jest miejsce na polskim rynku na solidny podcast skupiony wyłącznie na zwinności i aspektach z nią związanych. Mieliśmy rację kilka lat temu zakładając z Ewą, Izą i Dawidem agile247.pl i wierzymy, że podobnie będzie z podcastem. Czytaj dalej

Jak Scrum Master współpracuje z Product Ownerem?

PO z SM wspierają siebie nawzajem, podobnie jak piloci samolotów bojowych lecący na misję

PO z SM wspierają siebie nawzajem, podobnie jak piloci samolotów bojowych lecący na misję

Pisałem w ostatnim wpisie o tym, jak niewłaściwe zrozumienie słowa coaching, może mieć negatywny wpływ na relację pomiędzy Product Ownerem a Scrum Masterem. Zaproponowałem też bardzo ogólnie kilka pomysłów na to, jak te dwie role mogą współpracować ze sobą. W dzisiejszym wpisie chciałbym rozwinąć te punkty o konkrety, które przedstawią, jak może taka współpraca wyglądać w praktyce.

Całość opieram na moich moich własnych doświadczeniach współpracy z Product Ownerami jako Scrum Master oraz Agile Coach.

Na czym może polegać taka współpraca?

Czytaj dalej