Jakie są negatywy Menedżerów Rozwoju jako Scrum Masters?

Powszechnie uważa się, że menedżerowie zespołów nie powinni być mistrzami scrum, ale staram się zrozumieć, dlaczego. Dla kontekstu jestem menedżerem rozwoju aplikacji z 4 programistami w zespole Scrum. Pochodzę ze Scrum Master i wprowadziłem scrum do organizacji. Zbudowałem zespół od zera i jasno powiedziałem, że wszystko, co robię, ma na celu ułatwienie zespołowi i podejmowanie decyzji. Jako zespół jesteśmy bardzo otwarci - nawet na chwilę uciszyli mnie podczas pojedynków, aby wyeliminować poczucie „zgłaszania się”, które zaczęliśmy odczuwać. Brak otwartości jest generalnie największym argumentem przeciwko menedżerowi jako scrum masterowi, ale dobrze sobie z nim radzi, łatwo można go pokonać dzięki właściwej kulturze.

Zostałem ostrzeżony przez doświadczonych trenerów Scrum, że jest to niebezpieczna sytuacja i istnieje ryzyko „jeśli coś pójdzie nie tak”. Moim zdaniem 2 pozycje nie są ze sobą sprzeczne, w obu rolach mam ten sam cel dla zespołu i poszczególnych osób. Scrum rozwiązuje konflikty w zespole, które tradycyjnie mogą pełnić rolę menedżerów. Samozarządzający charakter sprintu zabiera podział pracy tradycyjnie wykonywanej przez kierownika.

Wszystko, co naprawdę widzę jako menedżera deweloperów, to upewnienie się, że indywidualne potrzeby są spełnione, cele kariery, miejsce pracy itp. Mam cotygodniowy kontakt z każdym członkiem zespołu, aby podnosić wszelkie problemy i wykonywać wszelkie zadania administracyjne. Wiele z tego odnosi się bezpośrednio do zespołu lub mojej roli mistrza scrum.

Rozumiem w dużych organizacjach, jak może to być niemożliwe do zarządzania i oddzielna rola, ale dla małej organizacji z pewnością nie moglibyśmy uzasadnić innego Scrum Master lub Development Managera.

Proszę oświecić mnie co do pułapek menedżerów rozwoju jako Scrum Masters, wyłączając punkty, które podniosłem powyżej i które już pokonałem.

Zasadniczo masz konflikt interesów. Zadaniem menedżera jest dotrzymywanie terminów. Zadaniem mistrza scrum jest zapewnienie możliwie najdokładniejszych szacunków i praca w zrównoważonym tempie. Menedżer zwykle chce, aby więcej pracy zostało wciągnięte do sprintu, a mistrz scrum ma tendencję do tego, aby ilość, którą można realistycznie ukończyć, bez względu na terminy zewnętrzne. Chociaż dobry menedżer może zrównoważyć ten konflikt, o wiele łatwiej jest, gdy praca jest podzielona na dwie osoby. Menedżerowie zwykle lepiej pasują do roli właściciela produktu.

Nie ma nic złego w występowaniu w roli mistrza scrum, jeśli nikt w twoim zespole nie jest z nim zaznajomiony, ale twój zespół zobaczy korzyści, jeśli odrzucisz tę rolę po kilku miesiącach. Ważne jest, aby tę rolę postrzegać jako rówieśniczą. Nawet mistrzowie scrum niezwiązani z zarządzaniem często po pewnym czasie muszą się wycofywać, ponieważ zespół zaczyna traktować ich zbyt mocno jak menedżera.

Uważam, że głównym problemem jest to, że jako menedżer masz prawo powiedzieć zespołowi, co ma robić. Mistrz Scrum nie ma tego autorytetu poza egzekwowaniem zasad Scruma.

Co to znaczy? Wkład kierownika w sposób dorozumiany będzie miał większą wagę. Możesz tego nie chcieć lub nie chcieć, ale pod koniec dnia kariera członków zespołu i wypłata zależą w pewnym stopniu od ciebie. I oni to wiedzą. I to zaburza związek.

Nadal możesz to zrobić? Oczywiście. Musisz po prostu bardzo ciężko pracować, aby potwierdzić, że jesteś przywódcą-sługą, a odgórny nie będzie latał.

W rzeczywistości widziałem, co się dzieje, gdy „kierownik techniczny” zbyt mocno angażuje się w codzienną mechanikę projektu, i to nie jest ładne. W naszym przypadku menedżer, o którym mowa, nie był mistrzem scrum, ale próbował dokooptować niektóre z tych decyzji; gdybyśmy nie mieli oddzielnego mistrza scrum, który mógłby grać w obronie, byłoby to znacznie bardziej bolesne.

(Nawiasem mówiąc, to nie był mój menedżer, więc czuję się dość obiektywny w tej kwestii.)

Omówię to, co widziałem jako podstawowe konflikty interesów; jeśli nie uważasz, że któreś z nich dotyczą twojej sytuacji, być może możesz zrobić jedno i drugie. Pamiętaj jednak o regularnym sprawdzaniu tych założeń, aby upewnić się, że nie wpadniesz w żadną z tych pułapek:

