Pragmatycznie o… tym, jak przestać gasić pożary w firmie IT

Wprowadzenie

Cześć! W dzisiejszym odcinku opowiem wam pragmatycznie o tym, w jaki sposób efektywnie zarządzać zmianą w organizacji. Opowiem wam między innymi o tym, w jaki sposób udało nam się wyjść z poważnego kryzysu w Pragmatic Coders. Podzielę się z wami narzędziami, które wykorzystywaliśmy do tego, żeby monitorować procesy w naszej firmie, w jaki sposób sprawiliśmy, że prawie stuosobowa firma nagle zaczęła pracować zgodnie ze standardami, które jej narzuciliśmy, co było potrzebne do tego, żeby nowi ludzie, którzy przychodzą do naszej firmy, również pracowali zgodnie z tymi standardami w taki sposób, byśmy mogli tę firmę faktycznie skalować i rosnąć w ustrukturyzowany sposób, a nie po prostu pozwalać, by chaos zaczął znowu rządzić wzrostem organizacji. W tym podcaście dzielę się z wami doświadczeniami z kilkunastu lat budowania produktów i prowadzenia biznesów o wielomilionowych przychodach. Pragmatycznie – to podcast dla tych, którzy chcą wiedzieć, jak naprawdę wygląda prowadzenie biznesu i budowanie produktów cyfrowych bez lukru, bez ściemy i bez marketingowego.

Początki kryzysu w Pragmatic Coders

Kilka lat temu w Pragmatic Coders mieliśmy dosyć duży kryzys. Mieliśmy problemy z tym, w jaki sposób nasze zespoły pracują dla naszych klientów. Cały czas pojawiały się jakieś problemy, pojawiały się jakieś eskalacje od klientów. My, jako osoby zarządzające firmą, musieliśmy bardzo często reagować, bardzo często interweniować w pracę zespołów i pomagać tym zespołom dostarczać oprogramowanie, dostarczać produkty lepszej jakości, zgodnie z oczekiwaniami naszych klientów. To była bardzo trudna sytuacja i to była bardzo nieefektywna sytuacja dla nas, która w zasadzie blokowała jakikolwiek wzrost naszej organizacji. Wtedy postanowiliśmy coś zmienić. Postanowiliśmy zmienić to, w jaki sposób firma funkcjonuje. Postanowiliśmy usystematyzować pracę w całej firmie, przeprowadzić tak naprawdę transformację tej firmy. Sytuacji, w której działaliśmy w sposób troszeczkę chaotyczny, w taki sposób, jak każdy sobie wymyślił, że będzie pracował, do sposobu, który będzie ustandaryzowany, ustrukturyzowany, który też będzie ustrukturyzowany zgodnie z najlepszymi praktykami wytwarzania oprogramowania czy też najlepszymi praktykami zarządzania wytwarzaniem oprogramowania, czyli metodykami zwinnymi.

Kto odpowiada za zarządzanie zmianą?

Jeśli mowa o zarządzaniu zmianą, o transformacji organizacji, to w pierwszej kolejności wypadałoby sobie zadać pytanie: kto tak naprawdę w twojej firmie jest odpowiedzialny za zarządzanie transformacją, za zarządzanie zmianą? I teraz możecie zapauzować sobie to wideo na chwilkę i się nad tym zastanowić, zanim odpowiem na to pytanie. Żeby dać wam pewną podpowiedź, która pomoże wam prawidłowo odpowiedzieć na pytanie, kto jest odpowiedzialny za zarządzanie zmianą, za zarządzanie transformacją w organizacji, przytoczę cytat pewnego izraelskiego fizyka, który okazał się być także świetnym menedżerem i osobą, która wniosła bardzo dużo do współczesnych metod zarządzania projektami, czy też produktami, czy firmami ogólnie. Mowa tutaj o Goldratcie, o Eliyahu Goldratcie: „Zarządzanie polega na tym, by wiedzieć, co zmienić, w co zmienić i jak wykonać zmianę”. W zasadzie mówimy tutaj o, jakby nie było, jakiejś zmianie w firmie, o transformacji. Goldratt powiedział, że dokładnie na tym polega zarządzanie. Czyli kto w takim razie jest odpowiedzialny za zmianę w organizacji? Oczywiście, nie są to zewnętrzni konsultanci, nie są to scrum masterzy, nie są to programiści, nie są to product ownerzy i nie są to też agile coachowie. Za zmiany w organizacji odpowiedzialne są osoby, które tą organizacją zarządzają. No dobrze, to nawiązując do tego cytatu z Goldratta: co zmienić, w co zmienić, jak wykonać zmianę? Spójrzmy na naszą sytuację. Kilka lat temu w Pragmatic Coders byliśmy w kryzysie. Pracowaliśmy w sposób chaotyczny. Każdy zespół, każdy projekt był prowadzony tak, jak ludzie potrafili najlepiej, w taki sposób, jak umieli. Starali się oczywiście wszyscy, żeby robić to najlepiej, jak się da. Niestety, nie zawsze to działało – czasami działało, czasami nie. Mając kilka projektów prowadzonych równolegle, w momencie kiedy gdzieś coś wybuchało, zaczynaliśmy tam reagować, zaczynaliśmy to porządkować. Ledwo zdążyliśmy w jednym miejscu coś posprzątać, za chwilę okazywało się, że jakiś inny projekt wybucha i w zasadzie nasza praca, jako osób zarządzających firmą, polegała tylko i wyłącznie na tym, że cały czas gasiliśmy gdzieś jakieś pożary.

