SM jako inżynier produkcji oprogramowania 

Od jakiegoś czasu na naszych social mediach, a w szczególności na YouTube, rządzi krytyka i narzekanie na Scrum Masterów. Jest to kontynuacja pewnego trendu – wcześniej narzekaliśmy na to, że firmy i organizacje wprowadzają Scruma na siłę i nie tam, gdzie powinny, a także w ogóle nie potrafią budować Zespołów Scrumowych. Dość tego! Powiedzmy sobie, jak możemy przestać przeszkadzać, a zacząć pomagać.

Niniejszy tekst po raz pierwszy pojawił się na naszej liście mailingowej. To na niej raz w tygodniu rozsyłamy specjalnie przygotowane teksty, które czasami trafiają też na naszego bloga. Zapisz się i dostawaj #białko prosto na swoją skrzynkę pocztową!

Inżynier produkcji

Podejście zwinne i podejście lean mają wiele cech wspólnych i w wielu miejscach się przecinają. Ostatnio, gdy zostałem zapytany „No dobrze, ale jak właściwie powinien działać Scrum Master i ile powinien mieć wiedzy na temat procesu wytwórczego?” bez zastanowienia chlapnąłem „Scrum Master to taki odpowiednik inżyniera produkcji, który pracuje w fabrykach.” Zabierając się za dzisiejszy tekst wróciłem do tej myśli i nieskromnie stwierdziłem, że jest to genialne porównanie.

Sprawdźmy więc, czym się zajmuje inżynier produkcji. Przytoczę dwa cytaty z czeluści Internetu. Pierwszy z nich szczególnie wpadł mi w oko:

„Inżynier produkcji pełni nadzór nad procesami produkcyjnymi, analizuje występujące problemy produkcyjne i pracuje nad ich minimalizacją. Opracowuje dokumentację procesową w obowiązujących standardach, przeprowadza szkolenia w zakresie wymagań procesowych, jakościowych, technik i metod pracy, wspomaga produkcję w zakresie kwestii jakości, bezpieczeństwa oraz redukcji kosztów, precyzji dostaw, produktywności. Definiuje najbardziej efektywne procesy produkcyjne i nierzadko zarządza zespołem.”

Jak się do tego ma Scrum Master?

Porównajmy powyższy opis Inżyniera Produkcji i odpowiedzialności Scrum Mastera. Nadzór nad procesami produkcyjnymi? Jest. Analizuje występujące problemy i pracuje nad ich minimalizacją? Jak najbardziej, najczęściej robi to z całym zespołem. Czy przeprowadza szkolenia w zakresie wymagań procesowych, jakościowych, technik i metod pracy? Powinien! Idźmy dalej – czy wspomaga produkcję w zakresie kwestii jakości, bezpieczeństwa oraz redukcji kosztów, precyzji dostaw, produktywności? Pewnie! Scrum Master odpowiedzialny jest za efektywność i skuteczność zespołu! Czyli też definiuje najbardziej efektywne procesy produkcyjne!

Jedyne wątpliwości możemy mieć co do sformułowań „Opracowuje dokumentację procesową w obowiązujących standardach” (aczkolwiek to bardzo często SM dokumentuje nasze wspólnie wypracowane procesy i zasady) i „nierzadko zarządza zespołem” (bo zwykle tego nie robi).

To wszystko sugeruje, że możemy w końcu przestać mówić, że Scrum Mastera nie da się porównać do żadnej innej roli. Może nie bezpośrednio z projektów IT, ale jak najbardziej odpowiednik SM-a istnieje i ma się dobrze.

SM to IPO – Inżynier Produkcji Oprogramowania

Drugi cytat jest konieczny, żeby jednak pokazać, że te dwie role to nie to samo.

„Inżynier Produkcji
Głównym celem stanowiska jest tworzenie i rozwój nowych linii montażowych lub produkcyjnych.

Podstawowe obowiązki
• planowanie, konstruowanie i rozwój nowych linii montażowych lub produkcyjnych
• rekomendacja i wprowadzanie nowych metod pracy, organizacji produkcji itp.
• nadzór techniczny nad kolejnymi fazami produkcji łącznie z doborem materiałów i urządzeń
• prowadzenie nadzoru nad aktualnością dokumentacji technicznej maszyn i urządzeń