1. Kierownicy techniczni są zazwyczaj odpowiedzialni za określoną rolę w wielu zespołach. Jeśli jest to tylko jeden zespół, oznacza to raczej „prowadzenie” niż „menedżera”. To rozłożenie odpowiedzialności oznacza mniej czasu w zespole i mniej czasu w projekcie / produkcie, i zwykle prowadzi do zarządzania stylem „hit and run”.

2. Menedżerowie techniczni mają wiele innych obowiązków kierowniczych wobec firmy. Muszą odbyć coaching / szkolenie, przeglądy wyników, wywiady / zatrudnienie, długoterminową infrastrukturę / planowanie zasobów i więcej. Może to z łatwością stać się pracą w pełnym wymiarze godzin i oznacza bardzo niewiele do wydania na ułatwienia.

3. Napięty harmonogram może również narzucić się zespołowi; menedżerowie techniczni mogą potrzebować (lub chcieć) wciągać członków zespołu na spotkania w czasie, który zespół uzna za nieodpowiedni. Zwykle zadaniem mistrza scrum jest zarządzanie i próba wyeliminowania zakłóceń, ale nie można być obiektywnym, jeśli masz własny harmonogram. Mistrzowie Scruma rzadko muszą spotykać się osobno z członkami zespołu, ponieważ wszystkie te spotkania są już wcześniej zaplanowane (spotkania, retrospekcje itp.)

4. Kierownicy techniczni muszą poradzić sobie z przekrojowymi problemami związanymi z projektem, a ich naturalnym impulsem będzie próba ujednolicenia wszystkiego - bibliotek, kontroli źródła, algorytmów, układów, kolorów, cokolwiek innego. Chociaż może to być naprawdę dobra rzecz dla firmy, ostatecznie nie pozostawia nikogo, kto mógłby się przebić za to, co zespół chce zrobić, i mogą mieć bardzo dobre powody, aby chcieć zrobić coś inaczej. Jest to sprzeczne z ideami „ciągłego doskonalenia” leżącymi u podstaw Scruma i podobnych metod.

5. Menedżerowie wywodzący się ze środowiska eksperckiego w roli, którą zarządzają, będą mieli własne dość mocne pomysły na temat tego, jak należy wykonać pracę i jak długo to powinno potrwać. To nie jest zła rzecz dla menedżera , ale jako mistrz scrum często oznacza zachęcanie członków zespołu do projektów lub szacunków, których inaczej nie zgodziliby się - i prawdopodobnie wiedzą więcej niż ty o danym problemie.

6. Członkowie zespołu zawsze będą mieli problemy z rozróżnieniem między żądaniem a zamówieniem. Nie powiedzą ci tego i mogą nawet nie zdawać sobie z tego sprawy. Nawet jeśli wyjaśnisz, że po prostu pytasz, a nie mówisz, w ich umysłach nadal jesteś ich menedżerem i istnieje ryzyko na poziomie kariery, że powiesz „nie”. Jest to prawdopodobnie najbardziej podstępny ze wszystkich problemów, ponieważ nic nie możesz na to poradzić - liczy się ich nastawienie, a nie twoje .

Jeśli masz pewność , że nigdy nie wpadniesz w żadną z tych pułapek, skorzystaj z niej ... ale powtarzam, upewnij się, że często weryfikujesz swoje założenia, rozmawiając ze swoim zespołem (i innymi zespołami / menedżerami!) i upewnij się, że nie dzieje się to w subtelny lub nieświadomy sposób, którego być może nie zauważysz.

Z pewnością dodam, że fakt, że uważasz ten problem za wystarczająco ważny, aby zadać pytanie, oznacza, że ​​prawdopodobnie dobrze sobie radzisz w obu rolach. W moich książkach dbanie o zespół, a nie tylko własne ambicje zawodowe, prawdopodobnie odpowiada za ponad połowę dobrego zarządzania.

... ale bycie dobrym w obu przypadkach niekoniecznie oznacza, że ​​możesz być dobry w obu jednocześnie . Uważaj na to.

To nie jest religia, a zasady Scruma nie są dogmatyczne. Jeśli kiedykolwiek istniała potrzeba połączenia roli HR Managera / Srum Master, zrobiłeś to dobrze. Uważaj na pułapki, o których wspomniałeś, ale nigdy nie będzie jednego zestawu zasad, które idealnie pasowałyby do każdej sytuacji.

Jeśli twój zespół czuje się swobodnie w wykonywaniu obu ról, nie ma powodu, aby zmieniać wszystko tak, aby pasowało do zasad książki.

Największym problemem, jaki widzę, jest sytuacja, w której zespół ma problem związany z tobą, kierownikiem. Jeśli są młodsi lub brakuje im pewności siebie, mogą bać się zabrać głos podczas retrospekcji. Może to ograniczyć skuteczność retrospekcji. Wiele osób boi się powiedzieć „Czuję, że menedżer jest nierealny”, gdy jest obecny.

