Próg wejścia do zwinności nie jest wysoki

To zupełnie jak z bieganiem: każdy może zacząć biegać, wystarczą tylko sensowne buty i to wszystko.

Ale kiedy chcesz przebiec półmaraton w ambitnym czasie (czyt. mieć faktyczne rezultaty), wiele elementów musi kliknąć jednocześnie.

1. Właściwy, regularny trening i jego periodyzacja
2. Odpowiednia ilość snu
3. Poprawne odżywianie i nawodnienie
4. Odpowiednia logistyka dnia

Wiele osób nie dojdzie nigdy do tego poziomu, chwilę pobiegają i stracą zapał do poważniejszych zmian albo będą biegać sobie raz w tygodniu.

I co do zasady to jest w porządku, bieganie dla przyjemności też jest możliwe.

Ale nie spodziewaj się wtedy faktycznych, mierzalnych rezultatów sportowych.

Jak to się ma do zwinności?

Podobnie jest ze zwinnością: wiele elementów musi kliknąć w tym samym momencie.

1. Bliskie współdziałanie z użytkownikiem tworzonego rozwiązania oraz wewnątrz zespołu wytwórczego
2. Dostarczanie wartościowego rozwiązania małymi krokami
3. Regularna refleksja na temat sposobu pracy i tego, co dostarczamy
4. Na bazie powyższego ciągłe usprawnienia

Wiele firm nie dojdzie nigdy do tego poziomu, chwilę popracują zwinnie i stracą zapał do poważniejszych zmian albo będą stosować losowo wybrane koncepcje (np. codzienny standup).

I co do zasady to jest w porządku, bawienie się w zwinność też jest możliwe [1].

Ale nie spodziewaj się wtedy faktycznych, mierzalnych rezultatów biznesowych.

[1] Aczkolwiek nie jest najmądrzejsze, w szczególności jeśli wykładasz na to swoje pieniądze.

I chociaż minęło już kilka lat od momentu, gdy wydałem książkę, to nadal uważam tak samo.

Jednak zrobić dobre retro nie jest tak prosto, jak może się wydawać. Jednym ze sposobów uzyskania faktycznych usprawnień na koniec tego spotkania jest zastosowanie wyraźnej struktury spotkania.

7 Kroków Udanej Retrospektywy wg Porządny Agile

Wraz z Kubą Szczepanikiem zebraliśmy nasze praktyczne doświadczenia z przeprowadzania skutecznych sesji usprawnieniowych i stworzyliśmy strukturę o dumnej nazwie 7 Kroków Udanej Retrospektywy wg Porządny Agile.

1. Zweryfikuj usprawnienia z poprzedniej Retrospektywy. Krok ten stosujesz tylko wtedy, gdy Retrospektywy odbywają się w Twoim zespole. Polega na tym, żeby wrócić do usprawnień, które zostały ustalone na poprzedniej Retrospektywie. Należy sprawdzić ich status i porozmawiać szczególnie o tych, które nie zostały zrealizowane.
2. Przypomnij, co będzie przedmiotem i celem Retrospektywy. Krok ten jest szczególnie ważny w zespołach, które dopiero rozpoczynają przygodę z Retrospektywą. Gdy Zespół Scrumowy dopiero się uczy jej używać, warto zadbać o dobre zrozumienie celu tego typu spotkania. Przykładowo, możesz opowiedzieć w kilku zdaniach, jak będzie przebiegać oraz poinformować o spodziewanych rezultatach.
3. Zbierz tematy do dyskusji lub przeanalizowania — Podczas tego kroku Zespół Scrumowy tworzy listę tematów, które chce przedyskutować. Pozwala to uniknąć pułapki rozmowy na pierwszy zgłoszony temat, który niekoniecznie jest najważniejszym tematem do dyskusji dla całego zespołu. Przykładową techniką może być technika 4L.
4. Wybierz z zespołem najważniejsze tematy — Bazując na stworzonej w poprzednim kroku liście tematów należy dokonać oceny, które z nich są faktycznie najbardziej istotne dla twojego zespołu. Zadbaj, żeby uczestnicy Retrospektywy oparli się pokusie omówienia wszystkich. Przykładową techniką na tym etapie jest zaproszenie każdej osoby z zespołu do zagłosowania kropkami na trzy najważniejsze dla tej osoby tematy.
5. Omów dogłębnie najważniejszy problem — Omów zespołem wybrane tematy, znajdź przyczyny źródłowe konkretnych problemów, bez skupiania się jeszcze na rozwiązaniach. Przykładową techniką na tym etapie może być metoda 5W.
6. Ustal rozwiązanie omówionego problemu — Gdy zespół ma już wybrany najważniejszy problem i zna jego przyczyny, można przejść do szukania rozwiązań. Warto być tutaj konkretnym, i tak sformułować ustalenia, aby na kolejnej Retrospektywie można było ocenić, czy zostały one zrealizowane czy może potrzebna jest w ich dokończeniu pomoc. Przykładową techniką jest przygotowanie listy „Co, Kto, Kiedy”, czyli ustalenie, co jest w zakresie usprawnienia, kto za nie odpowiada oraz kiedy spodziewamy się jego realizacji.
7. Podsumuj zaplanowane usprawnienia — Ostatnim istotnym krokiem jest podsumowanie zaplanowanych ustaleń. Ponieważ rozmowy podczas Retrospektywy są często burzliwe i bardzo angażujące, może się zdarzyć tak, że pewne wątki umkną, zwłaszcza jeśli nie będzie stosowana wizualizacja. Przykładowa technika na tym etapie to poproszenie losowej osoby o podsumowanie swoimi słowami, jak rozumie świeżo stworzony plan usprawnieniowy.

Niby proste, a jak zawsze diabeł tkwi w szczegółach.

Na co zwrócić uwagę?

Struktura jest prosta, ale łatwo jest popełnić błędy w jej zastosowaniu. Trzy najbardziej newralgiczne punkty z mojej perspektywy opisałem poniżej.

Zacznij Retrospektywę od przeglądu zaplanowanych działań usprawniających (pkt. 1)

