Dominujący członkowie zespołu w zespole Scrum

Co zrobiłbyś w sytuacji, gdy członek zespołu próbuje przejąć obowiązki początkowo nie jest mu przypisany, ale Scrum Master?

Zespół Scrum jest samoorganizujący, więc jest miejsce dla kogoś, kto jest nieco bardziej dominujący. Inni powinni zapytać go o jego pomysły na zadania, nad którymi pracują, ale jego dominacja musi być pod kontrolą.

Co możesz zrobić:

• Motywuj innych, aby byli niezależni, ale współpracowali - najlepiej to osiągnąć, jeśli będziesz współpracować z ich menedżerem i HR, który wyznaczy im pewne oczekiwania, które będą regularnie oceniane.
• Podczas stand-upów, planowania i retrospekcji; pozwól innym członkom zespołu mówić pierwszy. Podczas recenzji pozwól innym członkom zespołu przedstawiać historie użytkowników, które zrealizowali.
• Pozwól innym najpierw wybrać zadania, aby dominujący programista nie mógł tylko wybrać zadań, które chce wykonać.
• Zaangażuj programowanie par dla niektórych zadań, aby dominujący członek zespołu współpracował z innymi programistami.
• Bądź demokratyczny - opinia jednego członka zespołu nie wystarczy, aby wprowadzić zmiany w procesie - Scrum będzie działał tylko wtedy, gdy zespół komunikuje się wyraźnie lub po prostu będziesz się blokować.
• Jeśli nic z tego nie pomoże, powinieneś porozmawiać z dominującym członkiem zespołu i wyjaśnić mu sytuację - ale uważaj, nie ma lidera zespołu w Scrumie z jakiegoś powodu. Jeśli masz wsparcie ze strony kierownictwa, możesz również zagrozić stabilności jego pracy, ale powinna to być ostatnia opcja.

Jeśli dominujący członek zespołu nie chce stracić swojej dominacji, a pasywni członkowie zespołu nie chcą być bardziej aktywni, potrzebujesz wsparcia ze strony swojego menedżera i HR. Może to stanowić problem, jeśli zarząd nie zachęca do procesu Scrum.

Przypuszczalnie powodem tego pytania jest to, że czujesz, że zespół w jakiś sposób osiąga słabe wyniki z powodu tej dominującej osoby. Być może dlatego, że reszta zespołu nie wnosi 100%, ponieważ, cóż, o co chodzi?

Jeśli jesteś menedżerem, Twoim obowiązkiem jest upewnienie się, że wszyscy Twoi pracownicy rozumieją, jakie są ich role. W szczególności, czego się od nich oczekuje i jak będą oceniane. Jako członek zespołu Scrum, każda osoba jest osobiście odpowiedzialna za sukces zespołu. Tak więc ten dominujący członek zespołu musi wiedzieć, że nie ponosi odpowiedzialności i zostanie odpowiednio oceniony.

Informacje zwrotne to kluczowy punkt. Jeśli jest spotkanie zespołu, a ta osoba dominuje w dyskusji, narzuca swoje projekty i podejście reszcie zespołu i popycha resztę do pasywnych ról, należy mu powiedzieć, szczerze i prywatnie, że nie spełnia wymagań roli. Jeśli zauważysz, że podstępnie podkreśla tylko swoje osobiste osiągnięcia, należy go wezwać i zrozumieć, że osobiste osiągnięcia są cenione znacznie, znacznie mniej niż pomoc zespołowi w osiągnięciu grupy.

Wszystko to jest trudne, ale po to są menedżerowie i Scrum Masters.

Jest na to jeszcze jeden sposób. Niech to będzie problem zespołowy. Zadzwoń do nich razem i powiedz, że osiągają słabe wyniki. Oto dlaczego. Poproś, aby wymyślili rozwiązanie. Możesz być zaskoczony.

Poproś autora alfa o opinię. Jest całkiem możliwe, że nie ma pojęcia o tym, jaki efekt ma. Zabierz go na bok i powiedz mu, co myślisz. Możesz nawet wysłuchać dyskusji na temat „hej, jesteś naszym głównym programistą, ale musimy doprowadzić te osoby do twojego poziomu, potrzebuję twojej pomocy w ustaleniu, jak możemy to zrobić?”. Zamień jego dominację w atut. Sprawdź, czy potrafi to zrobić.

Jeśli oceni, jak dobrze wspiera swój zespół i podnosi go na wyższy poziom, będzie miał większą motywację do tego.

Sugerujesz, że tak naprawdę nie działa w interesie zespołu (zgaduję), tzn. Że jest w jakiś sposób zły, więc tak, usuń go. Ale mądry człowiek powiedział mi kiedyś: Nie zakładaj złej woli, gdy bardziej prawdopodobne jest niekompetencja lub zwykła ignorancja.

Wygląda na to, że próbuje zostać mistrzem Scrum.

Wyjaśnij swoje pozycje i działaj odpowiednio.

Rolą Scrum Master jest umożliwienie ducha zespołu. Jeśli nie możesz sprawić, by ta jedna osoba była graczem zespołowym, usuń go z zespołu .

Szybka uwaga: Twój dominujący programista nie jest bardziej problematyczny niż pasywny programista.

obecnie planowanie sprintu jest rolą, która zmienia się w zespole

Planowanie sprintu powinno obejmować cały zespół, a nie być przekazywane pojedynczej osobie na raz. Chyba że istnieje ku temu dobry powód, uważam to za poważny problem.

