Pierwotny Scrum Guide z 2010 jasno skupiał się na zadowalaniu developerów. Miał na celu „robić dobrze zespołowi wytwórczemu” i chronić go przed chaosem z zewnątrz. Dla niektórych osób może to brzmieć, jakby Scrum był placem zabaw dla rozpieszczonych i rozkapryszonych dzieci oderwanych od rzeczywistości. Kiedy ta ocena bywa prawdziwa? Bo przecież nie zawsze.

Koder czy software developer?

Kluczowym elementem wydaje mi się tu świadomość, czym różni się piaskownica osoby dorosłej od piaskownicy dziecka. Nie jest tak, że dorosła osoba nie może mieć swojej piaskownicy. Oczywiście że może. Praca, na ile to możliwe, powinna być miła, przyjemna i wykonywana w otoczeniu komfortowym fizycznie i psychicznie. Zarówno dorosły, jak i dziecko, mogą być rozpieszczani. Oboje mogą mieć swoją piaskownicę, przestrzeń do zabawy, rozwoju i eksperymentów. Oboje mogą mieć zachcianki i otrzymywać kieszonkowe. Jest między nimi jednak kluczowa różnica. Tylko jedno z nich musi wziąć odpowiedzialność.

Dojrzały software developer

Istnieje liczne grono developerów (mam tu na myśli wszystkich członków zespołu wytwórczego – testerów, analityków, programistów FE czy BE, devopsów, architektów), którzy chcą wiedzieć. Mają świadomość, że tylko zespołowo mogą wytworzyć wartość, stale się rozwijają, poszerzają kompetencje (bądź co bądź, tylko Ty jesteś odpowiedzialny za swój rozwój). Chwała wam za to, że jesteście, bo dzięki Wam Scrum ma sens. Pomaga, a nie szkodzi i utrudnia. Tak pracują mądrzy, dojrzali, otwarci na dyskusje, zaangażowani software developerzy, patrzący holistycznie na produkt, nad którym pracują. Wymagają od siebie, aby wiedzieć, i biorą odpowiedzialność.

Nieogarnięty koder

Znam jednak również innych „developerów”. Czują się trochę jak wybrańcy, którym dano zabawki i wysokie kieszonkowe. Wydaje im się, że pozjadali wszystkie rozumy, choć sami nie wytwarzają żadnej wartości dla klienta. Często też nie czują się za to odpowiedzialni. Nie zarabiają na siebie, przychodzą po kolejne podwyżki i dziwią się, że nie można wystawić faktury za kolejny urlop, bo wykorzystali już 24 płatne dni. To ci, którzy z odpowiedzialnością nie są za pan brat. Bo nikt ich nie nauczył. Czasem jestem zmuszona wypowiadać te gorzkie, lecz niestety prawdziwe słowa: „To że tu jesteś i że napisałeś jakiś kod, kompletnie nic nie znaczy, sorry. A teraz idź płacz w poduszkę albo weź się ogarnij i popracujmy nad tym”.

Dojrzały Scrum

Zaczęłam się zastanawiać, co bywa przyczyną tego, że słychać opinie: „Scrum nie działa”, „Scrum jest potworkiem”, „Scrum Master jest sekretarką zespołu albo adminem Jira”. Co może powodować, że ludzie patrzą czasami na IT właśnie jak na bandę rozkapryszonych dzieci, które dużo kosztują, a oferują niewiele wartości.

I think it [Scrum] makes a developers life a lot harder, in that the team has collective ownership, everyone has to chip in and help, and we either succeed or fail together. There is a level of accountability in Scrum that is often not present in other frameworks.

Mitch Lacey

Branie odpowiedzialności

Czy to to naprawdę od początku miało tak wyglądać? Odpowiedź oczywiście brzmi: NIE. Jednak w drodze po zwinność często zapomina się o kluczowej dla Scruma odpowiedzialności i dojrzałości. Zostały tylko te miłe i wygodne elementy, które często pasują zespołom, a nikt nie uczy ich tego, że wraz z miłymi rzeczami bierze się w pakiecie też te mniej miłe. I że te miłe miały być w pewnym sensie rekompensatą za te trudniejsze i bardziej wymagające.