Ten punkt jest zwykle realizowany po łebkach. Dobrą praktyką jest rozpoczęcie Retrospektywy od przeglądu wcześniej zaplanowanych działań. Pozwala to jasno określić, które zadania są już zrealizowane, które są w trakcie realizacji, a które nadal czekają na wykonanie. Może się również okazać, że niektóre straciły ważność lub na skutek innych działań ich realizacja jest bezzasadna. Mocno rekomenduję, aby każda Retrospektywa w zespole rozpoczynała się od przejścia po ustalonych działaniach usprawniających.

Porządnie przeanalizuj problemy (pkt. 5)

Brak faktycznych usprawnień może prowadzić do komentarzy w stylu „tyle razy już próbowaliśmy i nigdy nam nie wyszło”. Istnieje sporo narzędzi, z których możesz skorzystać. Dyskusja w parach & grupach, diagram Ishikawy czy metoda 5W, to przykładowe możliwości.

Stwórz namacalny, sensowny plan (pkt. 6)

Działania ustalone jako efekt dobrze przeprowadzonej Retrospektywy Sprintu powinny być dobrze zaplanowane, aby było jasne, co konkretnie jest do zrobienia i w jakim czasie. Ponadto ważnym elementem planowania ich realizacji jest określenie, kto wykona dane działanie. Zwykle zespoły nie mają z tym problemu, jeśli tylko struktura spotkania tworzy ku temu okazję. Przydatna może być technika „Co, kto, kiedy”, która pomaga w uchwyceniu informacji istotnych dla wybranej czynności, np.: „Udostępnienie możliwość testowania produktu klientowi (co) zrealizuje Tomek (kto) do najbliższej środy (kiedy)”.

Podsumowanie

Dobra Retrospektywa Sprintu bazuje na przygotowanej, przemyślanej strukturze. Jeżeli Twoja Retrospektywa nie przynosi faktycznych usprawnień w zespole, zastanów się, na które punkty mógłbyś położyć większy nacisk.

Jeżeli patrzysz na te punkty i są dla Ciebie oczywiste — super, najpewniej Twój zespół regularnie się usprawnia.

Natomiast jeśli te kroki wydają Ci się nowe albo masz wrażenie, że mogą znacznie lepiej zadziałać w Twoim zespole, to sprawdź webinar „Porządna Retrospektywa Sprintu”. Webinar nauczy Cię używać w w praktyce powyższej struktury, dostaniesz konkretne instrukcje działania i sporo materiałów dodatkowych, które umożliwią Ci realizować skuteczne Retrospektywy.

Udanego usprawniania!

Opisuję jedną z pięciu najpopularniejszych pułapek zwinnych transformacji. To pułapka, w której zwinna transformacja nie jest priorytetem w organizacji. Efektem jest brak faktycznych efektów zmian.

Wpis ten otwiera serię artykułów “Pułapki zwinnych transformacji”, którą przeczytasz na moim blogu.

Jak rozpoznać pułapkę?

Istnieje kilka podstawowych objawów sytuacji, w której zwinna transformacja nie jest odpowiednio ważna dla organizacji.

• Pomimo iż cała firma odmienia słowo “agile” przez wszystkie dostępne przypadki, nie widać żadnych konkretnych działań.
• W komunikatach top-managementu wysyłanych do firmy, dostarczanych najróżniejszymi kanałami (np. spotkania, e-maile, broszury, rozmowy 1×1, rozmowy przy pizzy) nie ma mowy o zmianach w obszarze zwinności.
• Zwinna transformacja trwa już bardzo długo, jednak nie przynosi realnych korzyści dla klientów.

Żeby lepiej wytłumaczyć, co mam na myśli, podzielę się z Tobą dwoma historiami.

Pierwsza historia

Pracowałem z firmą, która deklarowała, że chce rozpocząć zwinną transformację. Powołana została grupa przewodząca zmianie, w której zasiadali managerowie z różnych obszarów firmy: finansów, HRu, biznesu, IT oraz kilka innych działów.

Osoba, która zarządzała firmą, dała zielone światło tej inicjatywie. W komunikatach pisanych oraz mówionych poświęcała zwinności dwa, trzy zdania, na zasadzie: “Jak wiecie, musimy być zwinni, bo przez to będziemy szybsi i będziemy dostarczać więcej wartości„.

I zaraz po tych dwóch zdaniach o zwinności, wymieniała jednym tchem, że mamy również projekt X, projekt Y, projekt Z, inicjatywę A, inicjatywę B oraz inicjatywę C. I że wszystkie te rzeczy są równie ważne, jeżeli chcemy osiągnąć sukces!

W konsekwencji grupa przewodząca zmianie stopniowo zaczynała słabnąć. Członkowie zespołu, zdekoncentrowani mnogością priorytetów, zaczęli spotykać się coraz rzadziej. Ich spotkania dawały coraz słabsze efekty. Zwinna transformacja stawała się coraz bardziej pozorna. Ostatecznie grupa przestałą się spotykać, co spowodowało, że zmiany wyhamowały niemal do zera.

Druga historia

Pracowałem z firmą, która deklarowała, że chce rozpocząć zwinną transformację. Powołana została grupa przewodząca zmianie, w której zasiadali top-managerowie, reprezentujący większość strukturalną firmy.

Głównym liderem zmiany był prezes firmy. Gdy opowiadał, czym jest zwinność, mówił o sile wartości, wadze feedbacku, konieczności bycia odważnym i potrzebie eksperymentowania. Przy każdej okazji akcentował, jak ważna jest ta zmiana i podkreślał jej istotność.

Po jego słowach, decyzjach i zachowaniu wyraźnie było widać, że zwinna transformacja ma strategiczne znaczenie dla firmy. Zmiana wyraźnie postępowała, obejmując kolejne obszary firmy.

Aktualnie firma jest już po serii znaczących eksperymentów ze zwinnością. Wiedzą, w jakiej klasie problemów zwinność może im pomóc. Podejście zwinne pomaga im funkcjonować w mocno zmieniającym zmieniającym się oraz konkurencyjnym otoczeniu biznesowym.

Poczucie pilności

Co różni te dwie historie?