Od chaosu do standardów

To było to, co chcieliśmy zmienić. Definitywnie nie chcieliśmy, żeby nasza praca, żeby nasza firma wyglądała w ten sposób i, tak jak wspomniałem, byliśmy przekonani, i myślę, że to było prawdziwe przekonanie, że w ten sposób nie byliśmy w stanie rozwijać naszej firmy, nie byliśmy w stanie skalować naszej organizacji. Więc mamy już to, co chcemy zmienić. To teraz wypadałoby się zastanowić nad tym, w co chcemy się zmienić. Otóż, zarówno ja, jak i Marcin, jeden czy drugi moi wspólnicy, mieliśmy, zanim zaczęliśmy Pragmatic Coders, kilka lat doświadczeń jako konsultanci, jako trenerzy, jako szkoleniowcy. Pomagaliśmy wielu firmom w Polsce, ale też w całej Europie, zmieniać się, transformować w stronę, w kierunku metodyk zwinnych, w kierunku Scruma, w kierunku Kanbana, Lean Software Development, Agile Software Development, oczywiście też wszystkich praktyk technicznych typu Continuous Delivery, Test Driven Development i tak dalej. Postanowiliśmy wykorzystać te nasze doświadczenia do tego, żeby w tym momencie stworzyć firmę, naszą firmę, w taki sposób, czy przekształcić naszą firmę w taki sposób, by ona pracowała w zasadzie od linijki, zgodnie z tym wszystkim, czego nauczaliśmy naszych poprzednich klientów w czasach konsultingowych czy szkoleniowych. Czyli mamy już, co zmienić: chaotyczne, niezarządzanie firmą, tylko samorządzenie się firmy w ustrukturyzowany, ustandaryzowany sposób wytwarzania oprogramowania zgodnie z najnowszymi, czy też może nie najnowszymi, bo to zasady nie są nowe, ale z dobrymi praktykami wytwarzania oprogramowania czy zarządzania wytwarzaniem oprogramowania. Mając tę wizję, mając to wyobrażenie, jedyne, co trzeba zrobić, to wymyśleć, w jaki sposób przejść z punktu A, czyli ze stanu wyjściowego, do punktu B, czyli do naszego stanu docelowego. Czyli jak przeprowadzić tę zmianę? I w zasadzie o tym jest ten dzisiejszy odcinek. Powiem też o tym trochę na samym końcu, w jaki sposób utrzymać zmianę, ponieważ zmiana to nie jest coś, co wydarza się raz i zatrzymuje się w miejscu i tam już zostaje. Zmiana to jest proces, który trwa w sposób ciągły, który trzeba monitorować, ale o tym będzie w dalszej części tego odcinka. Po czym poznać, że wasza firma jest w kryzysie, czy też po czym myśmy poznali, że nasza firma jest w kryzysie? Otóż, po tym, że w zasadzie nasza praca, jako osób zarządzających firmą, skupiała się głównie na gaszeniu pożarów. Prawie nie robiliśmy nic innego, tylko po prostu biegaliśmy z wiaderkiem wody od jednego projektu do drugiego projektu. Te kwestie dokładnie porusza nasz poprzedni odcinek, także jeśli jeszcze go nie obejrzałeś, to polecam najpierw się z nim zapoznać, bo zawsze lepiej zacząć od diagnozy, a dopiero potem podejmować działania. Jak zrobiliśmy transformację? Otóż, wykonaliśmy kilka–kilkanaście działań, czy też prowadziliśmy kilkanaście procedur, procesów, narzędzi do naszej codziennej pracy, po to, żeby tę pracę ustandaryzować. Ale zanim to zrobiliśmy, w pierwszej kolejności musieliśmy jasno nakreślić standardy. W naszym wypadku powiedzieliśmy, że wszyscy w firmie, nieważne w jakim projekcie, dla jakiego klienta pracują, mają pracować w Scrumie. I co to znaczy, że mają pracować w Scrumie? To znaczy, że jest taka mała książeczka, Scrum Guide. Być może o niej słyszeliście, być może nawet mieliście okazję ją przeczytać, która dokładnie opisuje to, czym jest Scrum i to, czym Scrum nie jest. Więc wszyscy w firmie mieli od pewnego momentu dążyć do tego, żeby pracować zgodnie z tym, co jest napisane w tej książeczce. Dlatego zapoznanie się ze Scrum Guide’em było obowiązkiem, a przynajmniej odsłuchanie go w formie audio, które też polecam. Scrum Guide – przewodnik po Scrumie czyta Krystyna Czubówna. I to był pierwszy krok, czyli odgórna decyzja, że w ten sposób pracujemy. Odgórna decyzja, że to jest nasz nowy standard, w którym wszyscy mają pracować. Wszyscy, bez względu na jakiekolwiek wyjątki, na jakiekolwiek sytuacje, mają dążyć do tego i mają się do tego dostosować. Inaczej dla osób, które się nie dostosują, w naszej organizacji nie będzie miejsca. Tutaj mały spoiler: Okazało się, że praktycznie nikt w naszej firmie nie postanowił się zbuntować, nikt nie postanowił odejść. Dosłownie pojedyncze osoby z czasem może gdzieś tam decydowały o tym, żeby firmę opuścić, natomiast jeśli już, to powód tego, że wprowadziliśmy standaryzację w naszej pracy, to był tylko jeden z małych powodów, które gdzieś wpłynęły na ich decyzję, nie jakiś argument, który był kluczowy do tego, że nagle ludzie zaczęli odchodzić. Więc też taka rada dla was: jak pomyślicie o tym, żeby wprowadzać jakieś standardy w waszej firmie, o ile te standardy będą przemyślane i o ile będziecie w stanie dobrze uargumentować swoim ludziom, to raczej nie bójcie się tego, że ktokolwiek przez standaryzację w waszej firmie odejdzie. A nawet jeśli się tak wydarzy, no to cóż, tak naprawdę to chyba nawet lepiej, niż gdyby ten ktoś został i cały czas podburzał innych czy podkopywał waszą ciężką pracę.