Więc może wybaczysz sobie retrospektywę, aby rozwiązać ten problem. Teraz twój zespół robi retrospektywy bez mistrza scrum, potencjalnie również ograniczając skuteczność retrospekcji.

W obu przypadkach masz negatywny wpływ na zespół.

Główny problem, jaki widzę, polega na tym, że wysyłasz do zespołu sprzeczne wiadomości na temat organizacji zespołu.

Poniżej znajdują się dwie możliwe organizacje zespołów. Oba mogą odnieść sukces. Oni są różni. (Nie są to jedyne możliwe opcje).

1. Zespół ma oficjalnie wyznaczonego lidera. Lider zespołu jest ostatecznie odpowiedzialny za ogólną wydajność zespołów. Lider zespołu może nie podejmować wszystkich decyzji, ale lider zespołu ma decydujący głos we wszystkich decyzjach.
2. Zespół jest samoorganizujący i nie ma oficjalnie wyznaczonego lidera. Wszyscy w zespole ponoszą odpowiedzialność za swoje i ogólne wyniki zespołów. Scrum Master ułatwia proces Scrum, ale nie jest upoważniony do podejmowania jednostronnych decyzji dla zespołu.

Wygląda na to, że twoja prawdziwa struktura zespołu to nr 1, ale używając terminologii i kilku procesów Scruma, sugerujesz, że struktura jest nr 2. Moim zdaniem nr 1 to nie Scrum.

Poniżej znajdują się dwie sugestie dotyczące rozwiązania konfliktu.

1. Rób rzeczy takimi, jakimi jesteś, ale wyjaśnij, że jesteś liderem zespołu i nie podążasz za Scrumem w 100%. Prawdopodobnie pomogłoby to wyjaśnić, że chociaż dostrzegasz wartość podziału obowiązków menedżera i mistrza scrum, nie jest to wykonalne dla firmy.
2. Przekaż obowiązki Scrum Master, na ile to możliwe, komuś innemu. Nawet jeśli nadal będziesz musiał zachować pewne obowiązki, takie jak usuwanie przeszkód i odwracanie uwagi od reszty organizacji, nadal pomoże to w wykonywaniu dużej części pracy Scrum Master przez rówieśników.

Jakie są negatywy Menedżerów Rozwoju jako Scrum Masters?

Menedżerowie ds. Rozwoju są zatrudniani do:

• Rozwiąż problemy rozwojowe .
• Monitoruj i redukuj zadłużenie techniczne.
• Zwiększ personel techniczny.

Ich doświadczenie i wiedza predysponują ich do skupienia się na kwestiach technicznych .

Z drugiej strony zatrudnieni są menedżerowie projektów / scrum master;

• Zapewnij sukces projektu.
• Przypisywanie błędów / pytań dotyczących pracy i segregacji do odpowiednich zasobów programistycznych.
• Współpracuj z zespołem programistów, aby usunąć wszystkie przeszkody, które mogą opóźnić zakończenie projektu.
• Przekaż status projektu wyższemu kierownictwu.

• Gdy projekt lub firma osiąga określony rozmiar, nieefektywne i nierozsądne jest zwracanie się do kierownika ds. Rozwoju o wykonanie obu obowiązków.

• Kierownik ds. Rozwoju powinien być skłonny do „głębokich zanurzeń” w kodzie i / lub architekturze, podczas gdy kierownik projektu / mistrz scrum powinien zawsze martwić się widokiem rzeczy o wysokości „50 000 stóp”.

• Większość menedżerów ds. Rozwoju spędza lata na tworzeniu kodu. Kwestie programistyczne są im bardzo dobrze znane.

  • Dlatego są najbardziej przydatne, gdy rozwiązują problemy techniczne.
• Role kierownika projektu / mistrza scrum wymagają ludzi, którzy są bardzo zorganizowani i bardzo zorientowani na szczegóły, ale nie są super-techniczni.
• Jeśli możesz pozwolić sobie na to, aby ci ludzie specjalizowali się w rzeczach, w których są dobrzy, biznes jest najbardziej wydajny.
• A kiedy możesz odciążyć obowiązki związane ze scrumem z płyty menedżera rozwoju, może on / ona spędzać więcej czasu na kwestiach technicznych i zmniejszaniu zadłużenia technicznego.

Słuchałbym doświadczonych trenerów Scrum. Możliwe, że dobrze sobie poradzisz przez 99% czasu. Jednak gdy pojawia się ten przerażający 1% i konflikt ról, masz szansę zepsuć nie tylko relację jednostki z tobą, ale także dobre samopoczucie całego zespołu. A po jednym zepsuciu twoja rola zarówno mistrza scrum, jak i managera zostałaby podważona.

Gdybym był tobą, zidentyfikowałbym osobę w zespole, która ma potencjał, aby zostać mistrzem scrum i iść z nim / nią. Zawsze postrzegałem mistrza scrum jako kogoś, komu zespół ufa i który rozumie proces, biznes i przerażające sprawy techniczne. Jeśli wybrałeś zdolną osobę, rola mistrza scrum nie jest (a nawet nie jest bliska bycia) pełnoetatową pracą.