John Kotter, ekspert zarządzania zmianą, powiedziałby najprawdopodobniej, że nie zostało zbudowane odpowiednie poczucie pilności (ang. sense of urgency).

Spójrz na poniższy rynek.

Żeby wytłumaczyć, czym jest poczucie pilności, zacznę od przeciwieństwa tego stanu, czyli stanu samozadowolenia (ang. complacency).

Samozadowolenie

Po czym poznać, że Twoja organizacja jest w stanie samozadowolenia? Kilka przykładów:

• W prasie branżowej czytasz kolejny artykuł o Waszych dotychczasowych sukcesach
• Na ścianach korytarzy i salek wiszą plakaty wzmacniające propagandę sukcesu
• Na spotkaniach Twoi koledzy i koleżanki podśmiechują się z konkurencji
• Nowinki techniczne traktujecie z przymrużeniem oka, bo akurat Twoja firma tego nie potrzebuje (jest wyjątkowa)
• Często słyszysz “Jest dobrze, ale zawsze mogłoby być gorzej”

Sztuczne poczucie pilności

Skoro wiesz już, czym jest samozadowolenie, czas na wytłumaczenie pojęcia poczucia pilności. Na początek, to udawane.

Po czym poznać, że Twoja organizacja generuje sztuczne poczucie pilności? Kilka przykładów:

• Twoi koledzy i koleżanki cały dzień spędzają na spotkaniach
• Ludzie wpadają w pośpiechu z jednego spotkania na drugie
• Osoby spóźniają się na spotkanie, tłumacząc to innym spotkaniem
• Masz 150 nieprzeczytanych wiadomości w skrzynce pocztowej
• Praca jest przerywana, bo pojawiają się rzeczy jeszcze pilniejsze od tych, które były pilne wczoraj
• Więcej przełączasz kontekst pracy, niż faktycznie pracujesz

Prawdziwe poczucie pilności

Kiedy mówimy o prawdziwym poczuciu pilności, myślimy o czymś, co jest dla nas najważniejsze.

Skupiamy się na jednym, kluczowym aspekcie, na którym chcemy się skoncentrować. Zwykle jest to rzecz, której jeśli nie zrobimy, to pozycja naszej firmy będzie zagrożona.

Przykładowo: wyobraź sobie, że na rynek polski wchodzi największy konkurent Twojej firmy. To globalny gracz, dysponujący potężnymi możliwościami finansowymi. Twoja firma nie jest przygotowana na jego ekspansję, więc istnieje realne ryzyko, że stracicie część rynku.

Poczucie pilności to wspólna świadomość pracowników organizacji na wszystkich szczeblach, że:

1. Problem jest prawdziwy
2. Zmiana jest nieunikniona
3. Konieczne jest wspólne działanie

Jak nadać priorytet zmianie?

Moje doświadczenia przy wspieraniu zwinnych transformacji są jednoznaczne: trudno przeprowadzić zmianę bez zbudowania poczucia pilności w organizacji.

Jak więc budować poczucie pilności? Poniżej kilka przykładów pomysłów, które stosuję w praktyce.

Kwestionuj status quo

Status quo to stan, który chcemy utrzymać. Żeby było tak, jak jest teraz. Pielęgnowanie statusu quo oznacza w praktyce, że wszelkie zmiany, pomysły oraz innowacje nie są podejmowane przez organizację.

Jeżeli nikt w organizacji nie kwestionuje tego stanu, trudno oczekiwać, że jakakolwiek zmiana się wydarzy. Nie mam też złudzeń co do priorytetu takiej zmiany.

Dobra wiadomość jest taka, że każdy może kwestionować obecny stan rzeczy.

Jak w praktyce kwestionować status quo?

• Wchodź w rolę adwokata diabła. Gdy wszyscy w pokoju mówią “tak”, bądź osobą, która powie “nie”. Przykładowo, gdy cały pokój zgadza się, że zadowolenie klienta jest na wyjątkowo satysfakcjonującym poziomie, na potrzeby dyskusji możesz się z tym nie zgodzić i wskazać organizacje, które osiągają lepsze rezultaty.
• Pokazuj alternatywną rzeczywistość. Konstruowanie wypowiedzi zaczynając się od formułki “A co by było gdybyśmy…” pozwala na roztaczanie wizji, która może okazać się kamieniem węgielnym pod nadchodzące zmiany. Przykładowo, “A co by było, gdybyśmy mogli udostępniać nową wersję produktu nie co rok, tylko raz na kwartał?”
• Bazuj na faktach. W organizacjach pielęgnując status quo, zwykle mało się mówi o faktach, bo mogą one wskazywać na to, że zmiana jest nieunikniona. Dobry zestaw faktów potrafi rozgrzać atmosferę w pokoju. Przykładowe fakty: liczba rozwiązanych umów przez niezadowolonych klientów w tym miesiącu, aktualna liczba błędów na środowisku produkcyjnym czy spadkowy trend przychodów ze sprzedaży usług.

Wspieraj transparentność

W zależności od organizacji, określenie “transparentność”, może mieć różne znaczenie. W tym przypadku mam na myśli zapewnianie, że wszystkie osoby, które powinny mieć dostęp do konkretnej informacji, uzyskują rzetelną informację na temat tego, “jak faktycznie jest”.

W jednej z firm, w której pracowałem, zarząd zadecydował, że połowa zespołów programistycznych będzie pracować na superważnym projektem. Jeden z managerów postanowił sprawdzić, czy tak faktycznie jest. Odwiedził wszystkie zespoły sprawdzając, czym aktualnie się zajmują. Po przeprowadzeniu tournée po całej firmie wrócił do zarządu z zagadką.

Na spotkaniu z zarządem pokazał im na palcach cyfrę jeden i zapytał:

Czy wiecie, co oznacza ta cyfra?

Zarząd odpowiedział:

Hmm, to nie możliwe, że tylko jeden zespół pracuje nad naszym superważnym projektem.

Manager odpowiedział im:

Otóż nie. Na ten moment tylko jedna osoba w firmie faktycznie zajmuje się tym superważnym projektem. Wszystkie inne osoby “prawie to robią”, “tylko skończą jedno zadanie i się tym zajmą” lub “skupią się na tym, jak tylko poprawią błąd na produkcji.

