Niektórzy chyba zapominają, że techniki, narzędzia i metodyki to rozwiązania pewnych problemów. Im bardziej popularne jakieś rozwiązanie, tym bardziej uniwersalne powinny być problemy, które rozwiązuje. Niestety, problem zaczyna się, kiedy najpierw wybieramy rozwiązanie, a o problemach… zapominamy.
Po co pracujemy iteracyjnie?
Dawno, dawno temu zaczynaliśmy pracę w Sprintach, ponieważ w trybie ciągłym wszystko nam się rozłaziło. Dobrze wiemy, że postawienie ograniczenia czasowego zwiększa efektywność (patrz chociażby Prawo Parkinsona). Bez twardych terminów wiele rzeczy się nie zadzieje albo będzie trwało dużo dłużej, niż powinno. Sprinty walczyły więc z niekończącym się analizowaniem wymagań, debatowaniem nad tym, jak coś zrobić, oraz brakiem przewidywalności. Analogicznie bez Sprintów rzeczy ciągnęły się miesiącami, zamiast być zamykane.
Z kolei sam Scrum powstał po to, żeby „jakoś” zrealizować skomplikowane przedsięwzięcie, w którym wymagania dopiero poznajemy, a rozwiązania będziemy zespołowo wypracowywać w trakcie pracy iteracyjnej. Bez niego ludzie rzucali się na wieloletnie projekty, które próbowano ujarzmić w harmonogramy i skomplikowane plany. To oczywiście zazwyczaj nie działało, a konsekwencjami były opóźnienia i wysokie koszty, a często także rozwiązania niedopasowane do zmieniających się potrzeb.
Ba! Nawet SAFe powstawał (prawdopodobnie) ze szczytnych pobudek, próbując ujarzmić większe projekty i zaadresować problemy związane ze współpracą pomiędzy zespołami, interesariuszami, itd. Tak samo rytm wyznaczany przez Program Incrementy (od niedawna: Planning Intervals) miał za zadanie odpowiedzieć na wyzwania związane z synchronizacją powiązanych zespołów, zapewnieniem wspólnego celu, jasnych priorytetów i wypracowaniem krótkoterminowego planu uwzględniającego bieżące zależności. W teorii.
Każde z wymienionych rozwiązań odpowiadało na jakiś konkretny problem. Najpierw był problem, a dopiero później – próba dopasowania lub wypracowania rozwiązania. Nie odwrotnie.
Rozwiązanie kontra Problem
Wyobraźmy sobie organizację, w której regularnie borykamy się z problemem braku gotowych tematów do zaplanowania na najbliższą iterację. Może to być sytuacja, w której tuż przed PI Planningiem nie mamy nic dogadanego. Może też być gorzej. Rzeczy, które powinniśmy robić, zostały właśnie skasowane i pojawił się zupełnie nowy zestaw wymagań. Podobną sytuacją jest ta, w której niedługo po zaplanowaniu się, z wcześniej nieprzewidzianych powodów, całkowicie zmienia się zakres.
Podobne problemy mogą wystąpić w Scrumie, gdzie długość Sprintu nie jest dostosowana do realiów naszej pracy. Na przykład, nie udaje nam się ukończyć większości prac, bądź też na każdym planowaniu nie mamy gotowych rzeczy, które można by zrealizować.
W obu przypadkach możemy spotkać się z prośbami o przesunięcie planowania do przodu bądź w tył. Oznaczałoby to zmienną długość iteracji, czyli PI albo Sprintu, co – jak dobrze wiemy – nie sprzyja powtarzalności i przewidywalności.
Jeszcze częściej usłyszymy, że nie ma możliwości przełożenia planowania i powinniśmy zacząć z tym, co mamy gotowe, a resztę ustali się w trakcie. Takie podejście ma działać jako narzędzie samodyscyplinujące zespoły. Jeśli tym razem będziemy odczuwać niewygody związane z tym, że nie byliśmy gotowi na zaplanowanie, to jest szansa, że następnym razem zrobimy coś lepiej. I to działa, o ile faktycznie te rozwiązania (Sprinty, PI) rozwiązują jakieś problemy. Bo jeżeli nie, to tylko dokładają nam kolejnych.
Do czego ten młotek?
Jeżeli nigdy nie mieliśmy określonych problemów, a stosujemy rozwiązania, które miały je rozwiązać, to coś tu jest nie tak. Możemy osiągnąć skutek odwrotny do zamierzonego. Wszystkie „typowe” rozwiązania działają dla określonego rodzaju problemów i tylko i wyłącznie w określonym środowisku (patrz: „Scrum nie jest dla każdego„). Nie możemy jeść jak Michael Phelps w szczycie formy, licząc, że taką dietą uzyskamy jego sylwetkę. Trzeba pamiętać, że liczy się więcej rzeczy niż tylko jeden aspekt. Zapytajmy: „Skąd ta dieta? Jakie problemy ma rozwiązać?”
Dlatego tak bardzo nalegam na zadawanie pytania „Jaki problem chcemy rozwiązać, wprowadzając takie rozwiązanie?”
Stare porzekadło mówi, że jeśli masz w ręku młotek, wszystko zaczyna wyglądać jak gwóźdź. To bardzo ważna przestroga w pracy jako konsultanci, Agile Coachowie czy Scrum Masterzy, bo jeśli znamy tylko jedno narzędzie lub jedną technikę, istnieje duże prawdopodobieństwo, że będziemy ją proponować w każdej sytuacji – niezależnie od tego, czy faktycznie jest to najlepsze rozwiązanie.
Często nie ma szansy, żeby to było najlepsze rozwiązanie! Jeśli znamy tylko jedną opcję, to w rzeczywistości nie mamy wyboru. Na przykład, jeśli znamy jedynie Scruma, to nasza jedyna decyzja sprowadza się do tego, czy wdrażać Scruma w danym zespole, czy nie. Jeśli nie, to niestety nie mamy nic innego do zaproponowania.
Dość oczywistym, choć niepełnym rozwiązaniem, jest edukacja i zdobywanie doświadczeń, aby poznać więcej technik, narzędzi i metodyk. Jednak nawet wtedy, nasz proces myślowy będzie nadal opierał się na pytaniu: „Które rozwiązanie najbardziej pasuje do tego środowiska?”. O wiele ważniejsze pytanie to „Jaki jest prawdziwy problem?”.
Jaki mamy problem?
Zawsze, ale to zawsze, powinniśmy zadać pytanie: „Jaki problem chcemy rozwiązać?” Dopiero wtedy powinniśmy szukać w naszej pamięci gotowych rozwiązań albo opracować własne, dedykowane podejście. I wtedy też warto dorzucić drugie pytanie, „Skąd będziemy wiedzieli, że nam się udało?” Innymi słowy, musimy mieć jakieś mierniki, które powiedzą nam, że idziemy w dobrą stronę.
Praca Agile Coacha czy Scrum Mastera bardziej przypomina pracę konsultanta niż wdrożeniowca. Już od kilku lat firmy nie proszą nas o „wdrożenie Scruma”, lecz przychodzą z konkretnymi problemami, które trzeba jakoś rozwiązać. Co gorsza, Część tych problemów mogły wywołać same metodyki, jak Scrum czy SAFe. Szczególnie, jeśli zostały wdrożone w środowisku, które się do tego nie nadaje.
Są dwa rozwiązania. Możemy zmienić środowisko (organizację), co jest ekstremalnie trudne, ale przynosi długoterminowe korzyści, choć wiąże się z wysokimi kosztami krótkoterminowymi. Drugie podejście to dobór lepszego rozwiązania dla pierwotnego problemu. Bo przecież nikt nie chce „pracować w Sprintach” dla samej idei Sprintów czy PI-ów.
Pierwotne problemy i dawne rozwiązania
Zwykle pierwotnym problemem prowadzącym do wdrażania zwinnych rozwiązań była niska przewidywalność zespołów, wysokie koszty, których nie dało się opanować, oraz brak synchronizacji między jednostkami biznesowymi, co przy wielu zależnościach prowadziło do nieefektywnej pracy.
Jeśli ktoś zmaga się z niską przewidywalnością i ciągłymi opóźnieniami, a jednocześnie ma w firmie podejście produktowe, Scrum może wydawać się odpowiednim kierunkiem. Jednak w organizacji, która jest skostniała, hierarchiczna, gdzie departamenty rywalizują zamiast współpracować, zamiast szukać gotowych metod, skupiłbym się na identyfikacji problemów i ich stopniowym rozwiązywaniu. Oczywiście czerpałbym inspiracje z działających praktyk, które wcześniej miałem okazję widzieć, ale nie podchodziłbym do tego dogmatycznie.
Oczywiście to nie znaczy, że zaproponuję wdrożenie „połowy Scruma„, bo takie próby źle się kończą. Będę jednak korzystał z pewnych mechanizmów scrumowych, wprowadzając iteracyjnie zmiany do sposobu pracy, ale nie nazywając tego Scrumem ani żadną inną metodyką. To właśnie podejście „cały Scrum albo nic” jest jednym z powodów, dla których Scrum Masterzy są często postrzegani w negatywny sposób. Co nie znaczy, że organizacje nie są bez winy, próbując na siłę wciskać kwadratowego Scruma w okrągły otwór kultury danej organizacji.
Scrum Master bez Scruma
Dlaczego firmy zatrudniają Scrum Masterów, skoro nie mają wdrożonego Scruma? Najpopularniejsze odpowiedzi są dwie. Niektóre organizacje szukają doświadczonych specjalistów, aby uporządkowali procesy i wdrożyli Scruma zgodnie ze scrumguide’owym wzorem. Jednak duża część firm zatrudnia Scrum Masterów jako konsultantów, a nie jako osoby odpowiedzialne za zgodność ze Scrumem i efektywność/skuteczność Scrum Teamów. SM-konsultanci mają za zadanie rozwiązywać bieżące problemy, proponować rozwiązania oraz dbać o to, aby wypracowane usprawnienia były wdrożone, utrzymane i dostarczały wartość.
Krótko mówiąc, wiele organizacji utożsamia rolę Scrum Mastera z „konsultantem ds. procesów wytwórczych” (patrz też: „SM jako inżynier produkcji oprogramowania„). Ma to swoje zalety, ale patrząc na to, skąd wzięli się Scrum Masterzy i jak dotąd działali, może to stanowić pewne wyzwanie, żeby nie powiedzieć… problem.
Po co komu Scrum Master?
„Dawni” Scrum Masterzy to w większości przypadków były osoby, które albo miały duże doświadczenie jako seniorzy, team leaderzy, albo po prostu członkowie zespołu, którzy dostrzegali, że pewne rzeczy można by zrobić lepiej. Jeśli do tego mieli jeszcze jakiekolwiek doświadczenie w Scrumie, to byli w idealnej pozycji, by zacząć działać scrumowo w swoim własnym zespole na zasadzie eksperymentów. A jeśli już pracował on w Scrumie – mogli zabrać się za usprawnienia.
Z jednej strony była to osoba, która doskonale znała zespół, bo była jego częścią. Z drugiej strony, miała głowę pełną pomysłów i wiedzę o tym, jak procesy mogą działać lepiej. Dodajmy do tego przeświadczenie, że potrafi przeprowadzić te zmiany i poprowadzić zespół w kierunku efektywnego Scruma – i mamy przepis na świetnego Scrum Mastera.
Przez długi czas Scrum Master nie był zawodem, lecz rolą, którą przyjmowały osoby już pracujące w zespołach. Z czasem organizacje zauważyły, że ten scrumowy sposób pracy przynosi efekty i zaczęły go stosować na szerszą skalę. W ten sposób pojawiło się zapotrzebowanie na Scrum Masterów, którego nie dało się zaspokoić, wyłuskując ludzi z zespołów. Nie było wystarczająco wielu chętnych do podjęcia się tej trudnej, wymagającej, a czasem niewdzięcznej pracy polegającej na inicjowaniu, wdrażaniu i facylitowaniu zmian.
Do scrummasterki potrzebne były (i są!) osoby o bardzo specyficznych predyspozycjach – takie, które naprawdę lubiły ten typ pracy i potrafiły skutecznie działać z zespołem, wpływać na kierunek jego rozwoju oraz wspierać zmiany. W tym okresie środowisko scrummasterskie funkcjonowało jeszcze całkiem nieźle. Scrum Masterami były osoby, które pamiętały, jak wygląda praca Dewelopera. Wędrowali oni pomiędzy firmami, opierając swoje działania na doświadczeniu zdobytym podczas wdrażania Scruma w różnych zespołach.
Scrum Master 2024
Później jednak nastąpiła zmiana. Scrum zaczął być stosowany bezrefleksyjnie, w miejscach, do których kompletnie się nie nadawał. Jako tytułowe rozwiązanie szukające problemów. To spowodowało zwiększone zapotrzebowanie na Scrum Masterów, które zostało zaspokojone SM-ami bez doświadczenia i bez praktycznej wiedzy o materii, w której mieli doradzać.
W efekcie coraz trudniej było spotkać dobrze wdrożony Scrum, a coraz mniej osób mogło pochwalić się doświadczeniem w pracy zgodnej ze Scrum Guide. W efekcie dostaliśmy Scrum Masterów szukających dla siebie sensu w zespołach, które bardzo często nigdy nie powinny pracować w Scrumie. Kolejne rozwiązanie szukające problemów i to w dodatku niejako zagnieżdżone w poprzednim.
Podobnie jak w przypadku innych „podręcznikowych” rozwiązań, decydując się na wprowadzenie pełnoetatowego Scrum Mastera, musimy odpowiedzieć sobie na pytanie „Jakie problemy ma nam ten Scrum Master rozwiązać?” tudzież „Jakie będą z niego/niej korzyści?„. I oczywiście wypadałoby to poprzeć kolejnym – „Skąd będziemy wiedzieli, że to działa?”
I tak niezależnie od tego, co zdecydujemy się wprowadzić – iteracje, całego Scruma, osobę Scrum Mastera bądź Agile Coacha, Scrum of Scrums, PI Planning, zawsze musimy wiedzieć a) co adresujemy b) po czym poznamy, że to działa. Absolutnie odradzam wprowadzanie czegoś, „bo wszyscy tak robią” albo „bo taki jest standard”. Nie bądźmy leniwi w wyborze rozwiązań, bo możemy przypadkiem narobić więcej problemów, niż rozwiążemy. A w najlepszym przypadku zostaniemy z kolejnym rozwiązaniem szukającym swojego problemu.
