Czy zespoły powinny mieć wolną rękę do ustalania sposobu pracy i wręcz być „puszczone samopas”, aby znalazły najlepszą i najbardziej efektywną drogę? Niektórzy krzykną „tak, oczywiście”, a inni będą wieścić katastrofę. A odpowiedź jak zwykle brzmi „to zależy”.
Ryzyko błądzenia
Jeśli damy naszym zespołom wolną rękę na poszukiwanie właściwego sposobu pracy, musimy liczyć się z tym, że zabłądzą. Trudno, żeby ktokolwiek z nas, gdy pierwszy raz usiądzie do jakiegoś skomplikowanego problemu, od razu wpadł na optymalne rozwiązanie. W samą zwinność wpisane jest iteracyjne docieranie do celu. I mamy tu na myśli zarówno nasz produkt, jak i nasz sposób pracy. Będziemy poszukiwać właściwego rozwiązania i właściwego sposobu dotarcia do niego.
Zespoły zwinne, żeby były faktycznie zwinne, muszą poszukiwać właściwych rozwiązań na własną rękę. Oczywiście, wspierają się doświadczeniami (swoimi i innych), eksperymentują bezpiecznie, ale to nie znaczy, że nigdy nie zabłądzą ani nie zrobią czegoś nie tak. I to dobrze, bo mogą dzięki temu się rozwinąć i tę swoją wiedzę utrwalić. Ale nie każdej organizacji to pasuje, nie każda może pozwolić sobie na takie „porażki”.
Drugim istotnym zagrożeniem jest zdatność danej grupy ludzi do pracy zwinnej. Nie każdy nadaje się do pracy zespołowej w agile’owym otoczeniu. Niektórzy bez zlecanych przez kogoś zadań do wykonania czują się zagubieni i pracują mniej efektywnie. Zawsze istnieje ryzyko, że nasza „zwinna transformacja” to świetny pomysł, ale nie z tymi ludźmi, których mamy na pokładzie. Wtedy taki zespół nie tylko będzie błądził, ale wręcz nigdy nie dotrze do wyznaczonego celu.
Jasne, pomóc tu może wsparcie osób z doświadczeniem – Scrum Masterów, Agile Coachów. Ale są i takie sytuacje, że się po prostu „nie da”. Czasami wynika to z ludzi, a czasami z samej organizacji, która chciałaby, ale ma takie ograniczenia systemowe, że nie może sobie pozwolić na stuprocentową zwinność. A czasami na żadną zwinność, bo branża, umowy, kontrakty, etc. nie pozwalają na to, żeby coś mogło pójść nie tak. Albo inaczej – nawet jeśli coś pójdzie nie tak, to musi to spełniać pewne warunki i być obsłużone w konkretny nie-zwinny sposób.
Ryzyko ograniczenia
Do napisania tego tekstu skłoniła mnie historia, którą ostatnio miałem okazję obserwować własnymi oczami. Zespoły, które były nie tylko zachęcane, ale wręcz polecono im pracę w Scrumie, miały rzucane kłody pod nogi. A to czas przeznaczony na wydarzenia Scrum trzeba było raportować zgodnie z „projektem”, którego dane spotkanie dotyczyło. I tak np. Planowanie Sprintu na którym planowane były prace dla czterech różnych klientów powinno być zaraportowane w czterech różnych miejscach. I odwrotnie – nie było tu czasu przewidzianego na takie rzeczy jak Retrospekcja, a Sprint Review było „zbędne i w ogóle niemożliwe do zrealizowania”.
Idąc dalej, wywierane zostały naciski na to, aby „Scrum Master też coś robił”, najchętniej pilnował zespołów, a także żeby „Planowania nie trwały dłużej niż x„. Podobna rzecz tyczyła się refinementu „za który nikt nie płaci”. I tak dalej, i tak dalej.
Nawet bardzo odważny i ambitny Scrum Master szybko zorientowałby się, że warunków do pracy scrumowej w tym zespole nie ma. Nikt nie szukał sposobu na to, żeby zespoły się same zorganizowały i zaczęły pracować w efektywny, przynoszący organizacji sposób. Liczyły się mierniki, „kejpiaje”, zarobek i dowożenie zakresu „w budżecie i na czas”. Nie działa się zwinna transformacja, tylko poszukiwania „bardziej efektywnego waterfalla„. Co też nie jest niczym złym, ale trzeba jasno powiedzieć, jaki cel nam przyświeca i czego tak naprawdę oczekujemy.
Co chcemy osiągnąć?
Nie wiem jak to się dzieje, ale ostatnio większość rozważań, tematów, rozmyślań zarówno w życiu prywatnym jak i zawodowym kończy się pytaniem „Po co?”. Zwykle pełna konstrukcja pytania brzmi „No dobrze, ale co chcemy osiągnąć? Jaki ma być oczekiwany efekt?”.
Bardzo bym nie chciał, żeby z tego tekstu wybrzmiał wniosek inni niż „Dobrze przemyślmy co chcemy osiągnąć i poszukajmy drogi do tego celu.” Jeśli chcemy, żeby zespoły pracowały efektywnie(j), ale w żadnym przypadku nie dopuszczamy potknięć lub tego, że przez długi czas będą one szukały rozwiązań, to jest to bardzo istotna informacja, która mówi nam „szukamy lepszego sposobu zarządzania zadaniami”, a nie „szukamy lepszego sposobu tworzenia oprogramowania, które zwiększy nam wartość dla klientów”.
Coraz bliżej jestem zdania, że na rynku brakuje bardzo konkretnego rozwiązania – niezwinnej, tradycyjnej metodyki, która czerpie z doświadczeń zwinnych, ale nadaje się dla zespołów nie będących zespołami oraz takich które mają stały zakres, nieprzekraczalny budżet lub termin, itd. Tylko pytanie, co w taki sposób można ugrać? Czy doświadczenia nie pokazują, że jednak agile daje lepsze rezultaty?
Tylko jeśli decydujemy się na zwinną pracę, to nie ograniczajmy niepotrzebnie wolności zespołów. Wiadomo, samoorganizacja to nie samowolka i jakieś zasady czy granice muszą być. Ale w prawdziwej pracy zwinnej te zespoły muszą mieć możliwość popełniania błędów, wyciągania wniosków i ciągłego doskonalenia się. Nie możemy z góry zakładać, że „wszystko zawsze wyjdzie, nawet jeśli jest nowe lub trudne”, a podstawą naszej firmy nie powinna być pełna kontrola tego, co się dzieje w zespołach minuta po minucie.
Ale o tym już było, między innym w tekście „Scrum nie jest dla każdego„…