Historia ta pokazuje, jak wygląda transparentność w praktyce. Wymaga nakładu pracy, zebrania danych oraz odwagi, żeby powiedzieć, jak jest na prawdę.

Zatrudnij zewnętrznego konsultanta zwinności

Osoba z zewnątrz organizacji spojrzy na Twoją firmę bez emocji, uwikłań politycznych oraz da świeży obraz rzeczywistości. Często taka szczera opinia z zewnątrz potrafi być jednym z impulsów do przeprowadzenia zmiany. Dodatkowo, konsultant-praktyk, który dedykuje od lat swoje życie zawodowego na zgłębianie zwinności, ma wiedzę oraz doświadczenie, które może pomóc Ci uniknąć wiele kosztownych błędów.

Kilka lat temu zadzwonił do mnie manager międzynarodowej organizacji z pytaniem, czy jestem w stanie spojrzeć z boku na to, jak używają zwinności i dać im informację zwrotną wraz z rekomendacjami usprawnień i dalszych kroków.

Spędziłem w tej firmie kilka dni, rozmawiając z najważniejszymi managerami procesu wytwarzania produktu oraz obserwowałem, jak pracują zespoły. Gdy spędzałem czas z zespołami, nie wtrącałem się w ich prace, nie komentowałem, tylko świadomie patrzyłem na wszystko z boku. Pozwoliło mi to uchwycić w niezakłóconej formie to, jak faktycznie pracują.

Te kilka dni rozmów i obserwacji zamknąłem spotkaniem z top-managementem, na którym przedstawiłem im pisemny raport z obserwacji. Spotkanie to uruchomiło złożony proces zmian, których celem było takie usprawnienie procesu wytwarzania, aby rozwiązania dla klientów były dostarczane szybciej oraz w wyższej jakości.

Jak powtarzał mój znajomy Agile Coach w jednej z firm, „Trudno być prorokiem we własnej wiosce„. Często wybrane osoby w organizacji mają wystarczającą wiedzę, aby nadać poczucie pilności zmiany, jednak nie są wysłuchiwani przez zarządzających organizacją. W takich przypadkach warto skorzystać z eksperta spoza organizacji, który zwykle ma większy autorytet, wynikający z doświadczenia i pozycji na rynku.

Chciałbym, żeby to wybrzmiało wprost: zatrudnienie zewnętrznego konsultanta może pomóc dostarczyć bodziec, ale nie zagwarantuje, że organizacja zacznie się zmieniać. Bez woli, skupienia oraz zaangażowania osób decyzyjnych w firmie, nie ma co oczekiwać spektakularnych rezultatów.

Podsumowanie

Prowadzenie zwinnej transformacji wymaga nadania jej odpowiednio wysokiego priorytetu i uzyskania uwagi top-managementu. Warto zwrócić uwagę na stan, w jakim aktualnie znajduje się Twoja organizacja, zwracając szczególną uwagę na stan samozadowolenia lub sztucznego poczucia pilności.

Photo by Christopher Rusev on Unsplash

Omówione tematy

• Czym jest zwinność?
• Jak planować w podejściu zwinnym?
• Kim jest Scrum Master i czym się różni Scrum Master od Project Managera?
• Jakie są zagrożenia mechanicznego Scruma?
• Jak przestawić głowę z myślenia o procesach na myślenie o ludziach i interakcjach?
• Jak wygląda wprowadzenia zwinności do organizacji?
• Czy zwinność to projekt do realizacji czy raczej nieustanny proces usprawniania się?
• Jak może wyglądać udana praca zdalna w czasie pandemii?
• Jak wyglądał i wygląda rynek pracy?
• Czy agile może być kiedyś wiodącym podejściem wdrażanym do organizacji pracy w całym przedsiębiorstwie?
• Dlaczego warto odwiedzić portal agile247.pl?

Najciekawsze cytaty

„Zwinność to sposób pracy który pozwala dostarczać więcej wartości w krótszym czasie”

„Scrum Master naoliwia koła zębate, czyli zapewnia, że współpraca Product Ownera oraz Zespołu Deweloperskiego przebiega w jak najbardziej płynny i efektywny sposób”

„Scrum Master pracuje z całą organizacją nad tym, żeby ta była w stanie w efektywny sposób wykorzystać zwinność”

„Zmiana tylko po to, żeby przemalować etykiety i być w zgodzie z nurtem zwinnym, ale bez zrozumienia po co to robimy, jest wysoce nieskuteczna i frustrująca dla ludzi”

„Sensownie jest najpierw odpowiedzieć sobie na głębokim poziomie, dlaczego i po co chcemy przeprowadzać zwinną transformację”

„Zwinność to droga poszukiwania lepszych sposobów pracy, nie ma punktu końcowego na tej drodze, w którym już jesteśmy zwinni. […] Zawsze można zrobić coś szybciej, lepiej rozumieć problemy klientów, szybciej eksperymentować w poszukiwaniu lepszych rozwiązań”

„Człowiek jest i długo jeszcze będzie w centrum. Czynnik ludzki nadal będzie determinował sukcesy bądź porażki produktów, usług lub czegokolwiek, co wytwarzamy”

„Im bardziej działamy w złożonym środowisku […] tym bardziej moglibyśmy zainspirować się podejściem zwinnych – eksperymentowaniem, robieniem małych kroków, zastanawianiem się, gdzie jest wartość, wchodzić w interakcję z klientem, tworzyć krótkie pętle informacji zwrotnej”

Cały odcinek do odsłuchania

Relacja klient – dostawca

Gdy piszę o relacji klienta i dostawcy, mam na myśli współpracę, która:

• Opiera się na podpisanej umowie (np. typu fix, time & material lub hybrydy tych umów) pomiędzy dwoma firmami
• Dotyczy realizacji produktów od zera (np. firma budująca produkt pod konkretny zamówienie klienta), jak również sprzedaży produktów w wersji bazowej (np. ERP, CRM, silnik sklepu e-commerce) wraz z usługą dopasowania lub rozbudowania ich pod potrzeby konkretnego klienta

Firmę, która wytwarza produkt pod zamówienie nazywam software house’m, a odbiorcę tego produktu – klientem.

