Jak odzyskać kontrolę menedżerską nad moim "samoorganizującym się" zespołem?

Dajesz scrummasterowi dziwne spojrzenie, i mówisz “bye Felicia”, a następnego dnia zwołujesz spotkanie całego zespołu i pytasz, co to za bzdury.

Jeśli to rzeczywiście się stało, to ja bym zwolnił idiotę scrummastera w ciągu minuty w Nowym Jorku. Ten Scrummaster jest niebezpieczny, nieprofesjonalny i dziko niezdolny do swojej pracy. Sposobem na “zwolnienie twojego menadżera” jest rezygnacja: w zasadzie tylko złożył rezygnację dla całego zespołu.

Nie rozumiem, dlaczego się martwisz. Oni wszyscy są pod tobą w hierarchii i nie mają władzy, żeby cię zwolnić.

Co ważniejsze, musisz się dowiedzieć, co się do cholery dzieje. W zależności od sytuacji może zaistnieć potrzeba zakończenia pracy samego mistrza scrumu.

Zrób to zanim będzie za późno, zanim twój szef (lub CIO) powie to samo tobie.

Chociaż pracowałem z wieloma zespołami, które podążały tą samą drogą, nie brzmi to tak, jakby było to traktowane z należytą starannością. Chciałbym podzielić się z wami tym, co widziałem, aby sprawdzić, czy to pomoże wam znaleźć drogę naprzód.

Po pierwsze, Scrum zachęca zespoły do samoorganizowania się. Przewodnik Scrum mówi konkretnie o samoorganizowaniu się zespołów:

Są one samoorganizujące się. Nikt (nawet Scrum Master) nie mówi zespołowi programistów, jak przekształcić Product Backlog w przyrosty potencjalnie dostępnych funkcjonalności;

To, wraz z wieloma innymi kwestiami związanymi z byciem wielofunkcyjnym i szeroką odpowiedzialnością, ma na celu zachęcenie członków zespołu do zadawania sobie trudnych pytań o to, jak dobrze są przygotowani do realizacji zadań, które są przed nimi stawiane. Zdecydowanie warto poświęcić czas na przeczytanie Scrum Guide - jest krótki.

Jeśli chodzi o menedżera, jeśli zauważyłeś, że twoja praca w przeszłości polegała na przydzielaniu zadań i śledzeniu elementów pracy, Scrum prosi cię o krok wstecz. Szczerze mówiąc, jeśli Scrum Master nie rozmawiał z tobą o tym na długo przed pierwszą retrospektywą, mogło mu to trochę umknąć. Surowa rzeczywistość jest jednak taka, że wiele zespołów, które są przyzwyczajone do menedżera organizującego dla nich swoje zadania, nie jest dobrze przygotowanych, aby po prostu wskoczyć do tego podejścia. Jeśli czujesz, że twoja drużyna jest w takiej sytuacji, polecam porozmawiać o tym z Scrum Master. Istnieje wiele technik ułatwiających to przejście. W szczególności, przyjrzałbym się Drabinie Przywództwa Davida Marqueta i może nawet jego książce Obróć statek dookoła. Przekonasz się, że w obu przypadkach, żaden menedżer nie zostaje zwolniony.

Na koniec, spójrzmy, dlaczego chciałbyś dokonać tej zmiany, jeśli w przeszłości odnosiłeś sukcesy w zarządzaniu ludźmi. Krótka wersja jest taka, że będziesz miał jeszcze więcej sukcesów pomagając im w nauce zarządzania sobą. Jest na ten temat tak wiele badań i danych, że trudno nawet wiedzieć, od czego zacząć - ale powiem, że jest to dość dobrze udokumentowany fakt, że wszyscy ludzie są potencjalnie zdolni do samoorganizacji i w zespole dziesięciu, jedenastu mózgów (w tym Twój) zawsze będą rozwiązywać problemy skuteczniej niż jeden, a kolejne dziesięć będzie czekać na Ciebie, aby zrzucić winę za błędne rozwiązanie.

Widziałem wiele udanych menedżerów w środowiskach Scrum. Zawsze ostrzegałbym zespół przed bezpośrednim “zwolnieniem” jednego z nich. Nawet jeśli jesteś zastraszający, jak mówi twoje pytanie, i zarządzasz każdym zadaniem przed nimi, pracowałem z wieloma takimi menedżerami, którzy nadal są niesamowitymi atutami zespołu. W tych samoorganizujących się zespołach nie poświęcasz całego swojego czasu na kierowanie działaniami zespołu, aby mieć pewność, że droga do ich sukcesu jest jasna i zawsze lepiej wychodzi na jaw, gdy zespoły dostarczają więcej, a menedżerowie mają reputację gwiazd rocka.

