Teamwork, czyli Scrum tysiące lat temu 

Mówi się że wszystko co nowe, to zapomniane stare. Jeżeli uznamy to powiedzenie za prawdę, to musi ono dotyczyć również i Scruma, którego oficjalna historia liczy 20 lat. Czy może być tak, że ten framework istniał dużo wcześniej? I, co ważniejsze, jak odpowiedź na to pytanie pomoże nam budować lepsze zespoły dzisiaj?

Nie zdziwię się, jeżeli uznacie za szaleństwo samą myśl o tym, że Scrum mógł istnieć tysiące lat temu. Bo jak mogły wtedy powstać zwinne metodyki tworzenia oprogramowania, jeśli samego oprogramowania jeszcze nie było? Pomijamy oczywiście wersję, w której zaginione cywilizacje antyczne zanim na zawsze zniknęły, zdążyły osiągnąć nieznane nam poziomy zaawansowania.

Czy programiści w Atlantydzie mieli Agile’a czy musieli też męczyć się w Waterfallu? Na to pytanie, niestety, już nie dostaniemy odpowiedzi. Możemy za to dowiedzieć się, że pewna wiedza, posiadana przez ludzkość od tysięcy lat, może pomóc nam w tworzeniu oprogramowania o wysokiej jakości.

Chyba dla nikogo nie jest tajemnicą, że nazwa tego frameworka – Scrum – wywodzi się z rugby i oznacza zorganizowaną formacje drużyny zawodników. To właśnie naprowadza nas na jeden z najważniejszych (i mało omawianych!) aspektów tej metodyki – pracę drużynową (teamwork).

Wartość pracy zespołowej i zespołów jako takich była znana ludziom przez tysięcy lat. Spójrzmy na kilku przykładów:

• Falanga z antycznej Grecji – formacja wojskowa dla żołnierzy uzbrojonych w długie włócznie, w której każdy rząd jest chroniony przez włócznie poprzedniego
• Kolejny przykład militarny – formacja „żółw” z antycznego Rzymu, polegająca na tym, że żołnierze zamykają siebie tarczami z każdej strony, aby bezpiecznie poruszać się pod obstrzałem
• Z innej branży – typowy zespół muzyczny składający się z wokalisty, gitarzysty, basisty, perkusisty i ewentualnie innych muzyków, gdzie wszyscy grają jednocześnie, ale tworzą jeden utwór
• Scrum w rugby

Można przytoczyć mnóstwo innych przykładów ze sportu, sztuki, nauki wojskowej, inżynierii i wielu innych branż, z dowolnej epoki historycznej, również tych najbardziej dawnych. Wszędzie widzimy te same cechy Teamworku:

• Ludzie łączą swe siły by dokonać czegoś, czego nie da się zrobić w pojedynkę
• Łączenie się w zespół odbywa się nie w dowolny sposób, tylko skoordynowany
• Brak odpowiedniej koordynacji, lub odstąpienie od niej zagraża osiągnięciu postawionego przed nami celu (np. jeśli jeden z żołnierzy postanowi pójść w innym kierunku, w formacji robi się luka; podobnie jeśli jeden z muzyków zacznie grać co innego, harmonia całej piosenki się zepsuje)

Jak wygląda teamwork w Scrumie, i, co ważniejsze, jak praca zespołowa pomaga tworzyć oprogramowanie o wysokiej jakości?

