• Agile,  Zarządzanie

    Czemu pracuję z korpo?

    Ostatnio kolega Agile Coach zapytał mnie czemu przy moim sceptycyzmie wobec koncepcji „transformacji Agile” w korporacjach wciąż szkolę i doradzam w tychże korporacjach.

    Robię tak czterech powodów:

    • po pierwsze rozróżniam „bycie Agile” od stosowania metod Agile – w korpo da się zastosować metody Agile (np. Scrum czy Kanban w teamach, Nexus albo LeSS przy większej skali itp.) i uzyskać w ten sposób mniejszą lub większą poprawę (w tym mam na myśli zarówno poprawę wyników biznesowych czy wskaźników produktowych jak i poprawę jakości życia tych, którzy tam pracują a ściślej tej jego części, którą spędzają w pracy),
    • po drugie mam dużo szacunku dla ludzi, którzy mimo wszystko próbują zmieniać duże organizacje (co zawsze podkreślam) i w związku z tym ich w tym wspieram – zwłaszcza kiedy mnie o to poproszą; nawet jeśli nie mam wiary w to, że ich wysiłek przyniesie długofalową głęboką zmianę w ich organizacjach to przynajmniej może przynieść (i najczęściej przynosi) pewne konkretne efekty i korzyści w ich zespołach a czasem i większych grupach,
    • po trzecie nie uważam, że zjadłem wszystkie rozumy i jestem otwarty na przypadek, który przekona mnie, że nie mam racji,
    • po czwarte „nie potrzebują lekarza zdrowi, lecz ci, którzy się źle mają”. I tu mała metafora: przychodzi do lekarza facet chory na płuca, który tak poza tym pali. Wiadomo, że póki pali wyleczyć się go całkiem nie da. Ale trochę mu pomóc, wydłużyć życie, podnieść jego komfort i owszem. Leczyć czy pryncypialnie odmówić? Ja wybieram to pierwsze.

    Wciąż uważam, że nie da się przerobić korpo na „zwinną firmę” (co wielu wciąż obiecuje) metodą transformowania (a więc przekształcania) istniejących struktur i procesów. Da się w ten sposób uzyskać pewne usprawnienia (i to jest coś warte), ale nie stworzyć nową formę organizacji, nową jej wersję. By tego dokonać trzeba ją zbudować od zera – albo jako startup albo jako „nowotwór” obok firmy-matki, który ją w końcu „zje” (to np. poleca John Kotter). W każdy przypadku – czy to by uzyskać pewne usprawnienia czy to by zbudować coś nowego – pomocna jest wiedza. Tej wiedzy dostarczam jak umiem najlepiej.

    Tak na marginesie „Agile” jest w ogóle za małym konceptem, żeby na nim zbudować nowe organizacje. Za małym, bo skoncentrowanym na oprogramowaniu – a przynajmniej produktach – a tu trzeba objąć więcej i pochylić się głównie nad organizacją jako taką a nie tylko niektórymi procesami, samą organizację poddać empirycznej ewolucji. Do tego zmierza Holakracja i inne podobne podejścia. Być może to byłoby w stanie zmienić istniejące organizacje od środka. Ale to temat na kolejny post/artykuł.

  • Agile,  Zarządzanie

    Drugi list do Scrum Masterów

    Wszyscy zapewne już czytali mój „List do Scrum Masterów” (nie czytali? nadrobić!). Wpisuje się on dość dobrze w to, na co kładziony jest największy nacisk podczas szkolenia Scrum Masterów oraz później przy dalszym rozwoju w kierunku Agile Coacha (np. w naszej Agile Coaching Academy) – oduczenie ludzi postawy dyrektywnej. Innymi słowy pisząc ów list jak zwykle myślałem o wybiciu ludziom z głowy rozwiązywania problemów zespołu metodą zarządzenia jak ma być, rodzielenia co kto zrobi i poganiania do roboty metodą kija i marchewki. Przekaz jest w skrócie taki: jako Scrum Master nie decydujesz, nie narzucasz, nie kierujesz i nie mówisz ludziom co konkretnie mają robić.

    Poświęcanie uwagi walce z postawą dyrektywną jest dlatego uzasadnione, że jest to postawa domyślna, najczęściej przyjmowana przez ludzi zupełnie odruchowo, która kompletnie nie buduje zespołu. Odejście od niej wymaga świadomego wysiłku – pisząc i mówiąc o tym dużo staramy się Scrum Masterów zachęcić do podjęcia tego wysiłku.

    Jednak ostatnio obserwuję coraz częściej zjawisko, które każe mi się zastanowić czy ten przekaz nie jest aby zbyt jednostronny. Mianowicie zaczynam się spotykać z problemem niejako odwrotnym – problemem Scrum Mastera „bezradnej sierotki”. Jest to taki Scrum Master, który nie próbuje nic zespołowi narzucać i w ogóle nic nieprzyjemnego o nim samym mu nie mówić, żeby przypadkiem nie zaburzyć samoorganizacji albo nie wyjść z wąsko postrzeganej roli „servant lidera” rozumianego najczęściej jako „dobry wujek”. Dobry przykład to pewien Scrum Master, który żalił się, że jego zespół ma złą relację z Product Ownerem i bardzo się zdziwił na uwagę, że ta relacja znacznie by się poprawiła gdyby zespół zaczął dostarczać co sprint działającą wersję produktu z funkcjami, których PO oczekiwał. A jeszcze bardziej się zdziwił kiedy otrzymał sugestię, że jest jego zadaniem coś z tym zrobić – w szczególności powiedzieć zespołowi, że sobie nie radzą i skłonić do zastanowienia się co mogliby robić lepiej tak, żeby to zmienić.

    Dobrzym przykładem sytuacji, w której Scrum Master działa dyrektywnie i konkretnie zarządza jak ma być to wprowadzanie Scruma w zespole, który wcześniej z niego nie korzystał. Wtedy konieczne jest często bezdyskusyjne narzucenie wszystkich jego elementów. Oznacza to, że Scrum Master po prostu mówi, że będzie Daily Scrum (do dyskusji w zespole może być o której dokładnie godzinie i ew. gdzie ma się on odbywać), że będzie Sprint Backlog (do dyskusji zespołu w jakiej dokładnie formie i ew. gdzie ma wisieć), że będzie Kryterium Ukończenia (Definition of Done – do dyskusji zespołu co dokładnie w nim będzie) – i tak dalej. Również obecność członków zespołu na Daily czy Retrospekcji nie jest do dyskusji – Scrum Master ma prawo tego wręcz wymagać.

    Pierwszy, drugi, trzeci Daily Scrum Scrum Master powinien poprowadzić, wręcz pokazując ludziom w zespole co mają mówić. Ale oczywiście już od pierwszego Daily Scruma SM nie powinien „odbierać raportów” czy stać w centrum pozwalając, by ludzie do niego mówili. Już wtedy może też np. wprowadzić jakiś element zapobiegający stałemu mówieniu w tej samej kolejności (np. jakiś token).

    Za to pierwsze retrospekcje powinien Scrum Master po prostu poprowadzić od A do Z, przygotowując odpowiednie ćwiczenia zawczasu, nie oczekiwać, że ktoś z zespołu będzie chciał to zrobić. I trzymać się tego tak długo, aż po zespole nie zacznie być widać, że zaczynają rozumieć po co te wydarzenia są. Wtedy można zacząć proces przechodzenia z postawy nauczyciela ku postawie bardziej doradcy, mentora i coacha.

    Podobnie, jeśli doświadczony, dojrzały zespół popadnie w jakąś patową sytuację Scrum Master może musieć zdecydowanie wkroczyć, zarządzić spotkanie, dyskusję, ekstra retrospekcję itp. a więc użyć posiadanych przez siebie narzędzi do przywrócenia zespołu do dobrego stanu. Gdy tylko zespół zacznie ogarniać swoje problemy natychmiast Scrum Master wycofuje się pół kroku na pozycję coacha zespołu.

    Tak więc na wszelki wypadek piszę wyraźnie: nie jest tak, że jako Scrum Master nie masz w ogóle prawa nic nigdy narzucić, zwrócić uwagi czy pokazać, że coś jest nie tak. I w ogóle bycie Scrum Masterem nie zawsze polega na byciu miłym a już z pewnością nie polega na utrzymywaniu zespołu w dobrym samopoczuciu i błogostanie. Przeciwnie, czasem trzeba wytknąć ukrywane problemy i zmusić zespół do zmierzenia się z nimi, choć może to być dla zespołu nieprzyjemne. I oczywiście Scrum Master nie podejmuje decyzji technicznych, architektonicznych, nie rozdziela pracy itp. – jego interwencje dotyczą utrzymania spoistości i sensowności procesu oraz dobrostanu zespołu, polegają głównie na zarządzeniu spotkań, wprowadzaniu praktyk, pilnowaniu by zespół przestrzegał swoich własnych zobowiązań i umów.

    Oczywiście, wkraczanie i zarządzanie to są te elementy postawy Scrum Mastera, które stosować należy rozsądnie i z rozwagą. Bardzo wiele zależy od etapu życia zespołu i stopnia jego rozwoju. Szczególnie na początku oraz w sytuacjach kryzysowych Scrum Master musi czasem po prostu „przejąć sytuację”. Dlatego nie bójcie się tego robić gdy sytuacja tego wymaga, ale upewnijcie się, że tak jest zanim to zrobicie. Linia między „bezradną sierotką” a kierownikiem jest cienka – po niej właśnie powinien poruszać się Scrum Master. Dlatego to taka trudna rola.