Powodzenia, mam nadzieję, że to daje ci kilka kątów do pracy.

• W kontekście scrum: Co mówi właściciel produktu? To nie jest funkcja szefa scrumu, aby prosić o więcej (lub mniej) zasobów. Jest to coś, co właściciel produktu musi uzgodnić z interesariuszami

• W kontekście scrumu: Retrospektywa dotyczy procesu, zespołu i projektu (a nie “jak się czuję z moim szefem”). Jeśli byłeś częścią zespołu, powinieneś był zostać zaproszony. Jeśli nie byłeś częścią zespołu, retrospektywa powinna była dotyczyć tylko Twojej roli w projekcie.

• mistrzowie scrumu mówiący menedżerom liniowym, co mają robić, są co najmniej tak samo absurdalni jak menadżer liniowy angażujący się bezpośrednio w scrum

Tak więc mistrz scrumu wyraźnie przekroczył swoje granice. Jego zadaniem było skupienie retrospektywy na identyfikacji konkretnych problemów, które należy rozwiązać.

Jak postępować:

• Rozmawiasz z zespołem podczas indywidualnych sesji i pytasz go, co się dzieje. Wyjaśniasz jasno, że scrum master jest nie funkcją liniową i że robi nie montaż zespołów. Zapytaj też, gdzie według nich powinieneś był pozostać poza codziennym biznesem

• powiedz wyraźnie zespołowi, do kogo należy kierować problemy

• przechodzisz do następnej w kolejce (jeśli to jest CIO, to jest CIO - nie do przyjęcia jest to, że nie masz menedżera od miesięcy), stwierdzając, że sytuacja musi być rozwiązana natychmiast (poprzez zwolnienie mistrza scrumu lub CIO mającego ze sobą słowo, że zostanie zwolniony na obecnym kursie), w przeciwnym razie zagraża to projektowi - dla mnie brzmi to tak, jakby mistrz scrumu nie rozumiał swoich obowiązków i ograniczeń. Profesjonalną odpowiedzią dla zespołu próbującego “zwolnić” swojego menadżera w ramach retrospektywy byłoby “To nie moja sprawa, żeby załatwiać sprawy między tobą a twoim szefem, a na pewno nie to, za co projekt nam płaci”.

I’ve stressed to the team the benefits of self-organing teams and team empowerment.

Well, they certainly took that part to heart.

It seems clear that you’re in very emotional situation right now. Najwyraźniej twój zespół ma kilka poważnych problemów z obecnymi relacjami między tobą a nimi. Prawdopodobnie dobrze, że nie byłeś na retrospektywie, ponieważ to jest zazwyczaj powód, dla którego ludzie są nagle skłonni mówić o tym, co ich naprawdę niepokoi. Jeśli są gotowi zrobić to wokół Scrum Master, z którym pracują dopiero od kilku tygodni, to albo już mu ufają, albo są tak wkurzeni, że nie przejmują się konsekwencjami.

Tak czy inaczej, to nie jest nowy problem, który pojawił się nagle, kiedy przeszedłeś do Scrum lub zatrudniłeś nową osobę. Jest to problem, który od dawna nie był widziany. Często mówi się, że praca Agile nie tyle stwarza nowe problemy, co sprawia, że te już istniejące są niezwykle oczywiste. To jest prawdopodobnie przypadek tego.

To powiedziane; twój Scrum Master upuścił piłkę, mocno. To jego praca, aby pomóc zespołowi rozwijać się w kierunku samoorganizowania się, pewnie. Ale to nie jest dobry sposób. Na jeden, nie może aktualnie zwolnić cię, i po prostu mówienie ci “to jest to, co zespół chce” jest całkowicie niekonstruktywne. Nie jestem pewien, co on myśli, że będzie wynikiem tego, ale to nie może być to, co zespół myśli, że jest to.