Szkolenia, presja i monitoring

No dobrze, skoro mamy pewien standard, poprosiliśmy ludzi, by pracowali w taki sposób, to czy to sprawi automatycznie, że nagle ci ludzie zaczną pracować zgodnie z tym, co my rozumiemy, czytając Scrum Guide’a, że jest Scrumem i że tak należy pracować? No oczywiście nie. Wiem, że mamy końcówkę 2025 roku. Wiem, że dzisiaj już praktycznie wszyscy z was, którzy to oglądacie, którzy tego słuchacie, słyszeliście o Scrumie. Być może prawie wszyscy z was mieli okazję pracować w czymś, co ktoś inny nazywał Scrumem i prawdopodobnie zdecydowana większość z was nigdy przenigdy nie widziała zespołu, który by naprawdę pracował w Scrumie, tak jak jest to opisane w Scrum Guide’zie od A do Z. Raczej większość osób, które spotykam, mówi, że to jest jakaś utopia, należy do tego dążyć, ale tego się nie da osiągnąć. Być może tak jest, być może to jest bardzo trudne. Niemniej jednak mi się zdarzyło kilka razy w życiu obserwować zespoły, które naprawdę były bardzo blisko takiego Scruma „by the book”. Więc też postanowiliśmy w ten sposób pracować. No dobrze, ale jak to zrobić, skoro wszyscy na rynku uważają, że wiedzą, o co chodzi w Scrumie? Większość osób na rynku uważa, że potrafi pracować w tym Scrumie, być może już nawet pracowała w Scrumie, a jednak przychodzą do nas i okazuje się, że ta ich praca w Scrumie nijak się ma do tego, co my rozumiemy przez pracę w takim prawdziwym Scrumie. Żeby ten problem zaadresować, postanowiliśmy wprowadzić obowiązkowe szkolenia dla wszystkich w firmie, czyli w zasadzie podjęliśmy decyzję, że w którymś momencie wszyscy w firmie zostaną przeszkoleni. To były warsztaty, które akurat w naszym wydaniu rozłożyliśmy sobie na dwa miesiące – po jednej godzinie tygodniowo. Wszyscy w firmie, bez wyjątku, przechodzą takie szkolenie. Wszyscy przeszli wtedy – to było prawie stu osób – wszystkich przeszkoliliśmy w ciągu kilku miesięcy, myślę. I oczywiście zrobiliśmy też dodatkowe szkolenie onboardingowe, gdzie każda osoba, która przychodzi do nas, od razu w pierwszych tygodniach swojej pracy przechodzi przez takie krótkie czterogodzinne szkolenie scrumowe, które jest takim tak naprawdę wprowadzeniem, żeby ta osoba od razu mogła zacząć pracować w zespole, mniej więcej ucząc się od innych, jak ten Scrum wygląda. Ale też obowiązkowo w pierwszym półroczu każda osoba, która do nas przychodzi, musi przejść przez to długie szkolenie, które trwa dwa miesiące – przez ten proces szkoleniowy, proces treningowy, który sprawia, że to zrozumienie Scruma zaczyna być na wyższym poziomie. Szkolenia dla wszystkich w firmie to jest podstawowe narzędzie tego, żeby w ogóle jakakolwiek standaryzacja mogła zaistnieć. Mając szkolenia, mając narzucony pewien standard, określone warunki współpracy pomiędzy firmą a pracownikami, można zacząć od ludzi oczekiwać tego, by pracowali zgodnie ze standardami. Narzucając standardy, nie dając jednocześnie wiedzy na temat tego, jak te standardy spełniać, tak naprawdę ciężko jest oczekiwać, żeby ludzie te standardy sami spełniali. A już na pewno ciężko jest oczekiwać, że te standardy będą spełniane zgodnie z naszymi oczekiwaniami. Raczej ludzie będą się starać robić to, co uważają za słuszne w ramach tych standardów, natomiast bez dostarczenia odpowiedniej wiedzy to nie zawsze będzie przypominać to, jakbyśmy chcieli, żeby to wyglądało. Ponadto, tutaj dochodzi jeszcze jedna ważna rzecz: tak naprawdę ze szkoleń uczestnicy wdrażają w życie maksymalnie 30–40% wiedzy, która była przekazywana na takich szkoleniach. Dlatego nawet jeżeli prowadzimy tak intensywne kursy jak my i uczymy wszystkich Scruma, to ciężko jest liczyć na to, że od pierwszego razu wszyscy nagle będą pracować zgodnie z tym, co było na szkoleniu. Raczej liczymy się z tym, że to będzie może 20% wiedzy, którą przekazujemy, wdrożone w życie. Tutaj trochę na naszą korzyść działa to, że w tych szkoleniach uczestniczą wszyscy. Więc jeżeli każda osoba z kilkuosobowego zespołu wyciągnie jakieś 20%, to jest spora szansa, że wszyscy razem wyciągną być może różne rzeczy. Może to się złoży do jakiś 100%, może do 80%, może do 70% wiedzy, która była na szkoleniu, którą ktoś w zespole będzie posiadał i będzie pilnował, żeby ten fragment tej wiedzy z tego szkolenia był zaimplementowany w ich codziennej pracy. Żeby ludzie faktycznie zaczęli realizować te cele, które im narzuciliśmy, potrzebowaliśmy w nasze procesy ewaluacji rozwoju, procesy podwyżkowe, wprowadzić elementy, które będą wywierały pewną presję na nich, czy też elementy, które będą uzależniały chociażby właśnie podwyżkę czy dobrą ocenę podczas rozmów rozwojowych czy ewaluacji – będą uzależniały od tego, jak zespół danej osoby dobrze pracuje, zgodnie z oczekiwaniami, które przed nim postawiliśmy. Jeśli zmieniacie swoją organizację, mówicie ludziom, czego oczekujecie i nawet uczycie ich, w jaki sposób mają pracować, ale w żaden sposób nie egzekwujecie od nich tego, jak pracują, czy też nie egzekwujecie tego, że postawicie pewne oczekiwania, a oczekiwania nie są spełniane – no to możecie zapomnieć o tym, że zmiana waszej organizacji zaistnieje. Raczej dużo bardziej prawdopodobne jest to, że gdzieś w pewnych miejscach pewne bardziej ambitne osoby coś wdrożą, natomiast jeśli chodzi o systemową zmianę organizacji, to myślę, że macie duże szanse niepowodzenia, żeby taka organizacja bez odpowiedniej presji się zmieniła. No dobrze, mamy postawione cele i określone standardy, dostarczyliśmy wiedzę, wywieramy pewną presję na organizację, na ludzi, żeby te cele realizowali. Ale po czym poznamy, że tak naprawdę te rzeczy się dzieją? Żeby w ogóle wiedzieć, czy zmiany, które wprowadzamy, po pierwsze przynoszą sens, ale jeszcze zanim – czy przynoszą sens, to czy w ogóle cokolwiek zmieniamy, czy w ogóle nasze zmiany są realizowane w praktyce, musimy monitorować same procesy zmiany. Wiem, że fajnie jest mieć różne metryki produktowe, metryki biznesowe i tak dalej. Natomiast jeżeli wprowadza się zmiany w organizacji, zmienia się jakiś proces i tak dalej, to w ogóle pierwszą podstawową metryką, czy też pierwszą podstawową obserwacją, którą powinniśmy poczynić, jest sprawdzenie, czy w ogóle, jeśli wdrażamy jakiś nowy proces, czy jakiś nowy standard pracy, to czy ktokolwiek w ogóle pracuje zgodnie z tym standardem. My złapaliśmy się na tym, że mieliśmy oczywiście tę standaryzację, mieliśmy te szkolenia, natomiast po jakimś czasie znowu zaczęły się… Przez chwilę było fajnie, wszystko działało. Po jakimś czasie znowu zaczęły pojawiać się różne kryzysy. I pierwsza myśl była taka, że oj, chyba te nasze procesy nie działają. Być może wybraliśmy Scruma niepotrzebnie, może to było złe narzędzie, może trzeba było wybrać jakiś inny framework zarządzania, może Kanban by zadziałał lepiej w tej konkretnej sytuacji, gdzie tam gdzieś wybuchł pożar. W tym momencie chyba nawet ja powiedziałem: „No dobra, ale czy w ogóle ten zespół, w którym tam właśnie coś wybuchło, czy te dwa zespoły, w których coś właśnie wybuchło, czy oni w ogóle pracowali w tym Scrumie?”. Jak się zaczęliśmy temu bliżej przyglądać, to się okazało, że tak naprawdę to, kurczę, nie do końca. Niby wszyscy byli przeszkoleni, niby wszyscy wiedzieli, jak oczekujemy, że będą pracowali. Ale jak sobie spojrzeliśmy, co tam się dzieje, to się okazało, że tam praktycznie w ogóle nie było backlogu. Jak się bardziej zaczęliśmy temu przyglądać, to okazało się, że ostatnia retrospekcja to była trzy miesiące temu i tak dalej, i tak dalej. Okazało się, że pomimo tego, że oczekiwania już były, pomimo tego, że to już niby było wplecione w procesy rozwojowe, ewaluacyjne i tak dalej, to te ewaluacje dzieją się za rzadko – dzieją się raz do roku. I po prostu zespół, który sobie pracował poza naszymi standardami, jakoś się prześlizgnął i nawet nie zauważyliśmy tego, że te standardy nie są w tym zespole spełniane. Co zatem zrobiliśmy i co rekomenduję wam, żeby w takich sytuacjach robić? Otóż wprowadziliśmy narzędzia monitorujące to, w jaki sposób realizowane są procesy w naszej firmie – procesy, które sobie narzuciliśmy, czy w jaki sposób są wykorzystywane te metody pracy, które założyliśmy, że będą wykorzystane. Chciałbym wam pokazać jedno z tych narzędzi – to jest nasza scrumowa health checklista. To jest takie narzędzie, które pomaga naszym zespołom dokonać samooceny, lub też sam Agile Delivery Lead siada z takim zespołem, rozmawia z nimi i po kolei wypełnia, jak faktycznie ten proces scrumowy wygląda. Sprawdzają, czy w ogóle produkt, nad którym zespół pracuje, ma zdefiniowaną wizję i czy wszyscy członkowie scrumowego zespołu tę wizję znają. Są tutaj też inne kwestie związane z tym, czy w zespole w ogóle jest scrum master i czy członkowie zespołu wiedzą, kim jest ten scrum master. Może to być oczywiste dla was, ale uwierzcie mi, zdarzały się sytuacje, że w zespole był scrum master, ale nikt nie wiedział, że ta osoba pełni tę rolę – wszyscy myśleli, że to jest po prostu kolejny deweloper. Czy na przykład kwestie związane z tak oczywistymi rzeczami, jak to, czy zespół ma Definition of Done. Jak już ma to Definition of Done, czy wszystkie rzeczy, które ten zespół dostarcza, spełniają to narzucone przez sam zespół Definition of Done. Podobnie kwestia na przykład retrospekcji: czy w ogóle retrospekcja się odbywa, czy w trakcie tej retrospekcji są jakieś action pointy, czy action pointy z poprzedniej retrospekcji są omawiane na kolejnej retrospekcji, czy w ogóle te action pointy są wdrażane w życie i tak dalej, i tak dalej. Teraz, mając taką checklistę składającą się z kilkudziesięciu pytań, zespoły, które sobie to wypełniają, czy też Agile Delivery Lead, który wypełnia to razem z zespołem, określają pewną punktację, pewien wynik, który na koniec dnia pokazuje nam, jak dobrze dany zespół pracuje według naszych standardów, według naszego procesu. Trochę mówiłem już na ten temat w jednym z poprzednich odcinków, na temat tego, w jaki sposób mierzyć pracę programistów, czy też jak my mierzymy pracę naszych programistów. Jeśli jesteście zainteresowani tematem metryk i tak dalej, to bardzo was gorąco zachęcam do tego, żebyście zerknęli i poszukali tego odcinka na naszym kanale. Oczywiście i żeby nie było – Scrum to tylko jeden wymiar, to tylko proces. Oprócz samego procesu wytwarzania oprogramowania, jest też proces zarządzania tym wytwarzaniem, czy zarządzania tak naprawdę produktem. I tutaj mamy kolejną checklistę – czyli Checklistę Product Health, która jest już troszeczkę bardziej skierowana do naszych product managerów, naszych product ownerów, po to, żeby też się upewnić, że praca tych product ownerów jest zgodna ze standardami. Tutaj a propos szkoleń, to mamy oczywiście też osobny proces szkoleniowy, proces onboardingowy dla naszych product ownerów, w którym dokładnie tłumaczymy to, czego od nich oczekujemy, jak chcemy, żeby pracowali, jak chcemy, żeby wyglądały wszystkie artefakty w postaci backlogu, czy też roadmapy, czy jeszcze jakichś innych rzeczy. Oczywiście tutaj znowu mamy checklistę, która też nam pokazuje, jak dobrze te aspekty produktowe w każdym projekcie, który realizujemy dla klientów czy też wewnętrznie, są realizowane. Trzecim wymiarem, w którym staramy się mierzyć to, jak pracują nasze zespoły, czy też może nie tyle mierzyć, co monitorować to, jak pracują nasze zespoły, to oczywiście aspekty techniczne, aspekty dobrych praktyk deweloperskich. I tutaj oczywiście mamy kolejną checklistę, która skupia się już troszeczkę bardziej na tym, jak wygląda architektura, czy w ogóle jest jakaś architektura, jak są pisane testy jednostkowe, czy w ogóle są pisane testy jednostkowe, czy jakieś testy akceptacyjne, jak wygląda proces CI/CD i tak dalej, i tak dalej. Myślę, że te wszystkie checklisty udostępnimy wam w opisie tego odcinka. Jak będziecie mieli ochotę, to możecie sobie je pobrać i samemu spróbować zrobić coś takiego ze swoim zespołem, oczywiście dostosowując je do swoich standardów, do waszej pracy, do waszych codziennych projektów.

