Choć rzecz działa się wiele lat temu, to wspomnienie jest zaskakująco świeże. Było późne grudniowe popołudnie, już po zmierzchu, ale nie dało się tego odczuć w biurowym wnętrzu oświetlonym designerskimi żyrandolami. Zresztą uśmiech mojego interlokutora był tak szeroki i promienny, że gdyby skierować nań choćby maleńką ledową diodę, odbite od śnieżnobiałego szkliwa siekaczy promienie zdołałyby rozświetlić nawet Rów Mariański.
Jako młody – nie żebym dziś uważał się za poturbowanego przez metrykę, mam na myśli tylko ówczesne doświadczenie – scrum master bardzo wziąłem sobie do serca krótką wzmiankę ze Scrum Guide’a o tym, że zespoły (…) są (…) międzyfunkcjonalne (ang. cross-functional). Zespoły międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi od osób nienależących do zespołu. Na dodatek, jak to młody scrum master, wywodów Daniela Pinka wysłuchiwałem prawdopodobnie częściej niż własnej małżonki, więc koncepcja dążenia do mistrzostwa jako jednego ze źródeł motywacji mocno działała na moją wyobraźnię.
Napędzany takimi stymulantami usiłowałem wycisnąć od promiennie uśmiechniętego managera członków zespołu developerskiego jednoznaczną deklarację na temat perspektyw rozwoju, jakie owym członkom miał on zamiar zapewnić. Zza garnituru śnieżnobiałych zębów padła odpowiedź, której chyba już nigdy nie wymażę z pamięci. Tak obezwładniającego w swoim monumentalnym absurdzie komunikatu nie zdołał wygenerować nawet Bezimienny Bohater Internetów, ten od będę grał w grę. Tomb Raider.
– Poślemy ich na szkolenie z autoprezentacji – mówił jak zwykle uradowany manager.
– Czemu z autoprezentacji? – usiłowałem dociec, bo chodziło o inżynierów, którzy mogliby rzucić świat na kolana, gdyby na przykład dorzucić trochę węgla do ich pieców automatyzacji testów albo, na przykład, TDD.
– Bo jak robicie demo po sprincie, to zawsze prezentuje product owner, a oni siedzą. No i budżet szkoleniowy trzeba spalić.
Pozwolę sobie pominąć wzmiankę o demo, bo zagadnienie przeglądu sprintu to temat na inną okazję. Dopiero kilka tygodni później, kiedy doszedłem wreszcie do siebie po tej wstrząsającej wymianie zdań, zdałem sobie sprawę, że w wypowiedzi promiennie uśmiechniętego rezonował chyba ten chętnie powtarzany wers o rozwoju poza strefą komfortu. Sęk w tym, że jeśli go spłycić, zostaje banał godny Paula Coelho. Może nawet ciężko skacowanego Paula Coelho. Prawdę mówiąc, wolałbym pracować z zespołem developerskim, którego członkowie mają mikre zdolności autoprezentacji, za to rozwijają wachlarz kompetencji niezbędnych do budowy produktu, niż na odwrót. Chyba że produktem zespołu byłyby tutoriale dla obwoźnych sprzedawców, to przepraszam.
Tak czy inaczej, nie zmienia to faktu, że rozwój zespołów developerskich jest niejako wpisany w ich konstytucję jako nieunikniona konsekwencja przywilejów (i wyzwań) samoorganizacji i samowystarczalności. Ale – i tu być może idę w poprzek rozpasanego kultu samodoskonalenia – nie rozwój za wszelką cenę. Niekoniecznie poza godzinami pracy. Jeżeli zespół tworzą pasjonaci, którym kwadrans bez rozważań o zawiłościach kodu odbiera dech, to świetnie. Nie znaczy to jednak, że managerowie – nie wyłączając trwale uśmiechniętych – mają prawo oczekiwać, że każdy członek zespołu będzie dokształcał się po godzinach, na jednej szali kładąc doskonalenie swoich kompetencji, na drugiej – hobby albo życie towarzyskie lub rodzinne. Cóż warte jest zresztą życie rozwojowe, ale mdłe i jednowymiarowe? Przecież jest coś głęboko ludzkiego w wersach piosenki:
Czasem, w dobry dzień, siedzę i myślę
A czasem tylko siedzę
Na inną okazję pozostawię sobie wątek rozważań o tym, że w epoce galopującej cyfryzacji, postmodernistycznego rozszczepienia ról społecznych i – nie tylko scrumowej – interdyscyplinarności wąski rozwój zawodowy odarty z szerokiego kontekstu rozwoju osobistego przypomina zbrojenie armat pociskami bez zapalników. Jestem zdania, że nowoczesne organizacje, które chętnie podkreślają w procesach rekrutacyjnych inwestycję w człowieka, traktują tę inwestycję nie jako zapisy w pustosłowiu misji i wizji, ale jako modus operandi przynależny codziennej robocie.
I nie chodzi mi tylko – a na pewno nie wyłącznie o – rozpasane budżety szkoleniowe. Chodzi mi również o kulturę promocji (samo)rozwoju. Product ownerom znana jest najpewniej koncepcja ćwiartek backlogu, które mają odzwierciedlać różne aspekty rozwoju i utrzymania produktów. Ćwiartki, jak to ćwiartki, są cztery:
- Wsparcie
- Budowa nowych funkcjonalności
- Spłata długu technicznego
- Innowacje architektoniczne
Naturalną – i zupełnie zrozumiałą – potrzebą ambitnego właściciela produktu jest, rzecz jasna, inwestycja w budowę nowych funkcjonalności. Bo przecież klient jest na pierwszym miejscu, bo przecież scrum master truje na okrągło, że odpowiedzialnością właściciela produktu jest maksymalizacja wartości produktu i pracy zespołu deweloperskiego… Tak, jasne, święta prawda, przecież Schwaber i Sutheerland to łebscy panowie i głupot nie pletli, a jeśli nawet pletli, to nie publikowali ich na łamach Scrum Guide’a.
Spotkałem się w swojej praktyce, lata po epoce promiennie uśmiechniętego, z zespołem, który w swoich backlogach sprintów pozostawiał przestrzeń zapełnianą podczas planowania zadaniami związanymi z rozwojem developerów. Była to możliwość, nie przymus – każdy członek zespołu mógł wprowadzić do planu sprintu zadanie, którego owocem było poszerzenie kompetencji. Chętnie z tego rozwiązania korzystano, zwłaszcza wobec ograniczonych budżetów szkoleniowych proponowanych przez organizację. Co ciekawe, ekipa potraktowała tę praktykę dość kanonicznie z punktu widzenia scruma i pozyskaną wiedzę prezentowała jako swój przyrost na przeglądzie sprintu. Zadania zdarzały się różne: skok na główkę w słabo rozpoznaną do tej pory technologię, lektura źródeł branżowych, gościnne występy w innym zespole. Product owner nie bojkotował takich inicjatyw. Promował je, choć był poddawany ustawicznej presji rozwoju produktu. Udostępniał ekipie przestrzeń. I był to jeden z najtrzeźwiej myślących product ownerów, z jakimi miałem okazję współpracować. Z perspektywy czasu jestem pewien, że tego rodzaju zadania przynależały do ćwiartki poświęconej spłacie długu technologicznego. Albo i lepiej: one służyły zapobieganiu długowi technicznemu poprzez zasypywanie rowów długu kompetencyjnego.
Bo to ludzie zaciągają dług techniczny, czyż nie?
A ludzie i interakcje ponad procesy i narzędzia, tak?