Również, usuwanie ludzi jest najtrudniejszym wyborem, który zespół lub Scrum-Master ) może i powinien nigdy być traktowany lekko i bez rozmawiania (wielokrotnie) z osobami zaangażowanymi. Nie możesz po prostu wyjść i usunąć kogoś, kto nie ma pojęcia, że ktoś ma z nimi problem. Jeśli nie ma nic innego, wszyscy będą się bali jak cholera, że jeśli przegapią retrospektywę, mogą nagle wrócić do pracy i stwierdzić, że zostali usunięci z zespołu. To stworzy atmosferę strachu, a nie zaufania. Atmosfera zaufania i otwartości jest tym, czego chcesz podczas pracy w Agile.

Więc skoro twój Scrum Master nie pracuje w otwartej atmosferze (przynajmniej poza zespołem; wydaje się, że zmusił ludzi do otwarcia się całkiem wewnętrznie) i nie szuka konstruktywnego rozwiązania, wydaje się, że to na ciebie spadnie obowiązek.

W tym momencie, nie wydaje mi się, aby cokolwiek opartego na autorytecie było pomocne. W Scrum i Agile chodzi o umożliwienie ludziom robienia własnych rzeczy, a potwierdzenie swojego autorytetu w tym momencie prawdopodobnie zakończy się zwolnieniem całego zespołu. Zespół stwierdził już, że jest w punkcie, w którym chcą, aby ludzie odeszli, więc choć mogliby się pomylić, to pójście z nimi w cztery oczy prawdopodobnie skończy się na tym, że przynajmniej kilka osób odejdzie. (I pamiętaj o najważniejszej zasadzie dotyczącej odejścia: najcenniejsi ludzie będą pierwszymi, którzy odejdą)

Więc jeśli naprawdę chcesz zrobić Scrum z tym zespołem, musisz zaakceptować ich zdolność do decydowania o tym, jak chcą pracować i przeprowadzić otwartą dyskusję na temat tego, jak chcą zorganizować swój zespół. Nie mogą cię zwolnić, ale dali jasno do zrozumienia, że to, co robisz teraz, nie jest pracą dla nich. Musisz porozmawiać o tym, jaka będzie twoja rola w przyszłości, czego oni potrzebują od ciebie, czego ty od ciebie potrzebujesz i jak to wszystko zostanie zorganizowane. Pamiętaj, że oni decydują o tym, jak będą pracować, ale ostatecznie jest jeszcze produkt, który musi być dostarczony; oni _będą oceniani na podstawie jakości tego, co dostarczają. I jeśli są rzeczy organizacyjne, które potrzebujesz od nich, będą musieli zrobić te rzeczy, jak również. (To powiedziawszy, pracuj z nimi nad formą tych rzeczy i upewnij się, że są one naprawdę potrzebne przed ich egzekwowaniem).

Upewnij się, że na tym spotkaniu nie podchodzisz do rzeczy od swojego autorytetu; cała idea polega na tym, aby wszyscy byli na tym samym poziomie. Wszyscy jesteście kolegami i osobami, które mają pracę do wykonania, wszyscy chcecie wykonywać dobrą pracę i wszyscy musicie współpracować na co dzień. Bycie autorytarnym zazwyczaj po prostu sprawia, że ludzie są wobec siebie antagonistami, co nie jest produktywne. Postarajcie się więc być tutaj bezbronni i bądźcie gotowi przyznać się do tego, co zrobiliście źle. Musisz się dowiedzieć, jak się stąd wydostać jako człowiek.

Brzmi to tak, jakby twój zespół uderzył w Storming Phase ich rozwoju jako zespół, a oni uderzyli go hard. Teraz to do zespołu (i włączam w to ciebie, przynajmniej na razie) aby dowiedzieć się jak się stąd wydostać. Ostrzeżcie się, nie wszystkie zespoły wychodzą z tej fazy i nie mogę obiecać, że to podejście rozwiąże problem. Mogę zagwarantować, że nie będzie to jednak gorsze niż rezygnacja lub zwolnienie wszystkich.

I upewnij się, że porozmawiasz z Scrum Master osobno. Nie jestem pewien, co spowodowało, że otworzył się z tak niekonstruktywną pierwszą wiadomością, ale musi popracować nad swoimi umiejętnościami komunikacji i rozwiązywania problemów.

Powodzenia z twoimi sytuacja. Na pewno żyjesz w ciekawych czasach; wykorzystaj je jak najlepiej i dowiedz się, co możesz z tego wyciągnąć.