W swojej karierze bardzo często widziałem zespoły, które funkcjonowały po prostu jako grupa ludzi. Niby są zatrudnione do pracy nad tą samą aplikacją, a w rzeczywistości każdy działa osobno bez żadnej współpracy. Takie grupy błędnie nazywa się zespołami, bo nie działają one jako zespół (patrz: Zespół specjalistów to nie Zespół na #białkowym kanale na YouTube).

Nie ma teamu bez teamworku.

Praca drużynowa w Scrumie oczywiście różni się od formacji wojskowych i innych przytoczonych przykładów. Niemniej pewne rzeczy pozostają takie same, jak jak chociażby wspólny cel czy poleganie na sobie wzajemnie. (Współ)praca scrumowa bardziej polega na następnych aspektach:

1. Akumulacja Talentów. Każdy człowiek ma swoje mocne i słabe strony. Ktoś jest bardzo pomysłowy, ale nie przywiązuje wagi do szczegółów. Ktoś inny na odwrót – bardzo skrupulatny, lecz zbyt sztywny. Inna osoba ma np. talent do ulepszania już istniejącego kodu, a kolejna świetnie tworzy ramy, ale nie potrafi optymalizować istniejących rozwiązań. Drużyna jest zbiorem mocnych stron wszystkich członków, dlatego pozwala dokonać tego, co każdy z nich nie osiągnął by z osobna.
2. Rozwijanie Pomysłów. „Co dwie głowy, to nie jedna”. Zdarza się, że Developer wpada na pomysł. Dobry, ale niedoskonały. Przedstawia go zespołowi i przez dyskusję udaje się ten pomysł doszlifować.
3. Kross-Funkcjonalność. Praca bez teamworku doprowadza do nadmiernej specjalizacji. Jeden Developer pracuje tylko z komponentem A, drugi z komponentem B i tak dalej. Kiedy ktoś z nich zachoruje lub pójdzie na urlop rozwój tego komponentu zostaje zagrożony, bo inni, nie znając go, spędzą trzy razy więcej czasu gdy trzeba będzie coś w nim zmienić.
4. Wspólny Standard. Każdy Developer ma swoje nawyki i preferencje co do pisania kodu. Jeżeli będą pracować samodzielnie bez Teamworku, kod aplikacji będzie wyglądać jak nowela, gdzie każdy rozdział jest napisany przez innego autora. Komponenty będą różnić się od siebie jak zima od lata i będziemy napotykać na sytuacje, gdzie nowa osoba, dołączając się do zespołu, powie: „Tę klasę mogę edytować, a ta druga wygląda tak strasznie, że boje się jej dotykać!”. Developerzy w zespole Scrumowym ustalają jeden format, który będzie odpowiadać wszystkim, aby każda część kodu była tak samo czysta i zrozumiała, jak każda inna.
5. Zbiór Wiedzy. Waterfall każe nam tworzyć szczegółową dokumentację o produkcie. Problem jest taki, że kod ciągle się zmienia, a więc dokumentacja do niego robi się nieaktualna prawie codziennie, a więc utrzymywanie jej jest bardziej żmudne, niż utrzymywanie samego kodu. Im dłużej Developerzy pracują nad pewną aplikacją, tym lepiej ją znają. Ta wiedza jest niezbędna do podtrzymywania, rozwijania oraz naprawiania aplikacji. Czasami też tę wiedzę trzeba komuś przekazać – wprowadzić nową osobę bądź oddać projekt innemu zespołowi. Ludzie, którzy znają aplikację zawsze poradzą sobie z tym lepiej, niż jakakolwiek dokumentacja. Co nie znaczy, że dokumentacja nigdy nie ma wartości, ale to temat na inny post.
6. Rozwijanie Talentów. Tworzenie oprogramowania jest trudnym rzemiosłem, wymagającym ciągłego rozwoju zawodowego. Praca w drużynie jednocześnie ułatwia i ulepsza ten proces, bo członkowie zespołu uczą się od siebie nawzajem, dzielą się wiedzą, pomagają przeskoczyć zbędne kroki w nauce.

Teraz powinno być oczywiste, jak Teamwork, czyli praca zespołowa pomaga tworzyć oprogramowanie o lepszej jakości. A to właśnie jest celem adopcji Scruma. Od Scrum Guide’a 2020 możemy nawet pójść szerzej i powiedzieć – celem Scruma jest wytwarzanie wartości poprzez adaptacyjne rozwiązywanie złożonych problemów, niekoniecznie tworząc oprogramowanie. Nie ma to znaczenia – praca zespołowa jest potrzebna wszędzie tam, gdzie problemy są złożone.

I teraz zapewne niejeden czytelnik pomyśli: „No dobra, w teorii to brzmi super, ale jak to wprowadzić w praktyce?” Gdyby można było odpowiedzieć na to pytanie jednym postem, to musiałbym zmienić zawód. Bardziej odpowiednio by było napisać na ten temat książkę, bo jest to proces złożony i trwały. Scrum sam w sobie jest trudny, stąd też istnieją Scrum Masterzy oraz Agile Coache – specjaliści od rozkładania go na czynniki pierwsze. Oni pomogą stworzyć właściwe środowisko, ułożyć efektywne zespoły i rozwiązać problemy, które czekają zarówno na starcie, jak i w trakcie budowania zespołowości.

Pamiętajmy tylko, że teamwork wymaga właściwych warunków wstępnych. Jeśli nasza organizacja premiuje podejście indywidualne pod tytułem „ja swoje zrobiłem”, jeżeli nie pozwala na budowę zespołów z wspólnym celem, tylko takich „z jednym kierownikiem”, a do tego patrzy na ludzi tylko i wyłącznie indywidualnie, to będzie bardzo ciężko.