Zamiast tego po prostu totalnie zrezygnowano z tych trudniejszych, a później: „Ten Agile to do niczego niepodobny” albo „Scrum nie działa, bo nikt nie bierze odpowiedzialności za efekt prac, wymagania i dokumentację”, „Kiedyś to było, stary dobry Waterfall”. Skupiono się na mechanice frameworka, spotkaniach, rolach, artefaktach, wolności developera, „Nie wiem, na kiedy to zrobię”, „Trudno ocenić”, „To złożona sprawa”, „Sam nie wiem, zobaczę”, „Muszę się doszkolić”, „Potrzebuję czasu”. Dodajmy do tego wspominaną już wcześniej granulację i brak komunikacji, a efektem będzie dramat wytwórczy. Po drodze zgubiono całą esencję scrumowej zwinności – współodpowiedzialność. Zapomniano też o zaangażowaniu, szacunku do pieniędzy, otwartej komunikacji i ciągłej nauce.

Współpracuj albo zgiń

Sama nazwa Scruma wywodzi się z gry zespołowej – rugby. Kiedyś może sobie developer siedział sam i kodował w pokoju. Teraz, żeby być członkiem zespołu developerskiego, trzeba mieć też kompetencje wymagane do efektywnej pracy zespołowej. Tu się nie gra samemu do bramki. Weźmy za przykład mecz piłki nożnej. Wygrywamy i przegrywamy razem. Znamy cel, znamy kierunek. Mamy jakąś strategię, ona się może zmienić w trakcie gry, w zależności od sytuacji. Robimy wszystko, co w naszej mocy, aby na koniec osiągnąć sukces, poza podziałami na role.

Obrońca mający możliwość ataku nie powie: „Słuchajcie, no nie strzeliłem, bo to nie mój zakres zadań, mnie zatrudnili do obrony”. Żaden dojrzały piłkarz nie powie w takiej sytuacji, że to nie jest jego rola i że skupiał się tylko na pracy z piłką po jednej stronie boiska, a druga połowa go nie interesuje. No chyba że gra w lidze młodzików albo emerytów i szybko dostaje zadyszki, ale wtedy nie mamy kompletnie miejsca na Scruma i dojrzały profesjonalny development. A ile razy słyszeliście w zespołach wytwórczych: „Jestem programistą, nie testuję, od testowania jest tester” albo „To nie moja rola, żeby aktualizować narzędzie z zadaniami”. Aha, dzięki. Idź do domu i nie wracaj.

Szczera lista porad dla kodera

Zrobiłam listę oczywistości, które nie zawsze są tak oczywiste, jak się może wydawać. W moim rozumieniu podejścia zwinnego poniższe działania i postawa powinny charakteryzować dojrzałego członka zespołu wytwórczego. Jeśli ktoś dąży do tego, aby podejmować poniższe aktywności – lub przynajmniej chce zacząć – keep going! Jesteś już i tak dalej, niż ci, którzy mają to wszystko gdzieś.

Produkt

• Patrz holistycznie. Jak to, co macie zrobić, ma się do całego produktu?
• Znaj domenę i produkt, zrozum biznes. Czy to, co robicie, dostarcza obecnie największą wartość?
• Ćwicz z zespołem dzielenie domeny biznesowej na mniejsze funkcjonalne elementy.
• Zastanawiajcie się, jak elementy funkcjonalne zrealizować zespołowo.
• Mów głośno, jeśli zespół nie ma wystarczających informacji, jak coś ma działać.

Wartość

• Bądź częścią zespołu, który ma dostarczyć jakieś działające rozwiązanie.
• Interesuj się tym, jak produkt na siebie zarabia. W końcu zarabia też na ciebie. A może nie?
• Nie, nie dostarczasz tylko kawałka kodu. Zespołowo dostarczacie produkt, który ma działać na produkcji tak szybko, jak to możliwe.

Komunikacja