Skalowanie i utrzymanie zmiany

No dobrze, mamy już te podstawowe narzędzia. Określiliśmy cele, standardy, szkolimy ludzi, robimy wszystko zgodnie z tym, co sobie założyliśmy, że będziemy robić. Mamy monitoring tego, jak tak naprawdę ta praca wygląda. No to teraz wypadałoby zacząć skalować to wszystko w górę i rozwijać naszą organizację. I teraz, żeby odpowiednio rozwijać organizację i nie stracić tego wszystkiego, co zbudowaliśmy, musieliśmy wdrożyć odpowiedni proces onboardingu. Czyli musieliśmy sprawdzić, że ludzie, którzy dołączają do nas z zewnątrz, również będą jak najszybciej w stanie pracować zgodnie z naszymi standardami i że wzrost naszej organizacji nie zaburzy tych standardów. Więc tutaj musieliśmy stworzyć odpowiednie procesy onboardingowe, odpowiednie szkolenia, odpowiednie SLA na każde szkolenie, które musi się wydarzyć w pierwszych, na przykład, w pierwszym miesiącu, w pierwszych trzech miesiącach czy w pierwszym półroczu pracy danej osoby. To też oczywiście musi być monitorowane. I kolejny wymiar, który musiał ulec zmianie, czy też drobnemu tak naprawdę w naszym wypadku dostosowaniu, to była kwestia rekrutacji. Musieliśmy dużo bardziej selektywnie podchodzić do kandydatów i kandydatek, którzy do nas aplikowali i dużo bardziej sprawdzać to, jak oni się zapatrują na pracę zgodnie z naszymi standardami. I być może to nie jest takie oczywiste, ale zdarzyło nam się kilkoro kandydatów odrzucić z tego powodu, że na przykład otwarcie mówili, że Scrum to jest jakaś bzdura, oni nie będą w tym pracować, to jest bez sensu, to nie dla nich i oni już tyle razy to widzieli, że to na pewno nie działa. Jeśli ktoś ma takie podejście, to oczywiście moglibyśmy taką osobę zatrudnić, przeszkolić, próbować ją namawiać do tego i prawdopodobnie by nam się udało, pokazując efekty naszej pracy. Natomiast wysiłek potrzebny na to, żeby taką osobę wciągnąć na pokład i zmienić tak naprawdę jej nastawienie – ten wysiłek byłby zdecydowanie za duży i prawdopodobnie niewart tego trudu, który musielibyśmy w to wszystko włożyć. Ponieważ jednak jest jakaś szansa i ryzyko, że taka osoba by jednak nie zmieniła swojego podejścia i torpedowałaby wszystko to, co robimy i metody, w jakich pracujemy. No dobrze, wprowadziliśmy te wszystkie zmiany. To jest, myślę, takie absolutne minimum, które musicie zrobić, jeśli chcecie zmienić waszą firmę. My zrobiliśmy jeszcze kilka innych rzeczy wokół, o których być może za chwilę jeszcze opowiem. Ta zmiana trwała około sześciu, może dziewięciu miesięcy. Przez sześć bądź dziewięć miesięcy wprowadzaliśmy te wszystkie rzeczy, o których przed chwilą powiedziałem i zaczęliśmy obserwować efekty tego. I te efekty były zdumiewające, te efekty były naprawdę świetne. Nasza firma zaczęła pracować w jednostajnym rytmie. W zasadzie nawet nasz dział marketingu i nasz dział HR zaczął pracować w Scrumie, co wydaje się być nie do pomyślenia, ale naprawdę te zespoły były w stanie pracować w dwutygodniowych iteracjach, budując produkty, czy też produkt, którym jest nasza firma – budując pewne procesy, automatyzując pewne rzeczy, robiąc interview, robiąc retrospekcje, wyciągając wnioski i ulepszając swoje procesy współpracy. To naprawdę działało świetnie. No i w zasadzie można powiedzieć, przeprowadziliśmy udaną transformację zwinną organizacji. Wszystko było okej, dopóki było okej. Mniej więcej dwa lata później zauważyliśmy, a w zasadzie zaczęliśmy zauważać pewien regres. Zaczęły się pojawiać pewne problemy w różnych zespołach i zaczęliśmy się zastanawiać nad tym, z czego to wynika. Tak naprawdę, co tutaj jest problemem? Badania pokazują, że ludzie, którzy się czegoś nauczyli, mniej więcej po około 18–24 miesiącach zapominają połowę tego, czego się nauczyli. Właśnie u nas zaczęliśmy dostrzegać to mniej więcej dwa lata po tym, jak zakończyliśmy ten główny proces szkoleniowy. Oczywiście te szkolenia trwały cały czas dla nowych osób w procesach onboardingowych, ale zauważyliśmy, że pewne rzeczy zaczęły się nam troszeczkę rozłazić, zaczęły się rozchodzić. Ludzie zaczęli zapominać, po coś robią, jak wyglądają te procesy, czy one działają dobrze, czy działają źle, czy być może nie działają wcale. Użyliśmy do tego Jiry. Wprowadziliśmy tablicę kanbanową, czy też ogólnie tablicę, która ma nam wizualizować – znaczy, to nie jest tablica kanbanowa, bo itemy na tej tablicy sobie latają w prawo i lewo w zależności od tego, gdzie są. Natomiast chciałbym, żebyście przede wszystkim skupili się na czterech ostatnich kolumnach, czyli na kolumnie „nie działa”, „działa źle”, „działa nieźle” i „działa dobrze”. To są kolumny, które odzwierciedlają stan danego procesu. Czyli na przykład mamy Technical Excellence, czyli checklista, która jest wypełniana w przypadku nowych projektów, która sprawdza, czy w tych nowych projektach pracujemy zgodnie ze standardami. I jak widzicie, akurat ten proces nie działa. On jest w tym miejscu, dlatego że akurat ten proces wydzieliliśmy z innego procesu i jest to w miarę nowa rzecz. Natomiast on jest w tej chwili niedziałający. Więc ja, patrząc na to jako prezes firmy, widzę, że to na pewno jest obszar, który wymaga może nawet nie tyle mojej uwagi, co zwrócenia uwagi osobie, która jest odpowiedzialna za ten proces. Mamy taki proces, czy też karteczkę w tej Jirze, która mówi o tym, że mamy scrum mastera w każdym zespole i ta karteczka jest w obszarze „działa nieźle”. Fajnie, to znaczy, że prawdopodobnie jest dosłownie jeden lub dwa zespoły, które tych scrum masterów nie mają. Podobnie Product Health Checklist, czyli ta checklista, którą wam wcześniej pokazywałem – to, jak ona jest spełniana, bądź też to, jaki jest wynik tej checklisty średni dla firmy. Dla każdego z tych procesów mamy określone konkretne SLA, konkretne kryteria, które mówią, że dany proces działa dobrze, działa nieźle, działa źle bądź nie działa wcale. I na przykład dla takiej Product Checklist to SLA wynika z tego, w jakim stopniu zespoły wypełniają te checklisty. Czyli jeśli wszystkie nasze zespoły mają wypełnioną checklistę, która jest nie starsza niż 75 dni (osobiście uważam, że jest całkiem długim okresem), to znaczy, że ten proces działa dobrze i faktycznie możemy na nim polegać. Natomiast jeżeli pojawiają się takie zespoły, które nie mają wypełnionej checklisty przez ostatnie dwa i pół miesiąca, to znaczy, że coś robimy nie tak. To znaczy, że uciekają nam jakieś dane. To znaczy, że prawdopodobnie może wydarzyć się coś takiego, czego nie będziemy w stanie wcześniej przewidzieć, obserwując te właśnie checklisty i te metryki, które mamy. Taki metaproces, który sobie po prostu nazwaliśmy Scrum at PC, on też u nas działa nieźle. Ten proces ma dużo bardziej złożone SLA. Na każdym poziomie ten proces zależy od kilku innych procesów. Przede wszystkim na przykład zależy od tego, jak wygląda ten nasz Scrum Score z tej checklisty, którą wam wcześniej pokazywałem, scrumowej, tak. Czyli jeżeli tamten Scrum Score jest na poziomie mniejszym niż 70%, Scrum w Pragmatic Coders będzie co najwyżej działał nieźle. Jeżeli tutaj ta metryka spadłaby średnio pomiędzy 40% a 50%, to mówilibyśmy o tym, że Scrum u nas działa źle. A jeśli ta metryka spada poniżej 40%, to moglibyśmy śmiało powiedzieć, że Scrum w Pragmatic po prostu nie działa. Zapomnijmy o tym, że jesteśmy scrumową firmą i albo coś z tym zróbmy i sprawdźmy, żeby to znowu zadziałało, albo po prostu poszukajmy innych metod pracy, ponieważ tylko udajemy, że pracujemy w Scrumie. I podobnie, inne metryki, od których ta metametryka, ten metaproces scrumowy w naszej firmie mocno, mocno zależy. Mając taki panel kontrolny, możemy śmiało zarządzać naszą transformacją, zarządzać naszą zmianą w organizacji oraz przede wszystkim monitorować to, na jakim etapie nasza firma jest, jak te nasze procesy, które sobie wdrożyliśmy, wyglądają i czy one faktycznie działają. My spotykamy się co tydzień, żeby rozmawiać o tym, co nasz management team w danym tygodniu robi w ramach tych procesów, w jaki sposób je usprawnia, wdraża w życie bądź też ulepsza. I raz w miesiącu omawiamy sobie już w szczegółach każdą metrykę i prowadzimy zapis tego, jak to historycznie wyglądało. Ten zapis fajnie pokazuje, że robimy postępy: jest coraz więcej rzeczy, które działają dobrze bądź nieźle i coraz mniej rzeczy, które nie działają.

