Andy Brandt

Pracując jako doradca i ekspert od metod zwinnych nieustannie spotykam się pewnym nieporozumieniem, które najkrócej streścić można w jednym zdaniu: „Agile to Scrum”. Innymi słowy polega ono na z gruntu błednym przekonaniu, że tak zwana „transformacja Agile” (czyli zmiana organizacji w nowoczesną, zwinną, sprawnie zarządzaną) polega na… wdrożeniu Scruma. Sprowadza to duży temat jakim jest Agile i w ogóle nowoczesne zarządzanie do jednej tylko metodyki pracy zespołowej, która choć bardzo dobra nie jest ani jedyną metodą Agile ani nie załatwia wszystkich problemów (zwłaszcza na skalę organizacji).

Nieporozumienie to wydaje się dość niewinne – ot, typowe niezrozumienie tematu przez osoby, dla których jest nowy. Niestety, przekonanie, że „Agile == Scrum” jest na tyle powszechne, że prowadzi do dwóch niepożądanych zjawisk, które do tego wzajemnie się napędzają.

Pierwszym są „wdrożenia Agile” polegające na odgórnym zadekretowaniu Scruma jako metodyki czy procesu, który ma obowiązywać wszystkie zespoły. Zazwyczaj początkiem takiej sytuacji jest kiedy ktoś mający władzę – menedżer działu IT, czasem prezes – zostaje „zainfekowany” fałszywym uproszczeniem, że „Agile to Scrum” czy to przez niekompetentnego konsultanta czy to wskutek lektury jakiegoś powierzchownego artykułu.

Dlaczego takie odgórne narzucenie Scruma jest złe? Scrum jest tylko jedną z wielu metod i praktyk Agile. Nie jest z pewnością metodą dla wszystkich zespołów, bo wymaga spełnienia pewnych warunków by w ogóle działać a co dopiero działać dobrze. Są to m.in. takie rzeczy jak wspólnota pracy (członkowie zespołu nie wykonują indywiudalnie od A do Z osobnych prac ale tworzą wspólnie produkt, dla którego potrzebne są kompetencje ich wszystkich razem i na raz) czy wyraźne cele (sprintu i produktu). Generalizując Scrum jest najlepszy dla tworzenia nowych produktów, przechodzących fazę szybkiego rozwoju funkcjonalnego, przy pomocy zaangażowanych zespołów profesjonalistów, w firmach, których kultura zbudowana jest wokół pięciu wspierających Scrum wartości. Niestety, w wielu organizacjach tej szerzej wiedzy o Scrumie brak. Brak także wiedzy o innych metodach Agile, czasem nawet wręcz brak świadomości ich istnienia.

Zatem zamiast narzucać dekretem Scruma należy raczej ustalić cele wprowadzania metod zwinnych, zapoznać się z ich teorią i różnymi dostępnymi opcjami po czym wybierać dla każdego zespołu te metody, które pasują do niego – i tego co robi. A także spojrzeć na organizację szerzej, zająć się takimi rzeczami jak cele, metryki, kultura itp.

Drugi problem często występujący razem z pierwszym jest tzw. „mechanistyczny Scrum”, a więc „wdrożenie Scruma” polegające li tylko na przemianowaniu ról (np. z Project Managera na Product Ownera) i przymuszeniu zespołów do odbywania przepisanych w metodzie spotkań. Typowym (choć nie jedynym) symptomem takiej sytuacji jest uczynienie oficjalnym standardem organizacyjnym łączenia roli Scrum Mastera i developera w zespole oraz brak dbałości o odpowiednie przeszkolenie tych Scrum Masterów (że nie wspomnę o zespołach).

W efekcie uzyskuje się niewiele korzyści z metody – jeśli w ogóle jakieś. Ponieważ nikt nie rozumie tak naprawdę po co są te spotkania i cała reszta, a rzecz została narzucona bez sprawdzenia czy dla danego zespołu ma sens to zamiast zwinnych wydajnych zespołów uzyskujemy ludzi, którzy bez przekonania – a potem z rosnącą niechęcią – odgrywają nakazany przez kierownictwo teatrzyk. „Mechanistyczny Scrum” nagminnie towarzyszy odgórnie zadekretowanym zuniformizowanym „wdrożeniom Scrum”, bo ma dokładnie taką samą przyczynę – brak głębszej wiedzy i zrozumienia choćby samej metody (a więc tego dlaczego Scrum jest taki, jaki jest, dlaczego składa sie z takich a nie innych elementów, czemu służy i gdzie działa najlepiej), że nie wspomnę o Agile jako szerzym zjawisku.

Najgorsze jest w tym jest jednak nawet nie to, że efekty takiego wprowadzenia Scruma są mierne – dużo gorsze jest to, że nikt nie zdaje sobie sprawy z tego, że to, z czym mają do czynienia ma się nijak nie tylko do Agile ale nawet do Scruma. W efekcie organizacja produkuje całe zastępy ludzi, którzy są święcie przekonani, że pracują w Agile i świetnie wiedzą na czym polega Scrum bo przecież pracowali w nim (czasem kilka lat) – którzy tak na prawdę nie mają ani o Agile ani o Scrum pojęcia. Ta nieuświadomiona ignorancja jest niezwykle trudna do wyleczenia – najczęściej zdarza się to dopiero kiedy delikwent trafi wreszcie do miejsca, w którym Scrum czy jakaś inna metoda Agile jest naprawdę dobrze stosowana. Z tego powodu organizacja z mechanistycznym, zadekretowanym Scrumem jest czymś w rodzaju rozsadnika zarazy. Wychodzą z niej ludzie, którzy następnie w innych organizacjach opowiadają że „Scrum nie działa” lub co gorsza uważając się za doświadczonych reklamują się jako konsultanci od Scruma (bo nic innego nie znają – jak w tytułowym dowcipie o człowieku, który miał tylko młotek więc wszystko wyglądało mu jak gwóźdź), którzy w kolejnych organizacjach „wdrażają Scruma” w sposób, który znają z doświadczenia, co produkuje kolejnych zrażonych – i kolejnych zarażających.

Walczyć z tym fenomenem można w jednyny sposób, a mianowicie przez rzetelną wiedzę nie tylko o Scrumie, nie tylko o Agile, ale w ogóle o nowoczesnym zarządzaniu. I to staram się robić m.in. w Code Sprinters, a także na tym blogu, w moich książkach i tak dalej. Metoda to żmudna, bo wiedza ta jest mniej „seksi” od uproszczeń w rodzaju „wdróżmy Scruma i będzie Agile”, ale za to skuteczna na dłuższą metę.