Jak sprzedawać agile przed podpisaniem kontraktu?

Poniżej zebrałem kilka strategii, z których korzystam, gdy wspieram budowanie kultury zwinności w organizacjach pracujących z klientami zewnętrznymi.

1. Sprzedawaj korzyści, nie Scruma

Mówienie klientowi „pracujemy Scrumem” niewiele daje. Wiem, bo sam popełniałem ten błąd, rozmawiając w ten sposób z klientami. Gdy tylko jednak zaczynałem mówić o korzyściach, moi rozmówcy zwykli entuzjastycznie reagować. Naucz się sprzedawać korzyści, które stoją za zwinnym dostarczaniem oprogramowania, używając jak najmniej słów branżowych jak to tylko możliwe.

Przykładowo, lepiej powiedzieć klientowi, że będzie co tydzień dostawał lepszą wersję swojego produktu, niż opowiadać, że zespół będzie pracować w Sprintach.

2. Wytłumacz złożoną naturę software developmentu

Wytwarzanie oprogramowania to najczęściej wkroczenie na obszary o dużej złożoności (ang. complexity). Im mniej precyzyjnie wiesz, co dokładnie ma być efektem prac oraz im mniejsze masz doświadczenie w realizowaniu podobnych produktów, tym bardziej wchodzisz do świata, w którym więcej jest niewiadomych, niż wiadomych.

Przykładowo, możesz w trakcie rozmów z klientem wprowadzić pojęcie stożka niepewności (ang. cone of uncertainty), żeby wytłumaczyć problem precyzyjnego określania „kiedy będzie gotowe”.

3. Pokaż klientowi case study

Dobrze przygotowane case study, oparte na faktach i realnych wynikach, ma spory potencjał w rozmowach z klientem. Warto rozsądnie dobierać przykłady, aby skutecznie trafiały one do konkretnego klienta.

Przykładowo, jeżeli klient pracuje w branży finansowej, lepiej jak pokażesz mu case study dużego banku niż firmy typu e-commerce.

4. Zdobądź rekomendacje od klientów

Według badania Mckinsey’a, od 20% do 50% decyzji zakupowych wynika z polecenia innych osób. Dobrze przygotowane, personalizowane rekomendacje to moim zdaniem jeden z filarów marketingu software house’ów.

Przykładowo, możesz poprosić klienta o odniesienie się w rekomendacji do tych aspektów, które są spójne z obietnicami na stronie internetowej Twojego software house’u. Efekt jaki będziesz budował taką rekomendacją, to „ta firma dostarcza to, co obiecuje”.

5. Użyj danych z raportów

Są klienci, do których trafiają dane liczbowe. W internecie dostępne są raporty dotyczące zwinności, którymi możesz się podeprzeć w trakcie rozmów z klientami.

Przykładowo, według raportu State of Agile z 2018 roku, drugą najważniejszą korzyścią wskazywaną przez 65% ankietowanych jest zwiększenie przejrzystości prac. Dobrze realizowana praca w Scrumie daje sporo transparentności, jeśli oczywiście nie wpadasz w popularne pułapki.

6. Przygotuj zestawienie porównawcze podejścia zwinnego i podejścia klasycznego

Łatwiej jest tłumaczyć nowe pojęcia, gdy możemy operować porównaniem. Na temat różnic w podejściu klasycznym (inne nazwy: kaskadowe, waterfall’owe, big-bang) istnieje cała masa materiałów w internecie. Argumenty przemawiające za zwinnością są mocne i trudno je kwestionować, przy czym jako software house musisz mieć pewność, że będziesz w stanie „dowieźć” obietnicę tego, że potrafisz pracować w faktycznie zwinny sposób.

Przykładowo, możesz zainspirować się jak opowiadać o różnicach w podejściu klasycznym i zwinnym na bazie mojej nagranej prezentacji The forgotten promise of agile development, którą wygłosiłem dla pracowników i klientów software house’u STX Next w 2015 roku. Dostępne są też slajdy po polsku.

7. Pokaż metryki jako dowód

Lubię używać metryk, bo pokazują one, jak faktycznie potrafimy sobie radzić z procesem wytwarzania oprogramowania. Warto zbierać metryki w zespołach – przydadzą się one zarówno zespołom (np. jako wkład do retrospektywy) jak i klientom zewnętrznym (np. jako część prezentacji pokazującej jak pracujemy)

Przykładowo, jeżeli klient wskazuje na to, że zwykle software house’y miesiącami „nad czymś pracowały, ale efektów nie było widać„, możesz pochwalić się metryką pokazującą, ile średnio czekają Twoi klienci, aby otrzymać pierwszy przyrost produktu. Jeżeli oczywiście faktycznie pracujesz w krótkich Sprintach.

8. Zaproponuj darmowy Sprint

Z kilkoma klientami zewnętrznymi stosowałem metodę „try before buy”. Klient dostawał opcję zrealizowania darmowych Sprintów, które pozwalały mu zdecydować, czy chce dalej z nami pracować. Opcjonalnie, można umówić się z klientem, że zapłaci za Sprinty wyłącznie wtedy, gdy będzie zadowolony z efektów pracy.

Przykładowo, możesz zaproponować klientowi dwa darmowe Sprinty, które zespół wykorzysta, aby przekonać namacalnymi rezultatami pracy, że warto z pracować z Twoim software house’m.

9. Nie przekonuj klienta do zwinności

Na koniec alternatywna strategia, na którą mogą sobie pozwolić software house’y posiadające dobrą sytuację finansową. Polega na tym, że nie przekonujesz klienta do podejścia zwinnego, jeżeli dysponujesz silnymi sygnałami wskazującymi, że dojście do porozumienie z klientem będzie Cię kosztować zbyt wiele.

Przykładowo, jeżeli pierwsze rozmowy z klientem wskazują na to, że występuje duże niedopasowanie, jeśli chodzi o kulturę, oczekiwania i filozofię pracy, nie warto przechodzić do dalszych etapów. Taka współpraca może być bardzo bolesna (np. pracownicy zaczną odchodzić do innych firm) i nie warta wystawianej faktury.

Podsumowanie