• Wyśmiewanie innych w pracy jest niedojrzałe. Nawet w żartach.
• To, że umiesz mówić, nie znaczy, że umiesz się komunikować. Ucz się komunikacji. Czyha w niej pełno pułapek i błędnych założeń, które podświadomie działają w naszych głowach.
• Jeśli czegoś wcześniej nie wiedziałeś, to nie tylko wina drugiej strony, bo ty też nie zapytałeś.
• Nie bądź jak zombie, nie działaj mechanicznie.
• Słuchaj innych i uczcie się od siebie nawzajem. Zadawaj pytania.
• Jesteście ekspertami, dogadajcie się sami. Nie czekajcie na koordynatora.

Współpraca

• Weryfikuj i sprawdzaj, kiedy masz okazję. Każdy może się pomylić. To nic złego.
• Pomagaj innym członkom zespołu, jeśli masz czas. Interesuj się.
• Nie zachowuj się, jakbyś pozjadał wszystkie rozumy.
• Wychodź z inicjatywą i wiedz, co robią inni w zespole.
• Współpracuj z innymi, bo sam w pojedynkę nie dostarczasz wartości biznesowej.
• Szanuj swój czas i czas innych osób.
• Jako członek zespołu wytwórczego, jesteś tak samo odpowiedzialny, jak inni.

Kompetencje

• Mów głośno, jeśli w zespole technicznym brakuje kompetencji do realizacji zakresu biznesowego.
• Naucz czegoś inną osobę. Albo zróbcie pair testing. Lub pair programming. Albo zoptymalizuj kod. TEGO PRODUKTU.
• Wiedz coś o wszystkim, i wszystko o czymś jednym.
• Poszerzaj kompetencje i wiedzę we własnym zakresie.
• Rozwijaj się w modelu T-shaped albo Pi-shaped.
• Skup się na tym, co możesz zrobić lepiej i mądrzej.

Transparentność i proaktywność

• Rozpisuj swoje zadania! Nie masz sekretarki ani asystenta.
• Nie czekaj, aż dostaniesz gotowe zadania.
• Nikt nie powie ci, co masz robić. To nie przedszkole.
• Jeśli ktoś spisuje zadania za ciebie, bo ci się nie chce, to wiedz, że wyglądasz jak analfabeta.

Etyka zawodowa

• Nie pracuj w robocie nad projektami prywatnymi, bo wychodzisz poza orbitę przyzwoitości.
• Miej pokorę i bądź pracowity. Udowodnij, że nie bez powodu dobrze ci płacą.
• Nie zrzucaj odpowiedzialności na inne osoby.
• Masz czas w pracy? Naucz się czegoś nowego, co pozwoli usprawnić produkt.
• Zachowuj się jak dojrzały profesjonalista.

Jeśli twoja postawa przypomina opis powyżej, świetnie! Wiedz jednak, że nie wszyscy mają taką dojrzałość (choć nie ma w tym złych intencji), a niektórym się po prostu nie chce. Jeszcze innych nikt nie nauczył brania odpowiedzialności. Nasuwa się pytanie, kto teraz ma ich uczyć? Pracodawca? Scrum master? Myślę, że Scrum jest przynajmniej dla tych, którzy chcą się uczyć. Chcą wziąć odpowiedzialność. Ci, którzy nie chcą i myślą, że nie muszą, powinni pracować pod pręgierzem jakiegoś zręcznego project managera, który na swoich warunkach i zgodnie z własnymi zasadami ogarnie tych, którzy sami siebie nie potrafią. Bo jako jedyny bierze odpowiedzialność. Pracując z wykorzystaniem metodyk tradycyjnych, powinien jednak, na ile to możliwe, przemycać do zespołu pewną naukę, delegować, a nie robić wszystkiego za zespół, oraz za zespół też nie o wszystkim myśleć. Może dzięki temu w przyszłości jego członkowie będą w stanie tę odpowiedzialność rozdzielić na siebie. Bo prawdziwy Scrum tej dojrzałości wymaga.

Sorry, boys.