Audio is streamed directly from the publisher (feeds.soundcloud.com) as published in their RSS feed. Play Podcasts does not host this file. Rights-holders can request removal through the copyright & takedown page.
Show Notes
Kuba na konferencji Agile By Example (edycja 2018) opowiedział o tym, że „Transformacja to nie krok ani projekt, tylko niekończąca się historia”. Na bazie tamtej treści poszerzamy wątek i opowiadamy o tym, dlaczego transformacja zwinna to złożona zmiana, kto za nią odpowiada i jakie praktyki zmiany mogą być naszym zdaniem dobrym pomysłem.
Czym jest, a czym nie jest zwinna transformacja – poniżej znajdziesz spis treści tego materiału.
Spis treści
Czym jest zwinna transformacja?
Transformacja jest złożoną zmianą, w której istnieją rzeczy, których osoby ją prowadzące nie są w stanie zaplanować. Ponieważ zmiana jest złożona nie jest też możliwe – zwłaszcza przed rozpoczęciem zmiany – sformułowanie ciągu przyczynowo-skutkowego, który zagwarantuje jej sukces.
W wielu organizacjach transformacja jest postrzegana jako coś prostszego. Uważa się ją za projekt, który ma określony początek, koniec i spodziewany rezultat pracy.
Można powiedzieć, że transformacja bywa postrzegana jak zmiana podobna do przeprowadzki. Wydaje się, że trzeba rozplanować jak zapakowanie rzeczy do przeniesienia, przewidzieć docelowy sposób rozstawienia mebli w miejscu docelowym. Innymi słowy, trzeba zidentyfikować cały zakres zmiany, później zaplanować te zmiany i je wykonać. Wiele firm świętuje zakończenie zmiany, gdy organizacja ma już nowe struktury, nowe metody pracy, a ludzie pracują na stanowiskach z nowymi etykietami. Transformacja zwinna to coś o wiele większego. Przede wszystkim bardzo wątpliwa jest możliwość zidentyfikowania całego zakresu zmiany. Ma to znaczenie o tyle, że w czasie pracy nad zmianą pojawia się cała masa nieprzewidzianych okoliczności, które mogą mocno wpłynąć na pierwotnie ustalony plan.
Pułapką jest też postrzeganie transformacji jak czegoś, co się zaraz skończy. Nawet jak skończą się pierwsze zmiany związane z reorganizacją, to już same one przyczynią się do powstania pomysłów na nowe usprawnienia i idące wraz z nimi kolejne reorganizacje. Można powiedzieć, że transformacja zwinna to niekończący się ciąg zmian. I jest to całkowicie naturalne, bo zawsze można coś zmienić, aby pracowało się trochę lepiej. Zadaniem liderów organizacji jest podjęcie nowych kroków, żeby się w tej rzeczywistości odnaleźć i kontynuować drogę do osiągnięcia zamierzonych celów.
Na jakie obszary wpływa zwinna transformacja?
Z naszego doświadczenia wynika, że transformacja zwinna wiąże się ze zmianami w takich obszarach jak:
Zmiana sposobu organizacji zespołu
- Zmiany w procesie wytwórczym
- Zmiany w obszarze HR
- Zmiany w umowach z klientami
- Zmiany w funkcjonowania działu sprzedaży
- Sposób myślenia i pracy menedżerów
1. Zmiana sposobu organizacji zespołu
Często obserwujemy, że częścią transformacji jest zmianę podejścia do sposobu tworzenia zespołów. Firmy przechodzą z modelu skupionego mocno na projektach na podejście zbudowania zespołów odpowiedzialnych za produkty. W tym pierwszym przypadku zespoły powoływane są na czas trwania projektu. Ich członkowie często nie mają wszystkich potrzebnych kompetencji do wytworzenia produktu. Celem transformacji jest tu doprowadzenie do zbudowania zespołów zorganizowanych wokół produktu czy jego konkretnego obszaru, aby były one w stanie wytwarzać gotowe produkty w postaci ukończonych Przyrostów tworzonych nie rzadziej niż na koniec Sprintu.
Jednocześnie taka zwinna transformacja to też zmiana na poziomie ludzkim. Ewolucji podlega to, jak członkowie zespołów współpracują ze sobą, jak dobrze się komunikują, ile o sobie wiedzą i kto może komu pomóc w razie potrzeby. Nawet jeśli ten aspekt dobrze wygląda w danej firmie, to reorganizacja zespołów na bardziej produktowe nadal może dać pozytywne zmiany w sferze międzyludzkiej.
2. Zmiany w procesie deweloperskim
Transformacja często uwypukla niedoskonałości i problemy w obszarze wytwarzania. Może się okazać, że w danej organizacji potrzeba wprowadzić zarówno nowe narzędzia związane z wdrażaniem produktu, jego testowaniem, czy z automatyzacją tych procesów. Z obserwacji wiemy, że to może być niezbędne, żeby transformacja miała w ogóle miejsce albo żeby uzyskać niezbędne efekty. Tak jak w poprzednim punkcie, mamy tu do czynienia zarówno z aspektem organizacyjnym (poukładanie procesów), jak i ludzkim (nauczenie się nowych narzędzi i sposobu pracy).
3. Zmiany w obszarze HR
Zwykle okazuje się, że zespoły deweloperskie pracujące zwinnie potrzebują nieco innego profilu członka zespołu, niż w przypadku podejścia klasycznego. W zespołach zwinnych potrzebny jest o wiele większy zasób umiejętności komunikacyjnych, w tym empatii, czy umiejętność udzielania i przyjmowania informacji zwrotnej. Zmienić się też może podejście do oceny zespołów, wyznaczania celów, rozwoju kompetencji pracowników czy sposobów uzyskiwania integracji zespołowej. We wszystkich tych sferach warto pójść w kierunku, które jest preferowane w podejściu zwinnym: zespołowość, wspólną odpowiedzialność, rozwój kompetencji potrzebnych w zespole.
4. Zmiany w umowach z klientami czy ustaleniach wewnątrz organizacji
Jeśli twoja firma pracuje w modelu usługowym albo podwykonawczym (np. software house’y), to umowy, które aktualnie masz podpisane z klientami mogą nie być dostosowane do pracy zwinnej. Często w relacji zamawiający-dostawcy stare umowy są zbyt sztywne i nie uwzględniają potrzeby elastycznych reakcji w zakresie pracy. Częścią transformacji będzie aktualizacja zasad działania z klientami.
5. Zmiany w interakcjach z otoczeniem zespołu
Gdy toczy się transformacja, zmianie może ulec też to, co komunikujesz potencjalnym klientom zewnętrznym albo wewnętrznym interesariuszom na temat sposobu, w jaki pracuje twój zespół. Ważne jest, aby klient/interesariusz dobrze zrozumiał na czym polega praca w ramach zwinnej umowy. Żeby praca zwinna miała sens, potrzebne jest pełne zaangażowanie w proces wytwórczy obu stron.
W przypadku zespołów rozwijających produkt wewnętrzny zmiany będą dotyczyć całego obszaru związanego z rolą Product Ownera i zarządzania inicjatywami projektowymi. W przypadku relacji klient-dostawca, sporych zmian można się spodziewać w obszarze działu sprzedaży lub relacji z klientem.
6. Sposób myślenia i pracy menedżera
Rola menedżera w zwinnej firmie przybiera trochę inną formę. Podczas transformacji często obserwujemy wyjście z pracy typowo operacyjnej (tzw. „gaszenie pożarów”) i wejście w pracę bardziej strategiczną, długofalową. Manager w środowisku zwinnym ma większe skupienie na wspieraniu zespołów w ich pracy, a mniej na śledzeniu wykonywania działań czy zarządzania pracami wykonawczymi.
Transformacja agile – co pływa na jej złożoność?
Trudno mieć całkowitą kontrolę nad zmianą, gdyż nawet jeśli poznasz obszary, które mają jej podlegać, to aspekt ludzki często wprowadza nieprzewidziane sytuacje. Zarówno członkowie zespołów, jak i menedżerowie i interesariusze mają swoje nawyki, a także często obawy i opory przed zmianami, przez co transformacja będzie się przedłużać i wstępne założenia mogą potrzebować przebudowania.
Znaczenie tu też ma wielkość organizacji. Im większa organizacja, tym trudniej poprawnie zidentyfikować wszystkich interesariuszy i aspekty działania biznesu.
Na złożoność transformacji wpływa też typ produktu oraz rynek, na którym działasz. Konkurencja raczej nie będzie czekać, aż się przeorganizujesz i rynek będzie działał, a klient będzie oczekiwał zaangażowania. Nowe trendy w danej branży mogą sprawić, że pierwotne pomysły produktowe się zdezaktualizują, więc będą potrzebne pilne kolejne aktualizacje do planów i wizji. Nawet jeśli niedawno firma reorganizowała się z powodów transformacji zwinnej, to może się okazać, że potrzebna jest ponowna reorganizacja, tym razem z powodu zmiany priorytetów biznesowych czy nowej strategii.
Rola Scrum Mastera i lidera a transformacja agile
Scrum Master jest jedną z ról, która może przyczynić się do rozwiązania wskazanych wyżej trudności. Osoby pełniące tą odpowiedzialność są w stanie zebrać od zespołów przeszkody i blokery, a następnie dokonać pewnej syntezy i przygotować coś, co może być bardzo wartościowym wkładem dla osób, które zarządzają prowadzeniem transformacji.
Z drugiej strony – bliska praca z Product Ownerem powoduje, że zaciera się w pewnym sensie granica pomiędzy IT i biznesem i następuje integracja do jednego zespołu produktowego.
Dotychczasowi liderzy organizacji powinni przede wszystkim mieć świadomość, że transformacja jest procesem. Ich rolą jest podejmowania działań angażujących członków zespołów, a także komunikowanie się ze Scrum Masterami i bezpośrednio z całymi zespołami.
Dobrze jest też upewnić się, że wszyscy w organizacji wiedzą kim jest lider transformacji albo z jakich osób składa się zespół przewodzący zmianie i do kogo mogą się zgłosić ze swoimi przemyśleniami czy obserwacjami, jeśli transformacja jest już w toku.
Ważne jest również to, aby mieć też świadomość, że transformacja to nie tylko pozytywne usprawnienia, ale to też trudna droga, w której mogą pojawiać się konflikty. Zmiany mogą wiązać się ze stratą władzy lub bezpiecznego status quo. Transformacja ma też swoje koszty wynikające np. z potrzeby przeszkolenia ludzi, zatrudnienia konsultantów zewnętrznych, inwestycji w narzędzia czy efekty chwilowego spowolnienia tempa prac. Pojawi się też cała masa trudnych decyzji, za które ktoś musi wziąć odpowiedzialność i argumentować ich zasadność. To wszystko leży w gestii lidera transformacji.
Transformacja zwinna - nasze wskazówki
Dla osób odpowiedzialnych za przeprowadzenie albo włączenie się w toczącą się transformację zwinną mamy też szereg podpowiedzi, wynikających z naszego doświadczenia uczestniczenia w takich procesach w wielu firmach.
1. Korzystaj z techniki małych kroków
Działaj podobnie jak Zespoły Scrumowe, które złożone problemy rozwiązują w Sprintach, stopniowo wdrażając zmiany w kolejnych iteracjach.
Zatem, zamiast próbować zaplanować coś na pół roku w przód, rekomendujemy technikę małych kroków, po których liderzy zmiany zastanawiają się, czy ten mały krok, który zrobili, jest faktycznie właściwym krokiem do przodu.
Oczywiście w pracy naprawdę małymi krokami nad zmianą całej firmy może się wydawać, że niewiele się zmienia, ale jeśli robisz to konsekwentnie i za każdym razem wybierasz kolejną najważniejszą rzecz, to po jakimś czasie zauważysz symptomy poprawy. Takie podejście jest korzystne z perspektywy całej organizacji, ponieważ nie ma zbyt dużo jednoczesnych zmian, więc łatwiej jest je zakomunikować i zrozumieć. Minimalizujesz także ryzyko niepowodzenia, bo nawet jeśli pójdzie coś nie tak, to tylko na małym wycinku całości, który łatwo zidentyfikować i naprawić.
2. Miej świadomość dokąd zmierzasz
Ponownie podobnie do zespołów Scrumowych, które mają określone Cele Sprintu i wizję produktu, tak samo w przypadku transformacji, powinna istnieć świadomość z jakiego punktu A startujesz i w jakim punkcie B chcesz się znaleźć.
Świadomość tego, dokąd zmierzasz, można przyrównać do latarni morskiej, która co jakiś czas daje żeglarzom sygnał. Sygnał ten jest punktem odniesienia do sprawdzenia, czy dany okręt płynie w dobrym kierunku, a jeśli tak nie jest, to powinien odpowiednie wcześnie skorygować kurs we właściwą stronę.
3. Dbaj o komunikację dotyczącą transformacji
Często obserwujemy, że komunikacja odbywa się na początku transformacji, a potem następuje cisza. Zwykle wysyłany jest po prostu mail informujący o tym, co jest planowane, natomiast pojawienie się nowych aspektów transformacji czy problemów nie jest już komunikowane w organizacji.
Nie jest to dobrą strategią, bo kluczowe w transformacji jest przypominanie, dlaczego to robisz i w jakim kierunku zmierzasz. Takiej komunikacji im więcej tym lepiej. Pamiętaj, że nie każdy przeczyta wszystkie e-maile i nie wszyscy zawsze są tak samo skupieni w pracy. Codzienność każdego pracownika potrafi łatwo przysłonić komunikację dotyczącą transformacji. Zatem powtarzanie tych komunikatów różnymi środkami, w różnych kontekstach, w jak najbardziej zróżnicowany i dopasowany sposób, może pomóc osobom, które biorą udział w tej transformacji być na bieżąco z jej przebiegiem. Zderzą się one kilkakrotnie z tymi informacjami i będą mogły na spokojnie przetrawić je we właściwym dla siebie czasie i we właściwy dla siebie sposób.
Jak widzisz transformacja to złożona zmiana, która obejmuje szereg obszarów i trudno jest określić jej konkretny koniec. Wpływ na nią ma mnóstwo czynników, nad którymi zwykle nie masz pełnej kontroli. Jednak jak wszędzie, tak i tu można wprowadzić pewne optymalizacje, które pomogą realizować tę zmianę płynniej i skuteczniej.
A jakie są Twoje doświadczenia związane ze zwinną transformacją: jak przebiegała taka transformacja, jakie problemy się pojawiły i jak je rozwiązaliście?
Dodatkowe materiały
- Wystąpienie Kuby na Agile By Example 2018 – „Transformation is a neverending story, not a step or project” (video)
📄Transkrypcja podcastu "Zwinna transformacja to niekończący się proces"
Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.
Jacek: Zapraszamy. W dzisiejszym odcinku będziemy rozmawiać o zwinnych transformacjach, a w szczególności o tym, że taka transformacja to niekończący się proces i niekończąca się historia. Dzisiejszy odcinek jest zainspirowany prezentacją Kuby, który wystąpił na ostatniej konferencji Agile By Example w Warszawie z prezentacją o bardzo zbliżonym tytule. No i chcielibyśmy, żeby ta prezentacja i ta treść stała się osią dzisiejszego odcinka.
Kuba: W ramach tego odcinka zaczniemy od tego, że zdefiniujemy sobie, czym jest transformacja i czym nie jest. Udowodnimy, że transformacja to nie jest ani krok – jakiś konkretny krok w zmianie firmy – ani też nie jest to niestety projekt. Bo transformacja jest złożoną zmianą i opowiemy trochę o tym. Drugą część odcinka poświęcimy na temat tego, kto może coś zrobić w ramach transformacji, jaka jest rola Scrum Mastera, jaka jest rola lidera transformacji i jakie konkretne kroki są dobrym pomysłem w ramach transformacji jako złożonej zmiany. Zaczniemy od tego, że transformacja nie jest ani krokiem, ani projektem. Tutaj obaj z Jackiem, jako osoby, które teraz przy transformacjach już w organizacjach pomagają jako konsultanci, ale też wcześniej, jako osoby zatrudnione w jakichś jeszcze organizacjach – w ten czy inny sposób – jako czy Agile Coache, czy Scrum Masterzy – no, spotykaliśmy się z takim dosyć uproszczonym spojrzeniem na świat, że: „No, przyjdź do mnie, potrzebuję zmiany, ile co to zajmie? Tydzień, dwa miesiąc? Ile tych kroków w zmianie trzeba podjąć?”.
Jacek: To jest takie spojrzenie, myślę, bardzo ukorzenione w podejściu projektowym, gdzie mamy pewien określony czas, który chcemy przeznaczyć na konkretny projekt, mamy konkretną datę startu, mamy konkretną datę zakończenia, no i mamy jakiś spodziewany rezultat prezentacji. Współpracowałem raz z osobą, która była liderem zmiany w organizacji i odniosłem takie wrażenie, że bardzo jej zależy na czasie. Jak zacząłem dopytywać, z czego wynika ten pośpiech, no to usłyszałem coś w stylu: „No, chciałbym do końca roku, żeby ten temat transformacji był już zamknięty”, co oczywiście…
Kuba: Rozumiem, że byli już mocno zaawansowani w kalendarzu?
Jacek: Raz, że byli bardzo zaawansowani w kalendarzu, a druga sprawa była taka, że te zmiany się nawet jeszcze dobrze nie rozpoczęły, tak więc trudno oczekiwać, że jesteśmy w stanie zakończyć coś na konkretną datę.
Kuba: Niestety transformacja czasem jest postrzegana jako taka zmiana typu „przeprowadzka”, że trzeba, nie wiem, rozplanować, ile biurek musi się przenieść, ile osób zmieni numer piętra, skrosować gniazdka sieciowe, czyli summa summarum, wychodząc z tej krótkiej metafory – trzeba zidentyfikować cały zakres zmiany, później zaplanować te zmiany, wykonać je i koniec transformacji, bo mamy już nowe struktury, mamy już nowe metody pracy, ludzie pracują z nowymi etykietami i koniec transformacji. No, zdecydowanie transformacja to jest coś o wiele więcej i nawet jeśli konkretnym elementem jakiejś zmiany organizacji będą te kroki, czy te małe kroki, to po pierwsze – bardzo wątpliwe jest, że się uda zidentyfikować cały zakres zmiany – o tym jeszcze za chwilę trochę powiemy – a oprócz tego wyjdzie przede wszystkim cała masa zjawisk kompletnie niespodziewanych – takie, o których byśmy nie pomyśleli i one prawdopodobnie będą o wiele ważniejsze niż to, jaki mieliśmy nawet tam pierwotnie wymyślony plan. I tutaj ta pułapka podejścia projektowego jest taka, że właśnie postrzeganie transformacji jako coś, co się skończy, jest wielką pułapką, bo to nawet jeśli się skończą te pierwsze zmiany, powiedzmy, reorganizacyjne, bo to najczęściej z transformacją będzie związane, to tak naprawdę same te reorganizacje wywołają jakieś pomysły usprawnieniowe, te pomysły usprawnieniowe mogą wymagać kolejnych reorganizacji i kolejnych – i tak naprawdę nawet jeśli firma do tej pory tak o tym nie myślała, no to to już będzie ciąg niekończących się usprawnień, reorganizacji – coś, co ja też widziałem np. w Allegro – jedna z osób to tak skomentowała, jak pracowaliśmy razem, że: „W zasadzie to jest niekończący się ciąg zmian” – i to akurat w tym w kontekście było to powiedziane w sposób negatywny, ale takie są raczej, bym powiedział, bardziej obiektywne fakty czy taka obiektywna rzeczywistość – że pewna reorganizacja pociąga za sobą już kolejny ciąg niekończących się usprawnień – bo to jest naturalne, normalne, no i to już jest taka droga bez wyjścia, że zawsze będzie dało się trochę lepiej pracować.
Jacek: Kiedy słyszę „projekt”, zakładam też, że jesteśmy w stanie dosyć jasno powiedzieć, jakie kroki musimy wykonać, żeby uzyskać spodziewany efekt. Niestety z mojego doświadczenia wynika to, że tak naprawdę bardzo ograniczoną ilość rzeczy jesteśmy w stanie przewidzieć, natomiast gros tematów, gros obszarów, które dotyczą bądź wpływają na transformację, na samym początku pracy nad zmianą może być dla nas jeszcze – że tak powiem – zamglona. Czyli w ogóle może nam nie przyjść do głowy, że – nie wiem, przykładowo – dział sprzedaży, początkowo w ogóle nieidentyfikowany jako stakeholder zmiany, może się okazać graczem, który ma dosyć duży wpływ na to, jak ta zmiana będzie przebiegać. Tak więc, jak słyszę „projekt”, to automatycznie przychodzi mi do głowy coś takiego, że widzę kolejne kroki, natomiast z drugiej strony doświadczenie pokazuje mi, że już po pierwszym, drugim kroku nagle się okazuje, że otwiera się przed nami nowa rzeczywistość, której kompletnie nie mieliśmy zaplanowanej – i całą sztuką jest podjąć sensowne kroki, żeby w tej rzeczywistości się odnaleźć, no i jakby dalej kontynuować drogę do osiągnięcia zamierzonych celów.
Kuba: Może spróbujmy wyliczyć, tak pokrótce, te rzeczy, które sprawiają, że transformacja to jest złożona zmiana. Zmiana złożona, w której istnieją rzeczy, których nie jesteśmy w stanie zaplanować, nie jesteśmy w stanie sformułować wprost – zwłaszcza przed rozpoczęciem zmiany – ciągu takiego przyczynowo-skutkowego, czy dać gotowej recepty, że wystarczy A, B, C, D i E i na pewno uzyskamy efekt taki, jaki oczekujemy. Jakie obszary podlegają zmianie z twojego doświadczenia, Jacek, które wpływają na transformację? Jakie obszary się zmieniają?
Jacek: Zwykle to, co pierwsze przychodzi mi do głowy w takiej sytuacji, to jest zmiana sposobu organizacji pracy zespołów. Czyli często jest to przejście z takiej pracy projektowej, z takiej pracy, gdzie zespoły są powoływane tylko na czas trwania projektu, często są to zespoły, które nie posiadają wszystkich potrzebnych kompetencji do wytworzenia produktu, no to często ten taki jeden z najpopularniejszych i myślę też, całkiem prostych jednak, mimo wszystko, obszarów zmiany – to jest doprowadzenie do tego, żebyśmy faktycznie mieli zespoły zorganizowane wokół jakiegoś produktu, wokół jakiegoś obszaru, wokół jakiegoś tematu – no i żeby te zespoły faktycznie były w stanie wytwarzać gotowe produkty na koniec Sprintu.
Kuba: Z zespołowością wiąże się też ten aspekt ludzki, że jeśli potworzymy z ludzi zespoły albo przeorganizujemy istniejące zespoły, no to podlega zmianie cały ten aspekt: jak współpracujemy ze sobą, jak się znamy, jak dobrze ze sobą się komunikujemy, jak się znamy, tak nazwę to „po ludzku”, ale też, co wiemy o swoich wzajemnych kompetencjach – kto komu, w czym może pomóc. No i to też jest obszar, który nawet jeśli nie najgorzej wygląda w danej organizacji, to najzwyczajniej w świecie zazwyczaj w związku z transformacją będzie po prostu podlegał zmianie. Ludzie będą być może pracować z innymi ludźmi niż do tej pory lub w jakiejś innej konfiguracji i zaczną się uczyć nowych rzeczy, lub tymi starymi rzeczami będą się musieli wykazać, jako mentor dla zupełnie nowych kolegów lub w jakiejś innej konstrukcji ze sobą współpracując. Więc to nie jest reorganizacja strukturalna, ale też tworzenie się zupełnie nowych zespołów – w tym rozumieniu społecznym, czy w tym rozumieniu miękkim.
Jacek: I tutaj możemy się dosyć mocno zaskoczyć, kiedy okaże się, że – pomimo iż mamy zespół, który posiada wszystkie potrzebne kompetencje – okaże się, że pomimo tego – właśnie z tych powodów, o których powiedziałeś, takich czysto ludzkich – nadal mamy wewnętrzne silosy w zespole, kiedy to np. usłyszymy – i to jest przykład z życia – kiedy usłyszymy od programisty, osoby o kompetencjach deweloperskich – że ona nie ruszy jakiegoś tam konkretnego zadania z backlogu produktu, bo analityk, który jest w zespole, nie przeprowadził jeszcze analizy. To jest taki aspekt, który trudno przewidzieć, jak zachowają się ludzie, kiedy zostaną jakby… postawieni, no bo często to jest coś, na co nie mają wpływu – w nowej sytuacji, w której okazuje się, że nie tylko liczą się umiejętności takie czysto deweloperskie, ale liczy się też otwartość na współpracę z innymi osobami i też taka umiejętność wychodzenia poza swoje takie sztywne ramy, które wynikają z umowy o pracę.
Kuba: Dobra, to wspomnieliśmy, że zmieniają się zespoły – organizacyjnie i ludzko – coś, co ja bym powiedział, że też się zmienia – tu nawiązuję do naszego poprzedniego odcinka podcastu – to może też się mocno zmienić proces deweloperski, zwłaszcza jeśli do tej pory wyglądał nie najlepiej albo tak się zreorganizujemy, że jakieś nowe niedoskonałości nam się uwypuklą. Może się okazać, że musimy wprowadzić zarówno nowe narzędzia – przykładowo Continuous Integration albo wprowadzić, albo ulepszyć – wprowadzić nowe narzędzia związane z wdrożeniem, z testowaniem, z automatyzacją, ale też jakieś np. lepsze rozwiązania związane z Code Review – czyli szeroko rozumiany warsztat inżynierski – może albo być niezbędne, żeby w ogóle transformacja miała miejsce, albo chociaż się pokaże, że będzie trudno o dalsze ulepszenia, jeśli ten aspekt inżynierski nie zostanie zaopiekowany i nie zostanie poprawiony, co też zajmie pewnie mnóstwo czasu, bo to jest zarówno strona i organizacyjna, jak to poukładać w pewne procesy, jak i strona ludzka znowu – jak ludzie się mogą w ogóle do tego przyzwyczaić, żeby weszło im w nawyk, nie wiem, czysty kod albo stosowanie jakichś narzędzi automatyzacji.
Jacek: Innym aspektem, który przyszedł mi do głowy, jak opowiadałeś o tym przykładzie, jest rola działu HR, czy działu kadr, jak to w niektórych firmach jest nazywane. Zwykle okazuje się, że zespoły deweloperskie, takie pracujące zwinnie, potrzebują nieco innego profilu kandydata, niż takiej osoby, która faktycznie patrzy tylko tutaj od punktu A do punktu B i wykonuje swoją pracę – często potrzebny jest o wiele większy zasób umiejętności miękkich, komunikacyjnych, jakaś dawka empatii, umiejętność udzielania informacji zwrotnej, przyjmowania informacji zwrotnej. Tak więc coś, czego na początku można nie przewidzieć to jest to, że sposób, w jaki będziemy rekrutować kandydatów oraz to, gdzie będziemy ich szukać oraz w jaki sposób będziemy poddawać ocenie umiejętności kandydata – również ze względu na toczącą się transformację – mogą ulec zmianie.
Kuba: Jak wywołałeś słowo „ocena” to też HR-owe rzeczy takie w trwających czy istniejących zespołach – ocena, wyznaczanie celów, jakiś rozwój kompetencji, rzeczy związane z integracją – wszystkie te rzeczy mogą mocno się zmienić, ogólnie mówiąc, raczej powinny pójść w takie preferowane w podejściu zwinnym modele ceniące czy wzmacniające zespołowość, wspólną odpowiedzialność, rozwój kompetencji potrzebnych w zespole, a niekoniecznie indywidualizm, takie eksperctwo bez współpracy z innymi, bo to są rzeczy, które też znowu, jak wiele poprzednich wymienionych, one zajmą sporo czasu, wymagają współpracy, no i tu już na pewno jesteśmy w obszarze, który ja – ze swojego doświadczenia też powiem – to nam często dopiero wychodzi, że to jest potrzebne. Na początku się wydaje, że w sumie niewiele trzeba zmieniać dokładnie w momencie, w którym tam jakaś reorganizacja postępuje.
Jacek: Dwa obszary, które jeszcze, myślę, warto wymienić – w szczególności, jeśli pracujemy w modelu takim software house’owym, to po pierwsze to są umowy, czyli może się okazać, że jeżeli chcemy zmienić sposób, w jaki pracujemy, na bardziej zwinny, no to te umowy, które aktualnie mamy popodpisywane z klientami mogą się okazać zbyt sztywne bądź zbyt mało przewidujące to, że, przykładowo, zakres prac może się całkiem elastycznie zmieniać. Drugi taki aspekt też bardzo popularny w firmach typu software house, to jest sposób, w jaki funkcjonuje dział sprzedaży. Czyli: co komunikujemy potencjalnym klientom, jak im przedstawiamy to, w jaki sposób pracujemy, cały proces zapewniania tego, żeby klient dobrze zrozumiał też, na co się pisze, podpisując zwinną umowę, no bo to nie jest tak, że możemy pracować komfortowo, kiedy to software house jest, powiedzmy, już firmą pracującą zwinnie, a klient jest, powiedzmy, bardziej pracujący w klasyczny sposób – no, może się okazać, że ta współpraca nie będzie zachodzić tak, jak by mogła, bo potrzebne są dwie strony w pełni zaangażowane, żeby taka zwinna praca miała sens.
Kuba: Lustrzanym odbiciem – w firmach, w których rozwój produktu jest wewnętrzny – tego problemu, jest cały aspekt związany z rolą product ownera, właściciela produktu – to w dużych organizacjach będzie cała grupa wręcz ludzi odpowiedzialnych za rozwój produktu, no i lustrzane odbicie, powiedzmy, też tego procesu sprzedaży czy umów – no to też jakiś aspekt w różnych organizacjach różnie rozwiązany, może jakiegoś zarządzania inicjatywami, może jakiegoś generowania pomysłów na różne rozwiązania w produkcie i to często takie, powiedzmy, zwłaszcza większe organizacje, jeśli mają jakiś proces w okolicy zarządzania projektami, zarządzania portfelem projektów, to możliwe, że do dużej transformacji, do dużej reorganizacji jest cały ten pomysł, nie wiem, składania business case’ów, składania jakichś formatek, inicjatyw projektowych, jakichś pomysłów na działania, zarządzania tym, priorytetyzacja, oceny co należy robić, a co nie należy robić – no i to jest długa droga, bo to wiele prościej powiedzieć, żeby tego nie robić, ale to właściciele produktu często muszą to sobie jakoś zorganizować i duże organizacje często raczej będą miały ochotę podejść do tego ewolucyjnie.
Jacek: Obszar, o którym nie wspomnieliśmy jeszcze, tak wprost, to też rola menedżera ul