(Zakładam tu również, że Scrum Master nie sprawi, że cały zespół zbuntuje się przeciwko tobie bez żadnych poważnych problemów. Jeśli potrafi i wędkuje do twojej pracy, to jest mistrzem-manipulatorem. Jak tylko osiągniesz punkt, w którym myślisz, że to właśnie się dzieje, musisz pozbyć się tego faceta asap. To chyba jedyny przypadek, w którym rozważałbym użycie twojego autorytetu jako osoby, która go zatrudniła i zwolniła go.)

Niezależnie od tego, czy mają faktyczną możliwość zwolnienia cię jako swojego menedżera, czy też nie, sam na siebie sprowadziłeś tę sytuację, nakazując zmianę scrumu tylko dlatego, że wolisz. Nie omówiłeś tego z nimi. Mogłeś być w granicach swoich praw jako menedżer, ale mimo to było to głupie, a teraz oczywiście pytają, czy chcą już dla Ciebie pracować.

Czy nie widzisz sarkazmu w ich twierdzeniu, że samodzielność i samoorganizacja są podstawą do podjęcia takiego działania?

Musisz zwołać spotkanie jutro o 9:15 i przeprosić za podjęcie tak ważnej decyzji, nie biorąc pod uwagę ich wkładu. Następnie możesz poprosić ich o opinię na temat tego, jak przebiegał ich pierwszy sprint i co można było zrobić inaczej.

Jeśli chcesz wprowadzić nowy proces pracy w tym zespole, możesz spróbować tego na mniejszą skalę, z konkretnymi zadaniami jako program pilotażowy, z wybranymi kilkoma członkami zespołu, którzy są na tyle otwarci, aby wystawić mu uczciwą ocenę.

Z upoważnionymi pracownikami lepiej jest przekonywać, włączać i zachęcać niż upoważniać.

Inna perspektywa: czy przyszło Ci do głowy, że po prostu żartują z procesu Scrum i jego “samoorganizującego się” aspektu? Szczerze mówiąc, nie mogę sobie wyobrazić, żeby byli w ogóle poważni i śmiali się dobrze czytając twój post. Twórcy oprogramowania (jestem jednym z nich) mają tendencję do bycia całkiem cynicznymi ludźmi z suchym poczuciem humoru, którego nie każdy lubi, a nawet nie rozpoznaje. Jestem pewien, że po prostu mówili ci, że nie lubią Scrum.

Być może najlepszym sposobem postępowania byłoby spróbować porozmawiać z niektórymi z nich nieformalnie o Scrumie i o powodach, dla których nie lubią go.

Jak @Sascha poprawnie zauważył , nie wygląda to wcale jak Scrum:

• Zespół Scrum nie ma menedżera, zamiast tego odpowiada przed właścicielem produktu. Właściciel Produktu reprezentuje interesy udziałowców w stosunku do zespołu, organizuje dostawy do sprintu na jego początku, akceptuje wyniki na końcu, a w międzyczasie wyjaśnia sprawy na prośbę zespołu. Jest on zasadniczo pełnomocnikiem pomiędzy zespołem a firmą.
• Gdybyś był częścią zespołu Scrum, wziąłbyś udział w spotkaniu retrospektywnym. Jeśli nie jesteś częścią zespołu Scrum, spotkanie powinno być ograniczone do Twojej roli w odniesieniu do zespołu w ramach modelu Scrum.

Tak więc, pytanie brzmi: Gdzie stoisz na tym zdjęciu? Jaka jest twoja rola w ramach modelu Scrum? *Od kiedy to *tylko ty wpadłeś na pomysł wypróbowania Scrum, zdecydowanie zbadałeś Scrum i pomyślałeś o tym zanim to zasugerowałeś, nie?

A jeśli nie, to czas to zrobić now. Arguably, the most seamless transition for a manager if they’re not considered a part of the team when moving to Scrum ** is the Product Owner.** You’ll continue to do the same thing – but now the team answers to you collectively rather than each member individually, and you stop micromanaging them unless they specifically ask for it (the latter one is probably a good thing for both parties).

Widząc, że najwyraźniej popełniłeś krytyczny błąd w badaniach sugerując Scrum, myślę, że nie zorganizowałeś dedykowanego Właściciela Produktu – więc jesteś dokładnie w stanie podjąć się tej roli teraz.

Nie neguje to faktu, że Scrum Master albo nie ma pojęcia co robi, albo jest po twojej pracy – które inne odpowiedzi pokrywają się odpowiednio z tym jak postępować.