Istnieje grupa klientów, których przekonanie do pracy zwinnej będzie wymagało sporej pracy. Opisałem kilka sprawdzonych strategii wraz z przykładami, które pomogą Ci inspirować Twoich klientów zwinnością już na etapie procesu sprzedażowego.

Potrzebujesz pogłębić powyższe strategie?

Który temat jest dla Ciebie najbardziej interesujący i dlaczego? Napisz mi o tym w komentarzu. Być może rozwinę go do oddzielnego artykułu.

Jeżeli chcesz w przepracować temat pracy zwinnej w klientami zewnętrznymi w formule warsztatowej, zapisz się na moje warsztaty online Scrum dla software house’ów, które odbędą się 15-16 czerwca 2020 roku.

Jeśli natomiast potrzebujesz dedykowanych konsultacji z obszaru zwinności oraz Scruma w realiach software house, skontaktuj się ze mną i porozmawiajmy, czy i jak mogę wesprzeć Twój software house.

Źródło zdjęcia: Photo by Chris Liverani on Unsplash

Dwa główne powody to:

• określenie „Agile Coach” traci swoje pierwotne znaczenie
• chcę świadomie budować moją markę osobistą

Poniżej kilka słów komentarza do obu punktów.

Określenie „Agile Coach” traci swoje pierwotne znaczenie

W czym problem? Agile Coach może oznaczać dzisiaj wszystko i nic.

Dla jednego Agile Coach to po prostu „senior Scrum Master”, dla drugiego to osoba pracująca z organizacją nad transformacją, inny powie, że to alternatywna nazwa na Scrum Mastera.

Nie będę dogłębnie opisywał jak rozumiem rolę Agile Coacha, bo zrobiłem to w odcinku „Kto to jest Agile Coach” podcastu „Porządny Agile”. Dodatkowo, pisali o tym m.in. Kuba i Stanisław na swoich blogach. Krótko mówiąc: problem związany ze zrozumieniem tej roli istnieje i moim zdaniem będzie się pogłębiał.

Druga sprawa – słowo „coach” w nazwie. Całkiem rezonuje ze mną model przygotowany przez Agile Coaching Institute, które pokazuje obszar kompetencji Agile Coacha:

Jak widać, umiejętności coachingowe (Professional Coaching) są częścią kompetencji Agile Coacha. Wiem też z własnej praktyki, że umiejętności coachingowe przydają się w codziennej pracy.

Niemniej, wyraz „coaching” przybiera od lat bardzo pejoratywne znaczenie i jest to zasługa całej masy magików, komunikujących, że „możesz wszystko” i „żeby coś zmienić w swoim życiu… musisz coś zmienić w swoim życiu”. Trochę to śmieszne, trochę to straszne i nie chciałbym mieć z tym zbyt wiele wspólnego.

Nie mam kontroli nad tym, jak definiowana jest rola Agile Coacha i jak kształtuje się ona w Polsce i na świecie. W świadomy sposób, coraz rzadziej mówię i piszę o sobie „Agile Coach”, aby uniknąć uproszczenia i błędnego zidentyfikowania tego, co robię i jak robię.

Moja marka osobista

Dodatkowym aspektem, który wpłynął na zmianę, jest fakt, że nie wiem co będę robił za 5-10 lat. Chciałem, żeby adres mojego bloga był odporny na upływ czasu.

Dlaczego taka domena? Marka osobista to coś, co zawsze będzie ze mną. Moje imię i nazwisko będzie gwarancją określonego zestawu wartości, kompetencji oraz doświadczeń.

I to niezależnie od tego, jaką nazwiesz moją rolę w organizacji. Nieważne w jakiej konfiguracji pracuję z klientami, nieważne jak nazywają mnie w swoich firmach (Agile Coach, Agile Master, coach zwinności, konsultant agile…), to na koniec dnia pracuję na swoje nazwisko.

Na orbicie mojej marki krążą się różne inicjatywy, które stworzyłem sam (książka) lub współtworzę z innymi osobami (podcast, portal o zwinności). To różnorodne produkty, zbudowane w różnych konfiguracjach osobowych, które posiadają dwa wspólne mianowniki: dotyczą zwinności oraz jestem częścią tych produktów.

Zmiana domeny do domknięcie większego tematu. Jakiś czas temu zmieniałem szablon bloga, dodałem też stronę startową. Przeniesienie bloga na nową domenę domknęło tę inicjatywę. Po wielu latach dodałem też w końcu SSL.

Podsumowanie

Zmieniłem adres strony agilecoaching.pl na jacekwieczorek.pl. Cała reszta pozostaje bez zmian. Będę pisał o tym, co dotychczas. Zmiana wydaje się kosmetyczna, jednak chciałem, aby kontekst był dla czytelników jasny.

Photo by Ludovic Fremondiere on Unsplash

Przez ostatnie kilka lat, mniej lub bardziej świadomie, budowałem swoją listę sygnałów ostrzegawczych. Pomagają mi one dokonać oceny potencjału toczącej się zmiany. Jest to dla mnie wsad do głębszej analizy sensu i wartości płynącej z kontynuacji mojego zaangażowania w zmianę.

Im więcej odbieram sygnałów ostrzegawczych, tym częściej poddaję analizie toczącą się transformację. Dodatkowym aspektem jest dla mnie kolor tych sygnałów — stosując analogię do świateł drogowych, lekki pomarańcz to póki co delikatne ostrzeżenie, natomiast mocny czerwony to bardzo konkretny sygnał.

Nie jest to oczywiście kompletna lista, a raczej kilka najważniejszych dla mnie aspektów, których miałem okazję wielokrotnie doświadczyć w praktyce. Oto ona, bez jakiejś konkretnej kolejności.