Jeśli to, co mówisz, jest prawdziwe i obiektywne, masz poważny problem: ludzie, którzy nie uczestniczą, i „Dominator”, który uniemożliwia naprawdę zwinny proces. Jako mistrz srum musisz podjąć działania. Może chciałbyś przekonać swojego kierownika projektu do pewności co do tej sytuacji.

Wiele zespołów odchodzi od rdzenia zwinnego, a Twoim zadaniem jest ich przywrócić. Musisz uczyć i ponownie osadzać zwinne wartości w zespole. W rzeczywistości powinieneś stale uczyć zwinnych wartości. Pokaż swoją zwinność, spraw, by była jasna i mocna. Pokaż im swoje zaangażowanie w „zwinne wykonanie dobrze”.

Aby to zrobić, przeprowadź ich przez zwinny manifest i wartości Scruma. Zapytaj ich, co oznacza dla nich współpraca i dlaczego jest ważna. Zapytaj ich o rolę zaufania w zwinnym. To świetny czas, aby porozmawiać o tym, dlaczego w Scrumie nie ma roli kierownika zespołu ani roli kierownika projektu, a tworzenie całego oprogramowania jest obowiązkiem całego zespołu , a nie osoby.

Zaplanuj całą sesję retrospektywną wokół tego. Poproś, aby zobowiązały się do przestrzegania niektórych wartości i kontynuowały podczas następnej retrospekcji. Nie celuj palcami, używaj neutralnych metod.

Wprowadź metody, które zmuszają pozostałych członków do bezpiecznego wyrażania opinii. Coś prostego, jak pięści z pięciu, doskonale nadaje się do usłyszenia cichych głosów w zespole. To boleśnie oczywiste, że zespół nie zgadza się z dominującym facetem. Planowanie pokera działa dobrze, ale kluczem jest niedopuszczanie do dyskusji przed pokazaniem kart. Wszystko, co pomaga wysłuchać innych bez wywoływania konfliktów, jest pomocne.

Jeśli wszystko pójdzie dobrze, wszystko gotowe. W przeciwnym razie porozmawiaj z nim o problemie. Skorzystaj z coachingu i zadawaj potężne pytania, które pomogą mu jasno zrozumieć problem. Postaraj się dotrzeć do przyczyny, dla której przyjął on dominującą rolę. Może brakuje mu zaufania do zespołu (dlaczego?) I może czuje się odpowiedzialny za sukces (dlaczego?). Podejrzewam, że ta rola nie jest czymś, czego chce i całkiem możliwe, że chciałby, żeby to się zmieniło. On może podjechać i go zrealizować.

Być może „dominujący” twórca jest nagradzany za swoje indywidualne osiągnięcia, a nie osiągnięcia zespołowe?

W przeszłości upewniałem się, że ludzie, którzy są bardzo głośni i mają jasne pomysły, są nagradzani (poprzez swoje cele) poprzez wspieranie innych.

Ogólnie rzecz biorąc, myślę, że złym pomysłem jest solidne nagradzanie członków Scrum za ich indywidualny wkład, a nie za osiągnięcia zespołu.

Możesz także spróbować zrobić 360 rundę zwrotną w swoim zespole dla wszystkich członków zespołu, tylko jeśli uważasz, że inni członkowie zespołu będą szczerzy w swoich komentarzach.

Zaproponuj, że zostanie Scrum Masterem na następny sprint.

Ludzie, którzy chcą wziąć na siebie odpowiedzialność, nie stanowią problemu (o ile nie chcą mieć nad nimi monopolu), właśnie to chcemy osiągnąć dzięki samoorganizacji.

Nawiasem mówiąc, zespoły z obrotową rolą mistrza scrum nie są rzadkością.

Jedynym zadaniem mistrza Scrum jest upewnienie się, że wszyscy przestrzegają zasad książki Scrum. Jeśli mistrzowie spoza Scrum zrobiliby to sami bez ingerencji mistrza Scrum, to po prostu pokazałoby, że jesteś w świetnej (Scrum-) formie! Im mniej mistrz Scrum musi zrobić, tym bardziej szczupły i szczupły jest twój zespół z perspektywy Scruma. W końcu rola mistrza Scrum może / powinna zostać wyeliminowana, on jest tam, aby pomóc ci zacząć i uczyć Scruma.

Ponownie mistrz Scrum nie bierze udziału w procesie rozwoju. Powinien upewnić się, że wszystkie zainteresowane strony komunikują się na czas o właściwych rzeczach, zna Scrum i udziela wskazówek dotyczących Scrum, nie jest właścicielem produktu ani liderem projektu. Jeśli doświadczasz czegoś innego, być może nie robisz Scruma w zwinnym duchu. Oczywiście w mniejszych ustawieniach Scrum Master może odgrywać rolę jednego z członków zespołu lub interesariuszy na boku. To tylko czapka, którą nakłada się, gdy nadchodzi czas na formalności. Nie myl go z rolą przywódczą, jest to rola przewodnia.

Uwzględnij indywidualizm i indywidualne wyniki, ale także spróbuj wzmocnić pasywne jednostki, aby stały się bardziej partycypacyjne.

Z mojego doświadczenia wynika, że ​​chociaż na pierwszy rzut oka mogą się wydawać podobne, komunizm i zwinność to nie to samo. Agile nie ma na celu bezklasowego społeczeństwa (zespołu), ale oprogramowania, które działa.

Postaraj się, aby programista alfa zrozumiał, że może pomóc ci rozwinąć umiejętności innych, pytając i trenując, zamiast odpowiadać zawsze na pierwszym miejscu i osiągając indywidualne osiągnięcia. Z pewnością twój programista alfa dba o dobre oprogramowanie i nie możesz sobie pozwolić na przegraną.