Całkiem niedawno dostałem bardzo ciekawą propozycję. Mój niemiecki klient zaproponował mi, abym został w jego firmie Scrum Masterem w zespole API. Propozycja wydaje się na pierwszy rzut oka całkiem w porządku. Możliwe jednak, że ów klient traci niepotrzebnie pieniądze, tworzy nieoptymalny produkt, nie wie gdzie tak naprawdę jest w projekcie i na dodatek stwarza sytuację sprzyjającą konfliktom wśród pracowników. Z całą pewnością nie ma też pojęcia czym tak naprawdę jest Scrum.
W Scrumie zawsze każda iteracja musi kończyć się działającym oprogramowaniem („6 poziomów działającego oprogramowania”), jednak zespół API1 nie posiada wszystkich kompetencji, aby to zrobić. Może wykonać tylko część backendową potrzebną w przyszłości frontendowi. Zespoły, które posiadają wszystkie potrzebne kompetencje, aby wykonać kolejny inkrement nazywa się interdyscyplinarnymi. Na przestrzeni lat przekonałem się, że interdyscyplinarność zespołów znajduje się na jednym z czterech poziomów. Im wyższy poziom tym zazwyczaj praca jest efektywniejsza, a wytwarzany produkt jest lepszy.
Warto sobie zadać pytanie, na którym poziomie interdyscyplinarności jest Twój zespół.
1. Zero interdyscyplinarności
Oprogramowanie jest wytwarzane w fazach. Za każdą fazę odpowiada zespół posiadający tylko jedną kompetencję. Po zakończeniu swojej pracy, wyniki są przekazywane kolejnemu zespołowi.
Przykład:
Analitycy biznesowi podczas warsztatów z klientem ustalają końcowy zakres całego projektu. Następnie na tej podstawie UX/UI designerzy tworzą grafikę dla całej aplikacji. Developerzy backendu przygotowują API, które po zakończeniu zostaje przekazane frontendowcom. Gdy prace programistyczne są zakończone do pracy wkraczają testerzy.
Konsekwencje:
Każdy zespół skupia się przede wszystkim na swojej domenie, brakuje wspólnej perspektywy. Zamiast skupiać się na sukcesie całego produktu liczy się wykonanie własnej części. To trochę tak jakby pięć osób malowało obraz, gdzie każdy jest odpowiedzialny za nałożenie swojego koloru. Pierwszy malarz nakłada swój kolor w całości, po nim drugi, potem trzeci itd. Najprawdopodobniej osoba nakładająca swój kolor jako ostatnia zauważy, że ich praca nie jest zgrana.
Wszystko opiera się na predykcji. Designerzy nie zawsze będą wiedzieć, że coś jest niemożliwe do wykonania przez programistów. Backendowcy podczas prac nie przewidzą wszystkich potrzeb frontendu, wykonają API w niewłaściwy sposób albo stworzą coś co nie zostanie nigdy użyte. To oznacza niepotrzebną pracę, czyli niepotrzebnie wydane pieniądze.
Takie zespoły mają tendencję do myślenia kategoriami „my i oni”, co skutkuje tworzeniem się się swojego rodzaju silosów kompetencyjnych. Gdy deadline się zbliża, a np. API nie działa tak jak powinno albo coś w projekcie designu jest coś niejasne to zaczynają się wzajemne oskarżenia. Widziałem to aż nazbyt często. Jeżeli zespoły pochodzą z różnych firm, konflikt w razie problemów jest praktycznie murowany.
2. Scrumfall / Fragile
To bardzo podobny przypadek do poprzedniego. Z tą różnicą, że zespoły pracują w iteracjach. Wyniki prac każdego z nich są przekazywany „dalej” w kawałkach. Dopiero ostatni w kolejce zespół jest w stanie wydać kolejny inkrement czyli kolejną wersję działającego softu i poddać go weryfikacji.
Przykład:
Zespół analityków określa potrzeby biznesowe i tworzy wymagania. Powstaje z nich Product Backlog. Stosowane jest Definition of Ready3, które nie pozwala frontendowi zacząć pracy bez całego projektu UX i API. Po zakończonej pracy programistycznej testerzy sprawdzają jakość i gdy występują bugi, wrzucają je do Product Backlogu odpowiedniego zespołu.
Wszystkie zespoły pracują w dwutygodniowych Sprintach.
Konsekwencje:
W zasadzie występują w tym podejściu wszystkie problemy wspomniane wcześniej. To co się poprawia to czas reakcji na wszelkiego rodzaju zmiany i problemy, np. frontend dalej dostaje API nie do końca odpowiadające potrzebom, jednak w kolejnym „Sprincie API” zostają wdrożone zmiany.
Pojawia się tutaj niestety problem, którego nie było wcześniej. Pomimo tego, że to podejście nie ma nic wspólnego ze Scrumem, wiele osób pracując w ten sposób za Scruma je uważa bo „przecież mamy Sprinty”. Jestem bardzo daleki od stwierdzenia, że Scrum jest w każdym przypadku najlepszym podejściem, jednak jak mawiał Konfucjusz „Naprawę państwa należy zacząć od naprawy pojęć”. Jeżeli nie pracujemy w Scrumie to powinniśmy o tym chociaż wiedzieć.
3. Zespół specjalistów
Zespół jest złożony ze specjalistów, którzy razem posiadają wszystkie umiejętności, aby wydać kolejną wersję softu.
Przykład:
Zespół składa się z analityka, designera na pół etatu, backendowca, 2 frontendowców i testera. Pracują w 2 tygodniowych Sprintach i po każdym z nich wydają kolejną wersję działającego softu. Razem planują, co musi zostać zrobione, aby stworzyć kolejny inkrement.
Konsekwencje:
Ponieważ różni specjaliści planują swoją pracę razem, ich współpraca jest o wiele lepsza. Deweloperzy skupiają się na poszczególnych funkcjonalnościach, a nie na swojej warstwie (np. frontend). To tak jakby wszyscy razem malowali fragment obrazu np. dom. Pomimo tego, że dalej każdy z nich odpowiada za swój kolor, to jednak na bieżąco dyskutują, co w danym momencie poszczególne osoby powinny zrobić, aby końcowy efekt był najlepszy.
Wszystkie napotkane problemy rozwiązywane są przez zespół wspólnie. Konflikty oczywiście dalej mogą wystąpić, jednak są o wiele rzadsze i mniej poważne. Pojawia się myślenie „my” jako zespół. Wpływa to bardzo pozytywnie na motywację.
Dzięki bliskiej współpracy można znacząco skrócić czas od powstania pomysłu do zrealizowania go w postaci działającego oprogramowania. Możliwe jest podejście empiryczne. Co Sprint można weryfikować, czy rozwój produktu zmierza we właściwym kierunku poprzez ciągłe feedbacki klientów albo end userów. Moim zdaniem jest to też jedyny sposób, aby mieć pewność, ile tak naprawdę jest w projekcie zrobione. W tym momencie tak naprawdę zaczyna się Scrum.
To podejście ma niestety wady. Zespół składa się z wyraźnych „podzespołów”, takich jak np. designerzy, backendowcy, frontendowcy i testerzy. Po zaplanowanej pracy na Sprint może się okazać, że niektórzy specjaliści mają mniej pracy niż mocy przerobowych, np. jest o wiele mniejsze zapotrzebowanie na pracę backendowców niż zazwyczaj. To prowadzi do marnotrastwa.
Co jednak jest najgorsze to niski bus factor4. Jeżeli w zespole jest tylko jeden backendowiec, istnieje ryzyko klęski projektu, gdy go zabraknie, np. zachoruje. W niektórych przypadkach zdarza się, że ktoś kto jest niezastąpiony w zespole zaczyna w nieetyczny sposób to wykorzystywać. Byłem świadkiem, gdy taka osoba była opryskliwa dla swoich kolegów z zespołu, publicznie okazywała brak szacunku przełożonym i wymuszała regularne podwyżki.
4. Zespół developerów renesansu 🙂
Specjaliści z punktu 3 stają się Generalizing Specialists (4). To osoby posiadające wiedzę specjalistyczną w swojej głównej dziedzinie, jednak mają również wiedzę ogólną z innych obszarów zarówno technicznych jak i biznesowych.
Przykład:
W skład zespołu wchodzi specjalista od tworzenia API w NodeJS, który dodatkowo posiada kompetencje frontendowe. Jest mniej wydajny niż developerzy frontendu i musi się częściej konsultować w tej dziedzinie, jednak gdy jest taka potrzeba potrafi to zrobić. Frontendowcy pomimo tego, że nie są ekspertami od backendu potrafią sami wykonać prostsze elementy API. Developerzy natomiast są w stanie na kilka Sprintów zastąpić Product Ownera, nie mają większego problemu z komunikacją z klientem i dobrze rozumieją wizję biznesową.
Konsekwencje:
W porównaniu do punktu 3. członkowie zespołu o wiele lepiej rozumieją swoje wzajemne potrzeby. Backendowiec, który sam robił frontend o wiele lepiej zrozumie jakiego API frontendowcy potrzebują, dzięki temu końcowy produkt będzie bardziej spójny.
Bus factor wyraźnie rośnie. O łatwiej jest zastąpić kolegę z zespołu na czas rekrutowania odpowiedniego specjalisty.
Zbliżenie członków zespołu do biznesowych aspektów projektu powoduje, że lepiej rozumieją potrzeby ostatecznych użytkowników. Natomiast osoby reprezentujące biznes zyskują lepszą komunikację z zespołem.
***
Nawet jeżeli nigdy w projekcie nie dojdziemy do 4-czwartego najwyższego poziomu interdyscyplinarności, warto próbować. Nawet częściowe zbliżenie się do tego punku daje ogromną wartość.
Terminologia i dodatkowe uwagi:
1. Zakładam, że API nie jest końcowym produktem tylko, częścią pracy oraz, że nie mamy do czynienia z wieloma zespołami które co Sprint razem releasują działający soft
2. Ang. Cross functional
3. Polecam świetny artukuł Mike’a Cohna o zagrożeniach płynących z użycia Definition of Ready.
4. Bus factor – to żartobliwy, ale dosadny sposób określający interdyscyplinarność. Opisuje ile osób może maksymalnie waść pod autobus, aby projekt w dalszym ciągu mógł trwać.