W zespole Scrum nie ma stanowiska Lidera, dodam więcej – nie ma żadnego stanowiska, na czas pracy w zespole Scrum każda osoba wykonująca „Przyrost” jest członkiem zespołu Deweloperskiego. Dzięki temu możliwa jest lepsza komunikacja która jest podstawą spójnego zespołu. 

W każdej grupie osób, które razem spędzają czas, jest lider. Nie znam takiej sytuacji, aby w jakimkolwiek zespole nie było osoby pełniącej takiej roli. Nawet gdy nie ma takiego stanowiska, pozycji w firmie – taka osoba istnieje, ludzie potrzebują liderów i wybierają samodzielnie Szef nie zawsze jest liderem. W Scrum jednym z najistotniejszych czynników pozwalających na osiąganie wymiernych korzyści jest samo organizujący się zespół. Oznacza to, że decyzje muszą być podejmowane wspólnie i jest jedna odpowiedzialność za zadania – grupowa. Dlatego w Zespole Deweloperskim nie ma osoby pełniącej rolę podejmującej decyzje w przypadku braku zgody wszystkich jej członków. 

Jeden wynik

W Scrumie praca zespołowa jest najważniejsza, dlatego należy do tego podchodzić tak jak do meczu. Jedna jest tablica wyników, na której nie ma prezentowanych wartości który zawodnik jak grał. Często się zdarza, że dominujący/najlepszy zawodnik wprowadza zamęt do gry – i pomimo najlepszych umiejętności – trener czasem „siada” takiego zawodnika na ławece rezerwowych (np. w meczach koszykówki, siatkówki).

Taką tablicą wyników w Scrum jest BurnDown-chart – narzędzie które prezentuje postęp prac na podstawie Sprint Backlog. W zaangażowanym i zgranym zespole dla członków nie ma znaczenia stanowisko, lecz wspólny końcowy efekt. W przypadku takiej interpretacji wyników dla użytkowników końcowych nie ma znaczenia wydajność poszczególnych osób lecz Przyrost jaki został zbudowany. Scrum skupia się na jak najlepszym procesie aby to osiągnąć i dlatego nie uwzględnia „osób decyzyjnych” w obrębie zespołu deweloperskiego.

Samoorganizacja

Kiedy mówimy o samoorganizacji zepołu mamy na myśli:

1. Brak nazw stanowiska w zespole – każdy jest człokiem Zespołu Deweloperskiego
2. Odpowiedzialność za zadania należy do zespołu a nie pojedynczych członków
3. Konflikty są rozwiązywane w dziale bez pomocy z zewnątrz (tutaj czasem jest potrzebna pomoc Scrum Mastera)
4. Nie ma „pod zespołów” 
5. Zespół jest multifunkcyjny – czyli posiada wszystkie kompetencje niezbędne do ukończenia zadań, do osiągnięca Przyrostu

Dzięki temu organizacja posiada bardzo dużą zdolność do realizowania projektów. Przyrost nie jest zależy od jednej czy dwóch osób, ale od całego zespołu, wiedza również musi być dzielona pomiędzy pracownikami. W takiej sytuacji nie może występować lider podejmujący decyzje. W przypadku odpowiedzialności zespołu jako całości musi występować wspólne podejmowanie decyzji. 

Takie podejście pozwala na szybsze podejmowanie decyzje i radzenie sobie w trudnych sytuacjach. W przypadku gdy nie ma całego zespołu (urlopy, choroby) produkt nadal jest rozwijany, a członkowie dokładnie wiedzą jak się dogadywać i rozwiązywać problemy. Spójny zespół jest ogromną korzyścią dla organizacji, nie wymaga nakładów na zarządzanie, motywowanie, itp.

Decyzyjność

Jest to jedna z najtrudniejszych czynności w trakcie wprowadzania Scrum do organizacji. W przeszłości bardzo często decyzje były podejmowane przez Project Managera, Senior Developera, Architekta Oprogramowania – w Scrum nie ma takich stanowisk, a decyzje muszą być podejmowane w porozumieniu z każdą osobą w zespole. Nie ma znaczenia czy jest to osoba testująca czy grafik – wszyscy muszą znać złożoność zadań i konsekwencje wprowadzania rozwiązań technologicznych.

Wydarzenia Scrum i opis pod kątem decyzyjności

1. Planning 
   • wspólne podejmowanie odpowiedzialności za realizację zadań
   • opracowanie planu realizacji
2. Daily
   • codzienne spotkania na których zespół wspiera siebie w realizacji zadań
   • tutaj są podejmowane decyzje technologiczne, omawiane są różne sposoby rozwiązywania problemów
     
3. Sprint Review 
   • współpraca z Product Owner w zakresie doszczegółowiania zadań, estymacja wartości pracy, przed rozpoczęciem pracy
     
   • wspólnie interesariuszami podejmowanie decyzji odnośnie dalszego rozwoju oprogramowania
4. Retrospective
   • spotkanie na którym omawiane są problemy w procesie m.in. komunikacji i wspólnie są podejmowane decyzje jak je poprawić 
     
   • wspólnie są określane metody rozwiązania najpilniejszych problemów

*Tutaj chciałbym dodać, że nie opisuję Wydarzeń Scruma w całości, lecz opisuje je pod kątem podejmowania decyzji.

Podsumowanie

Brak osoby decyzyjnej w zespole deweloperskim jest celowy i w dłuższej perspektywie bardzo korzystny. Lecz wiąże się z odejściem od aktualnego popularnego sposobu zarządzania „ignoruj i karaj” – nie można tutaj oceniać wydajności osób oddzielnie – lecz jedynie jako zespół. To powoduje kolejne problemy. Wiadomo, że każda osoba pracuje inaczej i osiąga inne rezultaty – tutaj musi wkroczyć nowoczesne zarządzanie aby osoby wyróżniające się nie czuły się ignorowane. Pamiętaj: 

Nie ma większej nierówności jak równe traktowanie nierównych!

Jednominutowy Menedżer i Przywództwo, dr Ken Blanchard