Agile Scrum Polish

Od Project Managera do Scrum Mastera: jak nie pomylić ról i nie wejść w mikrozarządzanie

Przejście z roli Project Managera do Scrum Mastera to nie awans ani zmiana nazwy stanowiska. To całkowita zmiana sposobu pracy, odpowiedzialności i wpływu na zespół. Sprawdź, na co uważać, żeby nie wrócić do mikrozarządzania.

AK

Arkadiusz Kozieł

Przejście z roli Project Managera do Scrum Mastera wygląda na naturalny krok, ale w praktyce to jedna z trudniejszych zmian zawodowych. Na papierze oba stanowiska dotyczą pracy z zespołem, planowaniem i dowożeniem efektów. W rzeczywistości stoją na zupełnie innych fundamentach. Project Manager zwykle odpowiada za zakres, termin, budżet i kontrolę postępu. Scrum Master nie zarządza ludźmi ani zadaniami — jego rolą jest tworzenie warunków, w których zespół sam potrafi pracować skutecznie.

Największy błąd po takiej zmianie to próba przeniesienia starych nawyków do nowej roli. Jeśli wcześniej pilnowałeś harmonogramu, rozliczałeś zadań i dopytywałeś, kto jest winny opóźnieniu, łatwo wejść w rolę „nadzorcy procesu”. A Scrum Master nie jest kontrolerem ani sekretarzem zespołu. Nie ma sprawdzać, czy wszyscy odhaczyli taski. Ma usuwać przeszkody, dbać o przejrzystość pracy, wspierać współpracę i pomagać organizacji zrozumieć, jak działa Scrum.

To oznacza też zmianę sposobu myślenia o odpowiedzialności. Jako Project Manager często bierzesz na siebie większą część ryzyka i próbujesz dopiąć projekt własną determinacją. Jako Scrum Master musisz oprzeć się pokusie „ratowania” zespołu za każdym razem, gdy pojawia się problem. Jeśli zaczynasz sam rozdzielać zadania, ustalać priorytety albo przypominać ludziom o terminach bardziej niż oni sami sobie, to nie wspierasz zespołu — odbierasz mu sprawczość.

W praktyce Scrum Master powinien patrzeć szerzej niż tylko na team. Duża część jego pracy dzieje się poza spotkaniami zespołu: w rozmowach z interesariuszami, z Product Ownerem, z innymi zespołami i z organizacją. Trzeba uczyć otoczenie, że Scrum to nie „meetingi dla meetingów”, tylko system pracy oparty na empiryzmie, odpowiedzialności zespołu i ciągłym usprawnianiu. To wymaga cierpliwości, konsekwencji i umiejętności zadawania trudnych pytań zamiast wydawania poleceń.

Dla osoby z doświadczeniem technicznym i delivery ta zmiana bywa szczególnie trudna, bo łatwo wejść w doradzanie „jak to zrobić lepiej” albo wchodzenie z butami w rozwiązania techniczne. Scrum Master nie musi znać każdej technologii, ale powinien rozumieć kontekst pracy zespołu na tyle dobrze, by widzieć zależności, ryzyka i blokery. Kluczowe jest jednak to, żeby nie przejmować odpowiedzialności za decyzje, które należą do zespołu.

Jeśli przechodzisz z PM do SM, zwracaj uwagę na trzy rzeczy. Po pierwsze: nie zarządzaj ludźmi przez zadania. Po drugie: nie licz sukcesu przez to, ile rzeczy sam „załatwiłeś”. Po trzecie: nie oceniaj swojej skuteczności wyłącznie po tym, czy wszystko idzie zgodnie z planem. Scrum Master jest skuteczny wtedy, gdy zespół staje się bardziej samodzielny, a organizacja mniej przeszkadza w dostarczaniu wartości.

Ta zmiana roli może być bardzo dobra dla osoby, która lubi pracę z ludźmi, procesem i usprawnianiem współpracy. Ale wymaga pokory, bo trzeba odpuścić część kontroli, do której przyzwyczaił Project Manager. Jeśli tego nie zrobisz, skończysz z tytułem Scrum Mastera, ale z zachowaniem starego stylu zarządzania. A to najkrótsza droga do frustracji zespołu i własnego wypalenia.

Found this useful?

Let's continue the conversation.