Podsumowanie

Czyli podsumowując, jeśli chcecie zmienić organizację, to musicie zarządzać tą zmianą. Możecie sobie zrobić na początku nawet backlog zmian, które chcecie wprowadzić, czyli tak jak mówiłem: co zmienić, w co zmienić i jak wykonać zmianę. Ten backlog to jest to, jak dokonać tej zmiany, czyli rzeczy, które musicie zrobić, żeby zmiana zaszła, i ten backlog możecie później realizować. Natomiast musicie pamiętać o tym, że zmiana to nie jest coś, co zrobicie raz i możecie o tym zapomnieć. Zmiana organizacji, zmiana czegoś takiego jak organizacja, takiego systemu, jakim jest organizacja, wymaga ciągłego monitoringu i ciągłego oddziaływania na tę organizację, żeby taka organizacja nie wróciła znowu do starych nawyków, do chaosu, czy też do metod, które są dla was niepożądane. Także polecam wam gorąco spróbować po pierwsze wprowadzać zmiany w sposób ustrukturyzowany – wiedzieć co zmienić, w co zmienić i jak wykonać tę zmianę. Następnie monitorować te zmiany, monitorować to, czy procesy, które wdrażacie, faktycznie działają. Czy być może wdrażacie jakieś procesy, wydaje wam się, że one działają, jednocześnie wydaje wam się, że nie osiągacie określonych efektów, po czym na przykład porzucacie te procesy, szukacie jakiś innych rozwiązań i tak dalej. A tak naprawdę okazuje się, albo okazałoby się, gdybyście się temu bardziej przyjrzeli, że te procesy, które wam się wydawało, że wdrożyliście, wcale nigdy nie były wdrożone. Także to już wszystko, co miałem dzisiaj wam do przekazania. Dajcie znać w komentarzach, czy mieliście okazję kiedykolwiek uczestniczyć w tego typu zmianie organizacji, bądź czy byście się podjęli takiej zmiany organizacji. Oraz, oczywiście, jeśli potrzebujecie pomocy, potrzebujecie wskazówek, możecie śmiało się do mnie odezwać, najlepiej na portalu LinkedIn. Chętnie porozmawiam z wami, opowiem wam więcej w szczegółach na temat tego, co i jak robimy w Pragmatic Coders. A tymczasem zapraszam oczywiście do subskrypcji naszego kanału i dajcie kciuk w górę, jeśli temat był dla was interesujący i odcinek się podobał.