Jak mogę rozwiązać tę sytuację i przywrócić swój autorytet jako ich menadżer, pozostając wiernym zasadom samoorganizacji i wzmacniania zespołu agile?

Od kiedy jest pan menadżerem tego zespołu? Nie sądzę, aby zespół zbuntował się przeciwko bezpośredniemu menedżerowi za brak porozumienia tylko w jednym temacie. Problem może być poważniejszy niż tylko metoda agile.

Jest to coś krytycznego dla menedżera i musisz się do tego odnieść, to powinien być Twój priorytet numer jeden na następne tygodnie.

Twoje n+1, n+2 są na urlopie przez kilka miesięcy? może to wpłynęło na to, że Twój zespół zbuntował się. Jaka jest kondycja finansowa Twojej firmy? ( jeśli jest zła, pracownicy mogą pomyśleć, że wykonujesz złą robotę i mogą lepiej radzić sobie bez Ciebie).

Co robić : - zorganizować spotkanie z całym zespołem : “scrum master powiedział mi, że chcesz mnie zwolnić, co się dzieje?”. (bardzo ważne jest, abyś skierował temat do wszystkich, ponieważ wszyscy go znają i jeśli wpływa to na codzienną pracę). -identyfikuj prawdziwy problem (tylko ta zwinna metoda czy masz już jakiś problem z zespołem?). -Jeśli już znasz prawdziwy problem, musisz zbadać: kto ma rację? Ty czy twoi pracownicy? -Zidentyfikuj, kto jest liderem tej rebelii (zawsze jest pracownik, który sprzeciwia się autorytetom bardziej niż inni). Jeśli uważasz, że jest niestosowny, musisz podjąć działania dyscyplinarne.

Nie jestem pewien, co znaczy “menedżer” w twojej firmie, ale ogólnie rzecz biorąc, myślę, że oznacza on kogoś, kto pomaga zespołom i zwiększa ich wydajność. Teraz:

Jestem wielkim zwolennikiem agile, więc zatrudniłem mistrza scrumu i powiedziałem, że będziemy podążać za scrumem.

Brzmi bardziej jak ‘mam świetny pomysł’ Chcę, żebyście to zrobili. Zamiast konsolidować zespół najpierw w sprawie waszego pomysłu. Myślę, że każdy zespół ma prawo krytykować Twój pomysł i robić dziury w Twoim pomyśle. Jeśli Twój pomysł nie trzyma się kupy, powinieneś móc go porzucić.

Nie jest pewne, czy trzyma się kupy, może powiedzieć zespołowi, że chcesz mieć okres próbny i/lub powolną migrację do nowej struktury projektu.

W ten sposób możesz nadal napotykać opór, ale prawdopodobnie nie tak duży jak teraz.

Myślę, że podsumowując: Jesteś ich menadżerem, nie szefem. To dwie bardzo charakterystyczne prace!

“Kod jest bardziej tym, co nazywasz "wytycznymi” niż prawdziwymi zasadami.“ - Kapitan Barabossa

Brzmi to dla mnie, jakbyś miał kłopoty i starał się trzymać się pewnych nierozsądnych ideałów.

Podkreśliłem zespołowi korzyści płynące z samoorganizacji i wzmacniania zespołu.

Wyjaśnij swoim dzieciom, że samoorganizacja i wzmacnianie zespołu nie oznacza, że mogą robić, co chcą. Jeśli Twój zespół zdecyduje się ukraść jakąś broń automatyczną i obrabować bank, nie musisz się do nich stosować tylko dlatego, że są upoważnieni.

Nie mogą Cię "zwolnić”. Taka jest rola twojego menedżera. Strzelanie zawsze pochodzi z góry łańcucha, nie z dołu. Jasne, mogą przeskakiwać szczeble w hierarchii i pracować z twoim szefem, aby cię usunąć, ale ponieważ najwyraźniej twój szef i twoi szefowie są oboje na urlopie bez umieszczania jednego pod ich nieobecność, nie ma zbyt wiele hierarchii do której mogliby się udać. Masz kilka miesięcy.

Powiedziałem szefowi scrumu, że chciałbym o tym porozmawiać z zespołem, ale był stanowczy, że czuli się “zastraszeni”, kiedy byłem w pokoju, i nie chciał ze mną o tym rozmawiać.