Najważniejsze kompetencje zawodowe
• umiejętność organizowania i planowania produkcji
• umiejętności związane z eksploatacją urządzeń i linii technologicznych
• umiejętność zarządzania zasobami materiałowymi
• umiejętność pracy w zespole
• znajomość metod i technik produkcji
• znajomość zasad BHP
• znajomość zasad zarządzania jakością
• uzdolnienia techniczne
• dokładność / precyzja

Najczęściej spotykane wymagania rekrutacyjne
• wykształcenie wyższe techniczne
• kilkuletnie doświadczenie w dziale produkcji
• znajomość procedur i zagadnień związanych z procesami produkcji”

Tutaj jasno widzimy, że inżynier produkcji to taki Bardzo Techniczny Scrum Master, który nawet jeśli sam nie wykonywał pracy „na taśmie”, to doskonale wie, co na którym stanowisku się dzieje, jakie narzędzia są używane, jak wygląda proces i ogólnie – co produkujemy i jak.

Praktyczny Scrum Master

Mam wrażenie, że to jest to brakujące ogniwo i powód, dla którego kiedyś Scrum Masterzy byli zbawieniem dla zespołów, a teraz często są problemem. Scrum Master musi oddychać procesem wytwórczym i nie tylko go rozumieć, ale i „czuć”. Obecnie bardzo często mamy do czynienia z SM-ami zupełnie nietechnicznymi, którzy nawet nie próbują nauczyć się produktu i procesu.

Osobiście mogę się przyznać, że najlepiej mi się scrummasterowało w zespołach, w których wcześniej pracowałem w jakiejś innej roli – nawet jeśli to było zaledwie parę miesięcy. Drugie według „miernika satysfakcji” były zespoły, które realizowały znane mi procesy. Budowa aplikacji webowych i na komórki zasadniczo wszędzie wygląda podobnie. Ponieważ robiłem to wiele lat jako programista i analityk, to doskonale wiem o co chodzi.

W ogóle praca jako analityk (zarówno biznesowy, jak i systemowy) dała mi warsztat do zrozumienia produktów i procesów. Jako SM powinniśmy rozumieć zarówno wytwarzany produkt, jak i proces wytwórczy. Czyli, powinniśmy być w stanie porozmawiać analitycznie o potrzebach biznesowych, wymaganiach i rozwiązaniach. Jako SM nigdy nie byłem bierny na refinemencie, bo moje analityczne ciągoty nie pozwalały mi siedzieć cicho.

Wracając do wiedzy o procesie wytwórczym, to tu widzę bardzo dużą zależność ze znajomością danego obszaru. Jeśli chodzi o web- i app-development, to czuję się bardzo mocno. W tematyce np. hurtowni danych mam szeroką wiedzę teoretyczną (kiedyś szedłem w tę stronę z edukacją) i mniejszą praktyczną – pewnie będę „przydatny” dla zespołu w mniejszym stopniu. Ale gdybym trafił teraz do Scrum Teamu realizującego tematy AI i Machine Learning, pewnie bym bardzo szybko uświadomił sobie, że „wiem, że nic nie wiem”.

I nie wiem jak Was, ale mnie taka konstatacja by uwierała i czym prędzej chciałbym się stać wartościowym członkiem zespołu, który wie, o czym inni mówią.

Jak zrozumieć zespół?

Scrum Master to nie jest „organizator wydarzeń scrumowych„. Wyobraźcie sobie, że opisywany powyżej inżynier produkcji ogranicza się do zrobienia porannej odprawy, analizy problemów na koniec tygodnia oraz okazyjnie przeprowadza jakieś szkolenia. Brzmi absurdalnie? Oczywiście! To skąd się biorą SM-i, którzy swoje działanie ograniczają tylko do Planowania, Daily, Review i Retro?

Ale miało być bez narzekania. Sprzedam Wam więc plan, który od teraz będę rekomendował wszystkim Scrum Masterom, którzy trafią pod moją opiekę w ramach mentoringu, konsultingu albo codziennej pracy.

Po pierwsze, zrozum produkt. Porozmawiaj z osobami „z biznesu”, zobacz co sprzedajecie, na czym zarabiacie, kim są sponsorzy, zlecający wymagania, klienci i użytkownicy (to bardzo często różne grupy osób!). Zacznij czynnie uczestniczyć w refinementach, zbieraniu wymagań i tworzeniu backlogu. Wspieraj Product Ownera w porządkowaniu Backlogu Produktu. Ale żeby podpowiedzieć PO jak dobrze sformułować wymagania i jak zapisać je np. w postaci User Stories, musisz je rozumieć! Kryteria Akceptacji to powinien być Twój drugi język!

