Co czyni Programistę dobrym w swoim zawodzie? Pierwsze, co przychodzi na myśl to: znajomość różnych aspektów wybranego języka oprogramowania, zrozumienie architektury oprogramowania, wzorców projektowych i tak dalej. Nikt o zdrowych zmysłach temu nie zaprzeczy. Natomiast, czy to wystarczy?
Ośmielę się stwierdzić, że nie. I dowodem tego jest fakt, że za dawnych czasów ponad 70% produktów informatycznych ponosiło klęskę. Powodem tego najczęściej nie był brak ludzi kompetentnych technicznie, lecz to, w jaki sposób zabierali się oni za sam proces. Trochę później osoby z najbardziej wydajnych firm tworzących oprogramowanie określili zasady pracy, dzięki którym właśnie oni byli najbardziej wydajni. „Odkrywamy nowe sposoby tworzenia oprogramowania przez robienie go i pomaganie innym go robić” – tak się zaczyna dokument z opisem wspomnianych zasad. Oczywiście, chodzi o Agile Manifesto!
Potrzebne są nie tylko kompetencje techniczne, ale i odpowiednie nastawienie – agile mindset. Już ustaliliśmy, że Zwinny Developer jest lepszy od zwykłego. Dziś spójrzmy, jakie to właśnie nastawienie do procesu tworzenia oprogramowania robi Developera zwinnym. I będzie nam o wiele łatwiej zrozumieć to nastawienie, pamiętając o wartościach Scrum: Skupieniu, Otwartości, Szacunku, Odwadze i Zaangażowaniu.
Samozarządzający się zespół
Doskonale wiemy, że w Scrumie nie mamy takich ról jak Project/Product/Delievery/jakikolwiek inny Manager. Odpowiedzialność za zarządzanie (management) jest podzielona pomiędzy Odpowiedzialności Scrum. Product Owner zarządza Backlogiem, Scrum Master – procesami Scrumowymi, a Developerzy – pracą nad Przyrostem. To znaczy, że sami (jako zespół!) dzielą pracę między sobą, sami są odpowiedzialni za jej organizacje, jakość i dowożenie. Obecność takich zespołów jest jednym z najważniejszych wskaźników, że działamy w Scrumie a nie ScrumBut.
Po co to jest potrzebne? Dobrze zgrana oraz zorganizowana grupa ludzi potrafi dokonać więcej, niż jeden człowiek, co oczywiste. Potrafi też dokonać więcej, niż suma tego, co każdy z jej członków zrobiłby sam. 1+1+1 = 3, jeśli każdy działa osobno, ale 1+1+1= >3, kiedy działamy jako drużyna, bo uzupełniamy swoje słabe strony.
Co prawda, im większa jest ta drużyna, tym jej trudniej jest koordynować się z powodu dużej ilości kanałów komunikacji. W pewnym momencie wysoka wydajność będzie niemożliwa. Dlatego najbardziej wydajne będą zespoły małe. I tu właśnie widzimy zalety samodzielnego zarządzania się przez zespół: zostawiamy tylko niezbędną ilość kanałów komunikacji, a każdy z nich jest skupiony na osiągnięciu Celu Sprintu (patrz: Skupienie).
A teraz kolejne pytanie: kiedy Produkt może osiągnąć sukces? Odpowiedź jest prosta: kiedy osiągnięty będzie Cel Produktu. A co można zrobić, żeby osiągnąć ten wielki cel? Też proste: podzielić go na małe, a następnie wykonywać je jeden po drugim.
W Scrumie każdy Sprint musi mieć konkretny i sprecyzowany Cel, który swoją drogą jest krokiem zbliżającym nas do osiągnięcia Celu Produktu. Kiedy mamy zgraną, wydajną drużynę, w której siły członków są połączone w pracy nad osiągnięciem sprecyzowanego Celu, mamy o wiele większe szansę, że to się uda. Cały wysiłek idzie w jednym, właściwym dla nas kierunku (znowu te Skupienie). W innym przypadku możemy błądzić, stać w miejscu lub nawet cofać się. Nic dziwnego, że tak mało Waterfallowych produktów osiągało swoje cele.
Typowo Waterfallowy manager szkodzi Developerom nie tylko przez ciągłe prośby o status update i narzucanie im nowych zadań, pogarszając ich Skupienie. Przy ciągłej obecności przełożonego ludzie mają skłonność czuć się obserwowani i oceniani, co szkodzi Szacunkowi („skoro próbują mnie kontrolować, znaczy, że nie szanują”). Do tego, będą też bardziej skłonni zamiatać pod dywan swoje problemy, obawiając się o konsekwencje. To pogarsza Otwartość.
Trudno mieć zespół wysoko zmotywowanych ludzi, jeśli oni nie czują Szacunku do siebie. A brak Otwartości może okazać się dla produktu zupełnie fatalny.
Czy lepiej mieć zespół, który z czasem się polepsza i rozwija, czy ten, który stoi w miejscu? I znowu, zdrowy rozsądek podpowiada, że zdecydowanie wygrywa ten pierwszy. Drugie pytanie: taki zespół w ogóle jest realny? Ośmielę się stwierdzić, że tak.
Doskonale wiemy, że w Scrumie jest takie wydarzenie jak Retro. Celem tego wydarzenia jest analiza skończonego Sprintu, aby znaleźć obszary do polepszenia. Otwartość, o ile jest obecna, sprawia, że zespół będzie przeprowadzał inspekcję swoich procesów jak należy, a potem będzie się adaptował. Jeśli w Sprincie n+1 zespół będzie o 5% bardziej wydajny, niż w Sprincie n, to w ciągu 50 Sprintów różnica będzie ogromna.
Osobiście widziałem, jak w ciągu 3 Sprintów zespół znalazł i rozwiązał około 10 dużych, powtarzających się przeszkód. Boję się wyobrazić sobie, ile ten Produkt by stracił w ciągu 100 Sprintów, gdyby te przeszkody pozostały nieruszone. Czasami dużym problemem może być nastawienie lub zachowanie kogoś z Interesariuszy albo wewnętrzne zasady Organizacji. Wtedy z góry zakładamy, że taka przeszkoda nie jest łatwa do usunięcia. Mimo wszystko, kiedy Developerzy wykazują Odwagę i jednak zgłaszają ten niemiły problem, okazuje się, że jest i na niego sposób.
Uważny czytelnik teraz stwierdzi, że zapomniałem o jeszcze jednej wartości – Zaangażowaniu. Otóż, wcale nie! W rzeczywistości, jako Developerzy zwinni, cały czas mamy do czynienia z tą wartością. Bez niej nie przebudujemy grupy specjalistów na wydajną drużynę. Nie będziemy się skupiać na osiąganiu Celów Sprintu, nie będziemy otwarcie przeprowadzać inspekcji i adaptacji, a o okazywaniu Odwagi już w ogóle można zapomnieć.
Jak widać, w samozarządzających się zespołach wszystkie Wartości Scrum są stosowane przez cały czas. Praca w takim zespole i reprezentowanie sobą takich wartości to ważne, ale nie jedyne cechy Developera Zwinnego. Jakie są inne? To już temat na kolejny artkuł.