Cóż, to po prostu szkoda dla nich. Porozmawiaj z nimi i tak. Upodmiotowienie może dać ci możliwość podejmowania własnych decyzji, ale nie zwalnia cię z odpowiedzialności za ich realizację. Gdybym miał taki zespół, rozmowa z nim byłaby najlepszym poziomem reakcji, jaki bym rozważył.

Można by powiedzieć “Oh, ale mistrz SCRUM ma rozwiązywać takie problemy. Wszystko powinno przez niego przejść.” Cóż, to trudne. Spieprzył to, kiedy poszedł do ciebie, żeby powiedzieć, że zostałeś zwolniony i nie zrobił tego w wystarczająco uprzejmy sposób, żebyś to zaakceptował. Od mistrza SCRUM oczekuje się, że będzie miał lepsze umiejętności od tego.

Więc co powiesz?

Po pierwsze, chcesz się dowiedzieć, czy rzeczywiście zdecydowali się cię “zwolnić”. Masz na to słowo jednej osoby i uważam, że jest to taka sytuacja, w której zespół powinien być w stanie bezpośrednio powiedzieć swój kawałek.

Po drugie, zastanów się, co oznacza “strzelanie”. Twierdzisz, że nie jesteś kierownikiem, ale oni chcą, żebyś odszedł. Zrozum, dlaczego. Nie wypisują czeków z wypłatą, więc decyzja o zwolnieniu cię nie jest decyzją typu “oh oni nie ciągną za sobą”. To jest decyzja typu “ta osoba aktywnie przeszkadza”. Coś tu się nie sumuje. Musisz to zsumować, zanim podejmiesz jakąś sensowną decyzję. Będąc anonimową osobą w internecie, nie mogę powiedzieć, czy to ty, czy oni, czy mistrz SCRUM, ale _coś naprawdę jest naprawdę złe w tym scenariuszu, i lepiej wiesz, co to jest, zanim skończysz z nimi rozmawiać.

Pracuj z nimi. Bądź menadżerem. Znajdź sposób na rozwiązanie problemu. Znajdź sposób na to, abyś mógł wykonywać swoją pracę, podczas gdy oni wykonują swoją. Spraw, aby tak się stało.

Teraz, jeśli ich odpowiedzi zapewnią Ci wystarczające zamknięcie, aby uhonorować ich samodzielność, teraz musisz pokazać zespołowi, co się dzieje, gdy tak “zwalniasz” przywództwo. Powiedz “Dobrze”. Przestanę zachowywać się jak twój menedżer. Nie możesz mnie tak naprawdę zwolnić, bo to nie jest twoja pozycja, ale jeśli chcesz grać w tę grę, to możemy grać. Byłem twoim menadżerem, pomagałem izolować cię od polityki korporacyjnej i stresu związanego ze składaniem raportów do wyższego kierownictwa. Teraz jestem twoim przełożonym, a ty nie masz już tej izolacji. Skoro nie mogę się usunąć z tej pozycji, po prostu zacznę przekazywać zadania z góry.“ Wyjaśnij, że tylko dlatego, że zespół głosował, nie oznacza to, że nie masz zobowiązań wobec wyższej kadry kierowniczej, które musisz wypełnić i będziesz je wypełniać.

Następnie, poproś o pomoc.

Bunt nie jest drobnostką. Cały twój zespół właśnie zagłosował na ciebie z wyspy. Nie lekceważcie tego. Wezwij kogoś nad tobą do pomocy. Może zadzwonisz do swojego szefa na urlopie. Może porozmawiasz ze swoim CIO. Ktoś musi wiedzieć, że w twojej firmie jest major problem z ludźmi, i że go rozwiązujesz.Ale druga połowa jest wyraźnie ważna. Nigdy nie idź do kierownictwa z problemami, idź do nich z rozwiązaniami.

Rozwiązaniem, które bym polecił, jest stworzenie swojego wizerunku jako "menedżera z wymaganiami” poprzez wybór rzeczy, które wymagają od kierownictwa (np. CIO), które jest tak skonstruowane, aby zbudować pewną samorealizację, która pójdzie w parze z tym upodmiotowieniem. Mogą myśleć, że mogą robić to, co chcą, ale i tak musisz sprawić, by odnieśli sukces jako zespół._ Jeśli musisz to robić z daleka, rób to z daleka. Dowiedz się, co było tak zastraszające w twoim podejściu z pominięciem rąk i upewnij się, że nigdy tego nie zrobisz.