• Zwinność nie jest priorytetem w organizacji – W komunikatach top-managementu wysyłanych do firmy, dostarczanych najróżniejszymi kanałami (np. spotkania, e-maile, broszury, rozmowy 1×1, rozmowy przy pizzy) nie ma mowy o zmianach w obszarze zwinności. Z mojego doświadczenia, analiza tych komunikatów daje całkiem jasny obraz tego, co jest ważne w najbliższym horyzoncie dla firmy.
• Zmiana nie posuwa się wyraźnie do przodu – Wszystkie aktywności związane z procesem przeprowadzania zmiany (np. komunikacja, usprawnienia, zmiany organizacyjne, szkolenia) toczą się bardzo powoli lub wcale. Brałem udział w wielu zwinnych transformacjach, prowadząc je lub wspierając jako konsultant zewnętrzny, stąd jest we mnie dużo zrozumienia i poszanowania dla indywidualnego tempa zmian w firmie. Niemniej, istnieje pewien niski poziom tempa zmiany, który z mojej perspektywy jest sygnałem ostrzegawczym, że coś dzieje się nie tak.
• Zmiana przeprowadzana jest bardzo powierzchownie – Jest to szczególny przypadek poprzedniego punktu. Pozornie, zmiana się toczy. Gdy jednak przyjrzeć się dokładniej faktom to okazuje się, że na poziomie mających znaczenie detali zmiany są płytkie, kiepskiej jakości i w dłuższym horyzoncie nie prowadzą do odczuwalnych usprawnień.
• Brak przywództwa zmiany – Nie wiadomo, kto jest liderem zmiany. Brakuje osoby będącej twarzą toczących się usprawnień. Gdy zapytasz kilka losowych osób o wskazanie, kto jest liderem zmiany, otrzymasz różne odpowiedzi. Na korytarzach i w kuchniach organizacji słychać coraz więcej pytań o to, z kim rozmawiać o bieżących problemach transformacji. Z perspektywy zewnętrznego konsultanta chcę wiedzieć, z kim powiniennem rozmawiać i dzielić się obserwacjami, przemyśleniami oraz informacją zwrotną.
• Zmiana toczy się pod wpływem impulsów zewnętrznych – To, czy zmiana się toczy, zależy wyłącznie od mojego zaangażowania. Jestem inicjatorem rozmów, zmian oraz usprawnień. Gdy świadomie robię krok do tyłu, z organizacji nie wyłania się ani osoba, ani grupa, która mogłaby realnie przejąć inicjatywę. Rozmowy o tym problemie nie przynoszą namacalnych rezultatów.
• Brak łatwego dostępu do osób decyzyjnych – Osoby decyzyjne w organizacji są zajęte pracą operacyjną a ich kalendarze są zarezerwowane na kolejne dni i tygodnie do przodu. Rozmowy dotyczące zmiany toczą się w biegu, na korytarzu, tak jakby tylko przy okazji. Nie ma przestrzeni, żeby spotkać się z osobami z mocą sprawczą w organizacji w jednym pokoju, w celu przedyskutowania bieżącego stanu toczącej się zmiany. Z mojej perspektywy prowadzi to do sytuacji, w której zmiana nie jest zarządzana.
• Brak gotowości na poniesienie kosztów na przeprowadzanie zmiany – Organizacja jest zainteresowana korzyściami płynącymi z podejścia zwinnego, jednak założenie jest takie, że zmiana będzie odbywała się bez kosztowo. Nie ma budżetu między innymi na rozwój kompetencji wewnątrz organizacji, wsparcie zewnętrznych ekspertów, zakup narzędzi, przeprowadzenie usprawnień czy przeorganizowanie przestrzeni pracy zespołów.
• Zmiany nie dotyczą całej organizacji – Zmiany odbywają się wyłącznie w wąskich, wybranych obszarach organizacji. Nikt nie patrzy przekrojowo na sposób pracy, stąd większość usprawnień ma charakter wyłącznie lokalny. Przykładowo: zmiana toczy się od wielu miesięcy wyłącznie w obszarze IT, z kompletnym pominięciem zespołów/działów/departamentów biznesowych. Tak jak całym sobą podpisuję się pod zaczynaniem transformacji od małych usprawnień, które mogą startować lokalnie, tak uważam, że długofalowy brak holistycznego spojrzenia na organizację jest ryzykowną ścieżką.
• Ludzie, którym “się chce”, odchodzą – Osoby, które były wyraźnie zainteresowane wspieraniem zmiany, odchodzą z firmy. Nie jest to zwykle decyzja, którą podejmują z dnia na dzień, a raczej pewien proces, który budowany jest na zawiedzionych nadziejach, kolejnych odmowach (“nie da się”, “pomyślimy”, “zobaczymy”) i rozczarowaniach związanych ze zmianą. Z moich obserwacji są to zwykle osoby, które oddały cząstkę siebie, zaangażowały się, a w rezultacie nie zobaczyły satysfakcjonujących efektów.

Ważna uwaga: z wszystkimi tymi tematami można i warto pracować. To, że np. dzisiaj zmiana nie posuwa się do przodu nie oznacza, że tak będzie już zawsze. W każdym z wymienionych obszarów podejmuję zwykle wielokrotne podejścia do zmiany aktualnego stanu rzeczy — w różnym punkcie czasu, angażując w to różne osoby, podchodząc do tematu różnymi sposobami.

Tematem na oddzielny wpis jest natomiast sytuacja, gdy po niezliczonej ilości prób, ogólny stan rzeczywistości nie ulega zmianie — w takiej sytuacji zaczynam zastanawiać się, czy moje zaangażowanie jako zewnętrzny konsultant przynosi wartość i czy długoterminowo widzę w tym działaniu sens.

Jestem ciekawy, na jakie aspekty Wy zwracacie uwagę. Zachęcam do dyskusji.

Źródło zdjęcia: Photo by Carlos Alberto Gómez Iñiguez on Unsplash

Zanim pomyślisz “Ileż można o tych Sprintach! Ten Wieczorek już kompletnie zatracił się w tych swoich labiryntach…”, poczekaj chwilę :)

W tym wpisie, będę się posługiwał zwrotem “Design Sprint”, mając na myśli Sprint w rozumieniu książki Jake’a Knapp’a, a nie Sprint, będący częścią frameworka Scrum.

Co to jest “Design Sprint” wg. Jake’a Knapp’a?

W dużym uproszczeniu, Design Sprint to koncepcja, która pozwala w pięć dni rozwiązać dowolny problem biznesowy.

