Spotkałem się ostatnio z ciekawą tezą, która głosi, że zespół musi dojrzeć do Scrum, żeby umieć w pełni go wykorzystać. Czy taki „zespół długodojrzewający” to kierunek w którym powinniśmy podążać? Czy faktycznie musimy mieć czas, aby się rozpędzić?
Zespół długodojrzewający
Aby w pełni wykorzystać metodykę jaką jest Scrum, powinniśmy w pierwszej kolejności zadbać o to, żeby wszyscy rozumieli ją w ten sam sposób. Podobnie sprawa ma się ze zrozumieniem powodów, dla których robimy niektóre rzeczy. Zespoły, które dopiero zaczynają swoją przygodę z zwinnym tworzeniem oprogramowania mogą nie do końca czuć, w jakim celu zostały powołane poszczególne elementy zwinnej metodyki.
Nie zgadzam się jednak z tym, że Zespół Deweloperski, który nie jest zespołem dojrzałym, pomija te elementy metodyki, które tej dojrzałości nie wymagają. Doskonałym przykładem może być tutaj Sprint Retrospective. Niejednokrotnie mówiliśmy, że nie jest to łatwe spotkanie. Jest jednak najważniejszym wydarzeniem w cały procesie Scrum. I wymaga ono od zespołu zaangażowania, a także czegoś więcej – zaufania do siebie nawzajem.
Zaufanie jest składową dojrzewania. Zaufanie będzie pojawiało się w miarę zdobywania doświadczenia przez zespół. Wspólna praca, rozwiązywania problemów czy spotkania integracyjne wpłyną na ten proces pozytywnie. A stąd już bardzo blisko do rozwiązywania podczas retro tych najbardziej drażliwych problemów.
Przewodnik/mentor
Każdy z nas kiedyś robił coś po raz pierwszy w życiu. Od pierwszych kroków, które każdy z nas stawia jako dziecko do pierwszej, samodzielnej jazdy samochodem. Nauka wykonywania tych rzeczy zawsze wiązała się z asystą kogoś, kto znał się na zagadnieniu dużo lepiej niż my. Decydując się na wykorzystanie metodyki Scrum również powinniśmy mieć takiego asystenta, osobę doświadczoną, która w trudnych chwilach pociągnie zespół we właściwym kierunku.
Taką osobą w naszym przypadku jest Scrum Master. Jako osoba odpowiedzialna za rozumienie i stosowanie metodyki, interweniuje on w przypadku zauważenia niezgodności jej wykorzystania ze wzorcem. Jeśli członkowie Zespołu Deweloperskiego nie czują potrzeby uczestniczenia w którymś ze spotkań przewidzianych przez metodykę, nie oznacza to, że zespół nie jest wystarczająco dojrzały. Wręcz przeciwnie, oznacza to, że zespół prawdopodobnie nie wie, po co to spotkanie jest. Inna możliwością jest to, że zespół nie widzi korzyści płynących z uczestnictwa w spotkaniu.
Na szczęście łatwo nadrobić te zaległości.
Doświadczenie/dojrzałość
Idę o zakład, że jeśli dacie zespołom możliwość wyboru tych elementów metodyki, na które są gotowi, to zostaną wybrane tylko te elementy, które nie wymagają konfrontacji. Konfrontacja jednak, ta przeprowadzona umiejętnie, jest zbawienna dla zespołu. Daje nam możliwość zderzenia ze sobą kilku wizji, a w konsekwencji wypracowania najlepszego rozwiązania. Co więcej, zespoły, które się nie sprzeczają, są podejrzane. Czy o gotowości do pełnego wdrożenia metodyki powinna decydować dojrzałość zespołu?
Odpowiedz na to pytanie nasuwa się sama. Implementacja metodyki nie zależy od doświadczenia czy dojrzałości zespołu. Tak jak w przypadku wielu innych aspektów naszego życia, jeżeli chcemy osiągnąć sukces obiecywany przez autorów jakiegoś podejścia, musimy zaimplementować je w całości. Nie możemy uzależniać wykorzystywanych elementów od żadnych czynników. Nie wyobrażamy sobie przecież budowy domu bez okien, drzwi czy fundamentów. Stanowią one integralną część budynku, a ich brak powoduje, że nie mamy do czynienia z budynkiem!
Ostatnim aspektem jest realna groźba, że wybieranie tych elementów, które nam się podobają rozpocznie proces powolnego psucia metodyki. Na własnej skórze odczujemy skutki opisywanego już przez nas Broken Window Theory.
Wszystko albo nic
Powyższe argumenty jasno pokazują, że wybieranie elementów metodyki nie jest najlepszym wyjściem w przypadku niedoświadczonego zespołu. Jest to najprostsze rozwiązanie, na które zgodzą się wszyscy, którzy nie chcą angażować się w poznanie przyczyny problemu. Takie podejście to nie wymaga od nas żadnego nakładu pracy, ani zmierzenia się z problemami, które wyjdą na jaw.
Chęć ucieczki od trudnych rzeczy jest objawem czegoś większego. Dobry Scrum Master powinien dokonać analizy i znaleźć przyczynę, dla której zespół chce się zachować w taki, a nie inny sposób. W kolejnych krokach trzeba wyjaśnić z Zespołem Deweloperskim powody dla których się tak zachowuje i je wyeliminować. Nie powinniśmy jednak „w międzyczasie” iść na ustępstwa w zakresie elementów stosowanej metodyki!
Wielokrotnie zwracaliśmy uwagę na fakt, iż framework Scrum oparty jest tylko i wyłącznie na niezbędnych elementach. To dokładnie 3 role, 3 artefakty i 5 wydarzeń. A to chyba nie jest dużo?