Celem końcowym jest uświadomienie im, że jesteś po ich stronie. Jeśli są naprawdę samodzielni, to muszą zdać sobie sprawę, że jesteś korzystną częścią zespołu. Uświadomią sobie, że jesteś korzystną częścią zespołu, tylko wtedy, gdy im się to uda. Jeśli zostaną pogrążeni w niemożliwości. terminy i beznadziejna biurokracja, nigdy tego nie zobaczą.

Upewnij się tylko, że to wszystko się zgadza. 2+2=4. Menedżer “hands off” jest “zwolniony” przez nowego mistrza SCRUM za bycie zbyt zastraszającym, podczas gdy dwie warstwy zarządzania są na urlopie? Coś się stąd nie sumuje. Jesteś bliżej sytuacji. Dowiedz się, co się nie zgadza i napraw to.

Albo: a) Oni mają rację, a ty nie uzasadniłeś swojego istnienia. (Nadal nie mogą cię zwolnić) lub b) Scrum Master chce twojej pracy.

Myślę, że najlepszą rzeczą jaką możesz zrobić jest pójście na 2-dniowy kurs scrum Master i pozbycie się twojego mistrza scrum. Wtedy prawdopodobnie będziesz mógł otrzymać premię pod koniec roku za wykonanie dwóch prac.

Nie ma żadnej** roli kierownika w zespole scrum. Prawdziwym pytaniem jest, dlaczego myślałeś, że jesteś członkiem zespołu na pierwszym miejscu. Jeśli nie uczestniczysz w dostarczaniu funkcji, nie masz miejsca w tym zespole - więc to, co zrobiłeś, było prawidłowe.

Jeśli uważają Cię za przeszkodę, dowiedz się dlaczego - prawdopodobnym scenariuszem jest to, że się wtrącałeś, a rozwiązaniem jest to, abyś się wycofał i pozwolił im wykonywać ich pracę.

What do you think your role is in the team? Wymyśl użyteczną odpowiedź, która jest zgodna z celami scrumu, a następnie podkreśl zespołowi, że zamierzasz wykonać tę pracę, a nie wtrącać się do jego pracy.

Więc nie widzę powodu, dla którego nie możesz postrzegać tego jako czegoś pozytywnego? Rozumiem, że celem samozarządzającego się zespołu jest nie potrzebowanie menedżera.

To, co musisz zrobić, to spojrzeć na możliwości, które to stwarza. Zasadniczo masz super zespół, który potrafi samodzielnie zarządzać, a teraz jesteś w stanie zrobić co następuje:

• Łatwiej jest rozliczać zespół z zobowiązań firmy. Jeśli nie są w stanie zrealizować celów firmy, to po prostu nie są w stanie samodzielnie zarządzać
• Możesz rozwijać umiejętności w zespole. Tak więc teraz możesz skupić się bardziej na aspekcie ludzkim w zespole. Rozwój kariery, możliwości i tego typu rzeczy.
• Zdaj sobie sprawę, że zespół + scrum master nadal odpowiada przed Tobą w hierarchii firmowej, budżetach i procesie oceny wyników. Więc to nie jest tak, że mogą przejść nad Twoją głową.

Pomyśl o tym jako o sukcesie na razie. Pomyśl więcej o tym, jak możesz wzmocnić swój zespół. Uświadom sobie również, że musisz być na miejscu w przypadku scenariusza, w którym to podejście do samozarządzania zawodzi.

Lao Tzu powiedział

The wicked leader is s/he who the people despise,

The good leader is s/he who the people reverevere,

When a great leader leads, people say “we did it yourself”.

A leader is best when people barely know he exists,

when his work is done, his aim fulfilled,

they will say: we did it yourself.

and I’ve been following this maximically since day 1 of leading dev teams. Jeśli wszyscy wiedzą, co mają robić, to ja nie jestem potrzebny, a moja praca jest najlepiej obsłużona w ten sposób - ciesząc się życiem poza biurem.

Śledzisz wskaźniki, sprawdzasz ich kod, robisz drobne korekty kursów, zachęcasz i włączasz wszystko, co wymaga zachęcania i włączania - komunikację, współpracę, pisanie testów itp., chronisz je przed wyższą kadrą kierowniczą i klientami - a najlepiej nigdy nie działasz.

