Skoro wszystkie role są w Scrumie na tym samym poziomie, a zespoły same organizują sposób wykonania pracy, to czy w ogóle znajdziemy jakieś miejsce dla kierownika? Czym ma się zajmować nasz bezpośredni przełożony?
Co robi management w Scrum?
Jakiś czas temu Łukasz śpiewał o middle managemencie. W trakcie tamtej dyskusji wyszło nam, że to właśnie kierownicy liniowi i middle management najbardziej boją się o swoją skórę przy okazji transformacji agile. Z jednej strony są pomijani przez wiele metodyk, a z drugiej czują, że w dobie samoorganizacji mają coraz mniej do powiedzenia.
Nie jest jednak aż tak źle. W większości przypadków ich sytuacja wygląda tak samo, jak naszego przyjaciela Project Managera. To nie jest tak, że staje się on niepotrzebny. Po prostu z roli, która zarządzała wszystkim i niczym staje się on specjalistą z węższym, ale konkretnym zestawem odpowiedzialności.
Jest jedno piękne pytanie egzaminacyjne na jeden ze scrumowych certyfikatów. Mowa w nim o roli managementu w Scrumie. Jak odrzucimy wszystkie odpowiedzi mówiące o „kontroli”, „przydziale zadań” i „upewnianiu się, że zespół zwiększa swoją efektywność” to zostanie nam ta nieśmiało sugerująca, że management ma pomagać zespołowi, wspierać go i zapewniać odpowiednie środowisko.
Czyli świat staje na głowie, nagle to kierownik jest dla pracownika, a nie odwrotnie.
Kierownik liniowy to przeżytek
Nikt nie mówi naszym zwinnym zespołom jak mają pracować, ani nie przydziela im zadań. A to ostatnie to właśnie lwia część zakresu obowiązków klasycznego kierownika liniowego. Jeżeli mamy do czynienia z kompetentnym i zmotywowanym zespołem, to nie ma potrzeby ich niańczyć. Wystarczy powiedzieć, o co chodzi i upewnić się, że wytwarzany produkt mieści się w ramach określonych naszym kontraktem.
Tylko do tego trzeba przyznać samemu przed sobą, że zatrudniliśmy najlepszych dostępnych ludzi, zapewniliśmy im odpowiednie środowisko oraz obdarzyliśmy zaufaniem. Bez tego, jak już mówiliśmy wielokrotnie, marzenia o samoorganizacji to mrzonka.
Idea „kierownika liniowego”, jako osoby, która przekazuje wizje zarządu do osób wykonujący pracę (czytaj: Development Team) też nie ma za bardzo miejsca w naszym zwinnym światku. Po pierwsze, zwykle nie realizujemy wizji zarządu, tylko staramy się pomóc naszym klientom lub użytkownikom.
Po drugie zaś, reprezentantem wspomnianych interesariuszy jest dla nas Product Owner, który z kolei zaś należy do naszego Zespołu Scrumowego. Skracamy więc nasz horyzont managerski do zera i skupiamy się na pracy. Bo tym właśnie jest Scrum – sposobem na efektywne tworzenie produktów dopasowanych do odbiorców.
I znów, to wcale nie znaczy, że nie liczy się zysk, koszty i w ogóle cała ta otoczka prowadzenia projektu. Ale chcemy od niej odciągnąć osoby dla nas najważniejsze – twórców produktu. Z punktu widzenia prowadzenia firmy oczywiście nadal będziemy mieli różne szczeble managerskie. Jednak na pewno nie znajdziemy tu klasycznie rozumianego kierownika liniowego.
Po to mamy Product Ownera (i czasami nawet Project Managera), żeby robić, to co trzeba i jeszcze na tym zarobić. O wiele łatwiej będzie to osiągnąć, jeżeli ludzie pracujący nad produktem będą skupieni na nim, a nie na milionie innych rzeczy.
„Role managerskie”
W większości firm, każda zatrudniona osoba ma swojego przełożonego, czasami nawet więcej niż jednego. Te osoby „dbają o nasz rozwój” (co zwykle jest pustym hasłem), wystawiają nam oceny roczne i podpisują wnioski urlopowe. Nie oszukujmy się, kierownik liniowy w IT jest trochę reliktem przeszłości.
Jeżeli już ktoś z nas myśli o „przydatnym kierowniku”, to ma raczej na myśli kogoś w rodzaju Team Leadera lub eksperta w swojej dziedzinie. Potrzebujemy kogoś służącego merytoryczną radą i pomocą. Klasyczny manager zwykle nie może tego zrobić, bo po prostu nie ma takich kompetencji. Tak to już jakoś jest, że eksperci zostają team leaderami, architektami, itp., a nie managerami (patrz: Peter Principle).
Wspominając przez chwilę nieistniejący „model Spotify„, warto sobie przypomnieć, że nawet tam wykształciło się wiele pozycji „kierowniczych”. Od Tribe Leaderów, przez Chapter Leaderów po szefów Gildii – to wszystko są „kierownicy”. Ale ich funkcje są w mniejszym stopniu managerskie, a w większym – eksperckie.
I wszystko wskazuje na to, że w tę stronę zmierza nasz informatyczny światek. Kierownicy pozostaną odpowiedzialni za sprawy organizacyjne i te ze związane z zapewnieniem środowiska, warunków do pracy, budżetów, szkoleń, itd. Z kolei mentoring, dbanie o rozwój i zapewnianie spójnego sposobu wykonywania zadań spadnie na barki ekspertów, czasami opatrzonych etykietką team leadera.
Tylko czy przypadkiem to już właśnie tak nie wygląda? Czy przełożony kilkunastu bądź kilkudziesięciu „profesjonalistów w Zespole Deweloperskim” kiedykolwiek był w stanie skutecznie i efektywnie rozdzielać zadania? Na pewno mam wątpliwości co do tego, czy taki kierownik lepiej jest w stanie ułożyć pracę niż zespół ją wykonujący (patrz: Skin in the game).