Jakie rozwiązania mam na myśli? Przykładowo: robot obsługujący gości hotelowych, klinika medyczna przyjazna dzieciom czy raport pozwalający specjalistom onkologii podejmować decyzje dotyczące leczenia pacjenta, to przykładowe prototypy rozwiązań opisanych w książce.

Jak widać są to prototypy rozwiązujące problemy zróżnicowanych branż, co jest mocnym atutem Design Sprintu. Podobnie jak dzisiaj Scrum, Design Sprint promowany jest jako narzędzie działające niezależnie od tego, co jest naszym produktem.

Z czego składa się Design Sprint?

Rozkładając Design Sprint na konkretne dni, wygląda to następująco:

Na początku tygodnia definiujemy problem, pracujemy nad nim przez kolejne dni, aby w piątek testować prototyp z potencjalnymi klientami naszego rozwiązania.

1. W poniedziałek definiujemy problem biznesowy
2. We wtorek przygotowujemy potencjalne rozwiązania problemu
3. W środę definiujemy plan działania i realizacji prototypu
4. W czwartek budujemy prototyp rozwiązania
5. W piątek przeprowadzamy wywiady z użytkownikami, którym pokazujemy prototyp

Dlaczego trafia do mnie “Sprint”?

Nie muszę chyba pisać stałym czytelnikom, jak bardzo rezonują ze mną tego rodzaju koncepcje. Krótkie iteracje, szybkie dostarczanie wartości, product discovery to obszary, na które zwracam szczególną uwagę w swojej codziennej pracy z klientami.

Przykładowo — ostatnio, w ciągu jednego dnia pracy z top-managementem firmy kompletnie nie związanej z IT, zrealizowałem trzy 120-minutowe Sprinty. Była to odpowiedź na potrzebę “praktycznego doświadczenie Scruma na realnym przykładzie”. W efekcie pracy uzyskaliśmy przyrost realnego produktu, który na koniec dnia został omówiony z pracownikami firmy (interesariuszami) na sesji Przeglądu Sprintu.

Dlaczego podałem ten przykład? Propozycja twórcy “Sprintu” brzmiąca: “w pięć dni przejdź od problemu do testu prototypu rozwiązania z klientem” nie jest dla mnie wywróceniem świata do góry nogami. Jest jednak dla mnie świetnym uzupełnieniem sposobu myślenia oraz posiadanego wachlarza technik oraz podejść. Ilość przykładów, metafor oraz głębia omówienia tego, jak budować prototypy zaciekawiła mnie na tyle, że zdecydowałem się napisać ten krótki artykuł.

Nie będę opisywał krok po kroku treści książki. Zainteresowanych jak działa Design Sprint w detalach (dzień po dniu, krok po kroku) odsyłam na stronę książki. Dodam tylko, że oprócz samej idei Design Sprintu, autorzy przemycają masę wskazówek moderacyjnych, które można od ręki wykorzystać w pracy. Jeśli na codzień wchodzisz w rolę facylitatora, na przykład jako Scrum Master, Agile Coach czy lider — zdecydowanie polecam przeczytać.

No dobrze, to co z tymi prototypami?

Wracając do tematu prototypów. Moje trzy najważniejsze lekcje, które wynoszę w tym temacie po przeczytaniu książki to:

1. Konieczna jest zmiana mentalna i oduczenie się “starego” sposobu myślenia. Zbudowanie prototypu rozwiązania wymaga zmiany tego, jak myślimy o wykonywaniu pracy. Minimalizm zamiast perfekcji. Tymczasowe rozwiązanie zamiast docelowego. Myślenie “tu i teraz” zamiast myślenia długofalowego. W ten oto sposób “nie da się” w praktyce zamieniamy na “da się”. Przykładowo, klikalny prototyp aplikacji można sprawnie przygotować w PowerPoincie/Keynocie, produkty fizyczne można na szybko wydrukować w 3D, a prototyp fizycznej przestrzeni (np. biuro, sklep, lobby) można niedużym kosztem czasowym prowizorycznie przygotować, modyfikując istniejącą przestrzeń.
2. Iluzja produktu jest wystarczająca, aby przeprowadzić test z użytkownikami. Budynki w westernach z zewnątrz wyglądają na prawdziwe, ale tak naprawdę to tylko fasada: zwykle wyłączanie imitacja ściany frontowej. Pomimo tego, wciągamy się w scenariusz, a wrażenie budowane przez fasady jest wystarczające na potrzeby filmu. Podobnie jest z naszym produktem — potrzebujemy do testów wyłącznie fasady, iluzji oraz pozorowania, które sumarycznie zbudują wystarczające dobre wrażenie realizmu, pozwalające nam przeprowadzić test z użytkownikiem. Zbyt mało realistyczny prototyp nie wystarczy, żeby przekonać użytkowników, że to prawdziwy produkt. Zbyt mocno szczegółowy prototyp to z kolei zbyt duża inwestycja czasowa. Szukamy czegoś po środku, co będzie wystarczająco dobre i nic ponad to.
3. Szybkie budowanie i testowanie prototypów chroni nas przed emocjonalnym związkiem z potencjalnym rozwiązaniem. Im dłużej pracujemy nad prototypem rozwiązanie, tym bardziej czujemy się z nim związani. Ma to negatywny wpływ na percepcję rezultatów z testów. Nasza mentalność zmienia się wraz z upływem czasu — im dłużej spędzamy czas nad rozwiązaniem, tym bardziej prawdopodobne jest myślenie, że to nie rozwiązanie jest błędne/do poprawy, tylko “nasi klienci tego nie rozumieją”.

Podsumowanie

Przygotowanie prototypu rozwiązania problemu biznesowego pozwala szybko przekonać się, czy pomysł jest właściwy. Umożliwia w krótkim czasie i niewielkim kosztem zdobyć wiedzę, która pomaga podjąć decyzję, czy warto realizować pomysł.

Zdecydowanie jest to wiedza, którą warto zdobyć, w szczególności, gdy pracujemy w rolach produktowych (Product Manager, Product Owner), a także gdy jesteśmy osobami decyzyjnymi w dowolnego rodzaju biznesie.

Photo by José Alejandro Cuffia on Unsplash

“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

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”?