Ale kiedy to robisz, robisz to i kopiesz nosy, kiedy to konieczne, jesteś facetem, który jest odpowiedzialny za ich pracę, w końcu - ludzie zostają zwolnieni z pracy na Twoją rekomendację i zwolnić powinieneś, i to na czas.

Nie jestem pewien, dlaczego jakikolwiek deweloper miałby zwalniać kogoś, kto nie stoi mu na drodze i w zasadzie jest po to, aby naprawić rzeczy dla nich i chronić ich przed klientami, a czasami nawet wyżej, dba o dostępność sprzętu, dokumentacji, nudności zawsze tak lekko, aby być lepszymi programistami i lepszymi ludźmi i umożliwiać im skupienie się na kodzie.

Wciąż jesteś ich wyżej - wciąż możesz ich zwolnić, jeśli musisz, nie zostałeś zwolniony z tej pozycji. Zostałeś po prostu uznany za bezużytecznego lub szkodliwego dla rozwoju, a oni wolą grać bez Ciebie.

Albo to, albo dzieje się jakaś poważna patologia w kulturze zespołu.

Powiedziałbym, że to niesamowita okazja do wspaniałej refleksji i rozwoju.

Widzę tu dwa punkty widzenia:

• Byłeś menedżerem liniowym zespołu rozwojowego w organizacji macierzowej, a nadal jesteś menedżerem liniowym. Twoja praca mogła się nieco zmienić, ale jest zasadniczo taka sama - zapewniasz dni robocze dla programistów zgodnie z procedurami budżetowymi/korporacyjnymi, opiekujesz się zatrudnianiem (a w razie potrzeby zwalnianiem), planujesz odejścia we współpracy z zespołem, i tak dalej. W rozwoju zwinnym, Twoja rola może być nieco mniej orzechowa niż kiedyś, ale szczególnie jeśli jest wiele zespołów scrumowych, Twoja rola będzie teraz obejmować takie rzeczy jak zachęcanie “społeczności do praktyki” lub “gildii”. Jak wszystko inne, scrumy mogą być szkodliwe, jeśli będą traktowane ekstremalnie, i somebody powinien zadbać np. o to, aby stosy technologii pozostały kompatybilne, chyba że istnieje bardzo dobry powód, aby zrobić wyjątek. To jest zadanie zarządzania liniowego w takiej organizacji.
• Byłeś członkiem zespołu programistycznego i miałeś bezpośredni wkład w decyzje technologiczne, architekturę, i tak dalej. W tym przypadku sugerowałbym, że spieprzyłeś, nie angażując się wystarczająco w ten pierwszy sprint, ponieważ nie widzą, jak wniesiesz swoje umiejętności do zespołu. W następnym sprincie, pracuj z zespołem.

I’m a manager of a development team.

I’m a huge advocent of agile

Good! Jeśli przez “agile” rozumiesz “Scrum Master” (po co zatrudniłbyś Scrum Master, w przeciwnym razie…), to wszystko jest dobrze.

Oni historycznie stosują bardzo metodologię wodospadu i są odporni na zmiany.

zespół wspólnie zgodził się “zwolnić” mnie jako swojego menedżera

Dobrze! […] […] Pamiętam, kiedy dostałem certyfikat Scrum Master na 3-dniowym seminarium; rola “menedżera” nie była nawet na wykresie.

Jeśli Twoja firma korzysta z typowej struktury macierzowej pionowego zarządzania liniowego vs. poziomego zarządzania związanego z projektem (lub produktem) (tj. menedżera liniowego <<> menedżerów projektów/produktów), wtedy wszystko wydaje się iść zgodnie z planem. Nadal będziesz miał obowiązki kierownicze, to znaczy zarządzanie wszystkim, co jest poza codzienną, produktywną pracą Twojego zespołu.

Powtórzę Twoje kluczowe zdanie:

Jestem wielkim zwolennikiem agile

Teraz jest dobry moment, aby to przyjąć i dowiedzieć się, co to znaczy zarządzać zespołem Scrum. […] Zajmujesz się zwykłymi rzeczami (przyjmowanie nowych członków, obsługa pensji, pomaganie zespołowi w pracy (zdobywanie ich sprzętu/softwar/etc. i dobre środowisko pracy), być może współpraca z innymi menedżerami Scrumu). […] […] […] […] […] […] […] […] […] […] […] […] […]