Tu warto pamiętać, żeby uwzględnić zarówno etap zbierania wymagań (przed tym jak trafią do backlogu), jak i samo ich uszczegóławianie, zapisywanie i refinement.

Po drugie, zrozum proces wytwórczy. Koniecznie zapoznaj się z procesem wytwórczym na wysokim poziomie. Jak wyglądają wdrożenia, kto odpowiada za podniesienie wersji, ile zespołów pracuje, ile jest różnych repozytoriów kodu, jak wygląda wersjonowanie, jaką ścieżką są poprawiane błędy produkcyjne, na których środowiskach testujemy oraz kto testuje i jak. Gdzie powstają dokumenty analityczne, gdzie mamy opisane procesy, itd., itp.

Dopiero w drugiej kolejności zbadaj Scrum – o której zespół ma Daily, kto jest na obecny na Planowaniu, jak wygląda Review i ile czasu poświęcamy na refinement. Te informacje są banalnie proste do zdobycia i turbo łatwe do zrozumienia. W odróżnieniu od tych z poprzedniego akapitu, które są równie ważne dla naszego Inżyniera Produkcji Oprogramowania (w skrócie SM).

Po trzecie, zacznij być pełnoprawnym członkiem zespołu. Zainstaluj wszystkie narzędzia, których używa zespół i uzyskaj dostępy co najmniej do dokumentacji, wymagań, kodu źródłowego, scenariuszy testowych i systemu do testów. To nic, że jeszcze nie wiesz co to znaczy, że masz zrobić rebase przed mergem, ale wypadałoby z czasem się dowiedzieć. Bo to tak, jakbyś jako inżynier produkcji nie wiedział czego dotyczą ustawienia pewnej maszyny.

Zacznij też chodzić na wszystkie spotkania związane z poszczególnymi specjalizacjami. Np. ogólne spotkania testerów, spotkania o testach automatycznych, standardach kodu, standardach dokumentacji, warsztaty produktowe dla PO i biznesu, prezentacje nowych idei, budowanie roadmapy, itd.

Po czwarte, zacznij udzielać się w pracach zespołu. Dla mnie zawsze najłatwiej wejść w tematy analityczne, ale do zrozumienia produktu przydają się też tematy testerskie. W zależności od technologii, potencjalnie mógłbym też poprawiać jakieś proste błędy. Nie muszę jednak „udzielać się” osobiście (realizować zadań w Sprincie), bo bardzo często dostępy dostaniemy w trybie „tylko do odczytu”. W takiej sytuacji zacznijmy pracować razem z innymi – mob programming czy pair programming jeszcze nikogo nie zabiły, więc możemy raz na jakiś czas połączyć się z kimś i popatrzeć tej osobie na ręce (programiście, analitykowi, testerowi, UX-owcowi, Product Ownerowi, itd.).

I dopiero po piąte, zacznij optymalizować. Najpierw proces wytwórczy, a potem samo wykorzystanie Scruma. W większości przypadków głównym problemem nie jest godzina Daily albo fakt, że biznes nie przychodzi na Review, tylko np. konieczność uzyskania akceptu Wszystkich Świętych na każdego merge’a albo fakt, że o wymaganiach dowiadujemy się dopiero na Planowaniu, bo wtedy trafiają one do nas od interesariuszy.

Jasne, na część z tych problemów odpowiedź ma sam Scrum i robiąc niektóre rzeczy lepiej (zbierając wymagania wcześniej; robiąc poprawnie refinement, na który zaprosimy też osoby z biznesu; włączając osoby z zespołu do procesu eksplorowania rozwiązań) będziemy w stanie zaadresować te Poważne Problemy.

Wymagająca rola Scrum Mastera

Czy to brzmi jak dużo pracy? Oczywiście! Jeżeli ktoś chce być pełnoprawnym, przydatnym Scrum Masterem z krwi i kości, to – moim zdaniem – powinien być Inżynierem Produkcji Oprogramowania, czyli odpowiednikiem inżyniera produkcji. A to jest rola o określonych umiejętnościach i niemałej wiedzy.

Na koniec przypomnę, że ekipa #białko nieustannie się rozrasta i mamy na pokładzie kilka osób o różnych specjalnościach, które z radością wesprą potrzebujących. Oferujemy mentoring, wsparcie doraźne, konsulting, a także możliwość po prostu umówienia się z nami na godzinę (lub więcej), żeby przedyskutować Wasze problemy i wspólnie znaleźć rozwiązanie. Piszcie do nas.