Nie stawiajcie Scruma na głowie!

Kryzys Agile, o którym pisałem pół roku temu stał się już tak widoczny, że właściwie nikt nie polemizuje już z samą tezą o jego istnieniu. Niektórzy jednak zaczęli się pocieszać, że to w sumie nic złego.

Rozumowanie, które do tego prowadzi jest takie: deweloperzy nie muszą wcale się interesować procesem, Scrumem, organizacją pracy. To my, Scrum Masterzy i Agile Coache jesteśmy od tego! My im to zorganizujemy, poukładamy, a oni będą się mogli skupić na tym, w czym są dobrzy, na wykonywaniu pracy (czyli kodowaniu).

Postawa taka jest dla mnie antytezą tego, czym Agile jest – a może raczej miał być.

Uważam tak, bo istotnym elementem idei Agile w ogólności a Scrum w szczególności to jest to, że to ludzie wykonujący pracę sami ją sobie organizowali. W Scrum organizacja narzuca być może strukturę, w tym właśnie Scrum, narzuca podział na zespoły (choć lepiej jeśli pozwoli ludziom się samym do nich przypisać lub choćby o tym współdecydować), ale o całej reszcie ma decydować zespół. Ba! Cała następna fala nowatorskich metod zarządzania klasy Holakracji idzie jeszcze dalej: ludzie (pracownicy) sami ustalają także struktury oraz podział odpowiedzialności i obowiązków, który jest przez nich dynamicznie dostosowywany zależnie od potrzeb.

Skąd ta idea się wzięła? Choćby z obserwacji, że to ludzie bezpośrednio wykonujący pracę mają najwięcej wiedzy na temat tego jak ona jest wykonywana, a zatem są w najlepszej pozycji do tego, żeby ją usprawnić, poprawić. A także z obserwacji, że jeśli ludzie mają wpływ na to jak pracują, to są bardziej zaangażowani w pracę – co powoduje, że jeszcze bardziej im zależy, żeby to dobrze działało. I tak mamy w organizacji – a przynajmniej w zespole – pozytywne sprzężenie zwrotne, które podnosi i jakość pracy i zaangażowanie. To właśnie do tego służą w Scrumie retrospekcje – robiliśmy pracę cały sprint, teraz pomyślmy jak tą pracę robiliśmy, żebyśmy robili ją jeszcze lepiej – bo nam zależy na tym, żeby robić ją lepiej.

Zresztą, Scrum wziął się stąd że zaangażowani deweloperzy i współpracujący z nimi produktowcy, menedżerowie kombinowali jak pracować lepiej. W skrócie, Scrum to jest coś co zespół robi, żeby lepiej działać (o czym już pisałem szerzej w przywołanym już artykule).

Mentalność „my wam to poustawiamy, nie musicie tego robić, wy macie kopać” jest z tym sprzeczna, wręcz szkodliwa. Obniża zaangażowanie, promuje postawę klasy „ja tu robię X od-do, a resztę mam w… głębokim poważaniu” albo „niech menedżer … ee.. Scrum Master się tym zajmie, to nie moja sprawa”. To jest po prostu stawianie Scruma na głowie, powrót do biernych deweloperów zarządzanych przez menedżerów którzy – jako ci starsi i mądrzejsi – poustawiają im świat. Czyli powrót dokładnie do tego w opozycji do czego cały ruch Agile w ogóle powstał. Innymi słowy, takie myślenie to prosta droga do tego, żeby Scrum nie był czymś co robią deweloperzy, żeby lepiej działać ale stał się czymś, co inni robią deweloperom. A to, jak już wiemy, nie działa.

Właśnie między innymi dlatego, żeby walczyć z takimi pomysłami w najnowszym Scrum Guide nie ma już ról. Są odpowiedzialności w zespole (Scrum Team). Cały zespół odpowiada za to, czy praca jest dobrze zorganizowana. Cały zespół odpowiada za to, czy jest wartościowa.

Jeśli to czytasz a masz odpowiedzialność Scrum Master apeluję: nie stawiaj Scruma na głowie! Nie próbuj we wszystkim zespołu wyręczyć, wszystkiego im poukładać. Pewnie, jak zespół jest mało doświadczony, w ogóle świeży (w sensie nie pracowali razem wcześniej) to tego układania potrzebuje więcej. Ale z czasem ma być go coraz mniej. Nigdy nie stawiaj się ponad zespołem, nigdy nie myśl, że TY im poukładasz a oni nie muszą o tym myśleć. Właśnie przeciwnie – powinni o tym myśleć. Jako SM masz dążyć do tego, żeby każdy członek zespołu czuł się odpowiedzialny nie tylko za swoje „od-do”, ale za całość: całość tego jaki produkt jest, ale także całość tego jak wygląda nasz zespół, jak wygląda organizacja, co można poprawić albo zmienić – i tak dalej.

Jeśli będzie inaczej twój zespół po prostu odrzuci Scruma, potraktuje go jako kolejny wymysł menedżerów wciskany im na siłę. A nie o to przecież chodzi.