Jak radzić sobie z przeciwdziałającym produktywności zespołem scrum?

Backstory:
Pracowałem jako część tego zespołu przez ostatnie trzy lata i tym razem mieliśmy trzech różnych Scrum Masterów, którzy prowadzili wszystko inaczej.

Z powodu tej zmiany w Scrum Masters i ich sposobie prowadzenia serialu, mój zespół odrętwiał na pomysł Scrum, ponieważ zasady nie były konsekwentnie egzekwowane, a jeden z Scrum Masters był osobą, która nie wierzy w zwinność rozwoju i po prostu zachowywał wydarzenia i artefakty jako nowicjusz, aby postępować zgodnie z decyzjami firmy.

Teraz członkowie mojego zespołu są zirytowani i znudzeni, kiedy robimy wydarzenia Scrum, a jedna osoba w szczególności bardzo się o tym mówi.

Obecny:
Dwa miesiące temu firma mianowała mnie Scrum Master z mojego zespołu ze względu na moje zaangażowanie w pracę zwinną i jej zasady.

Bardzo cierpię pod presją atmosferyczną członków mojego zespołu, którzy nie chcą robić Scruma.

Jak wspomniano, są zirytowani całym procesem, co sprawia, że ​​jest to dla mnie bardzo trudne, ponieważ nie angażują się w niezbędne rozmowy potrzebne do skutecznego planowania, retrospekcji i codziennego Scruma.

Dla nich planowanie to tylko strata czasu, ponieważ po prostu przenosimy przelew do nowego Sprint i i tak nie kończymy pracy, więc po co się tym przejmować.

Podczas Retrospektywy czuję, że chcą powiedzieć „Przestań robić Scrum”. Jedna osoba tak robi, ale pozostałe milczą i za każdym razem muszę sobie z tym poradzić.

Daily Scrum jest dla nich po prostu stratą czasu, ponieważ żaden z nich nie zawraca sobie głowy rozmową i planowaniem dnia. Po prostu stwierdzają: „Pracowałem wczoraj nad zadaniem X i nad tym dzisiaj popracuję”. I przez większość czasu po prostu żartują, aż zrobię się bardziej surowy.

Byłem bardzo duży, jeśli chodzi o to, jak spędzili czas podczas tych wydarzeń. Ale umieram w środku, ponieważ mam do tego pasję i już ich to nie obchodzi.

Dzisiaj osoba, która zawsze jest przeciwko mnie, powiedziała mi, żebym przestał mówić „Powiedzieli, że to właśnie zobowiązali się do tego Sprintu”, ponieważ jego słowami: „Nigdy nie kończymy Sprintu. Po prostu wykonujemy zadania i przyjmujemy nowe w następny Sprint, aby wypełnić przydział. Robimy KanBan w rzeczywistości. Przestań więc to mówić ”.

Rozumiem, dlaczego to mówi, ale nie zdaje sobie sprawy, że tak właśnie jest, ponieważ on i wszyscy inni w zespole nie dbają o to. Po prostu wykonują pracę zamiast radzić sobie z przeszkodami. Skarżą się na przeszkody, ale nic z nimi nie robią. A kiedy próbuję pomóc, po prostu wzruszają ramionami.

Cholernie to obchodzili, ale w ciągu ostatnich dwóch lat ich gotowość spadła do mniej więcej dna.

Jak sprawić, by zobaczyli, że żartowanie i marnowanie czasu podczas tych spotkań kosztuje firmę dużo pieniędzy?

Być może słyszałeś wiele statystyk dotyczących nieudanych projektów oprogramowania i doszedłeś do wniosku, że awaria nie ma charakteru technicznego. Problemy technologiczne można rozwiązać za pomocą setek rozwiązań technicznych, ale rozwiązywanie problemów w środowisku pracy za pomocą Scrum nie zadziała.

Proponuję tutaj, aby całkowicie przestać postrzegać to jako problem techniczny. Nie chodzi o Scruma, nie chodzi o codzienne pojedynki, sprinty, retrospektywy ani nic podobnego. Musisz skontaktować się ze swoim zespołem i znaleźć skuteczny sposób pracy, który zadowoli ich, a także ciebie i twoich przełożonych.

Jeśli uważają, że dzienniki są złym pomysłem, nie powinieneś im mówić, aby robili dzienniki i próbowali wbić w nie swoje rozumowanie. Zastanów się, co oferują ci dzienniki. Sprawdź ze swoim zespołem, czy również cenią te zalety. Dowiedz się, dlaczego nie podzielają twojego zrozumienia - tak jak dla zrozumienia ich punktu widzenia, a nie dla przekonania ich o czymkolwiek. Następnie sprawdź, czy dzienniki rzeczywiście pomagają Twojemu zespołowi, czy też możesz osiągnąć więcej za pomocą innego mechanizmu. Zabawną rzeczą w mistrzach Scrum jest to, że są sługami ich drużyny - możesz im najlepiej służyć, całkowicie znosząc Scruma.

Podsumowując, przestań skupiać się na Scrumie, a zamiast tego wróć do podstaw zwinności. Możesz zacząć od samego początku zwinnym manifestem : oceniaj osoby i interakcje w procesach i narzędziach.

Z mojego doświadczenia wynika, że ​​zespoły rozczarowane muszą zacząć od skutecznych retrospekcji. Dlatego moim zdaniem retrospektywy są jedyną obowiązkową częścią zwinnego procesu. Wszystko inne może ulec zmianie poprzez retrospektywy.

W skutecznych retrospektywach nie tylko narzekasz na swoje problemy, wybierasz co najmniej jeden z tych problemów i identyfikujesz możliwe rozwiązania, a następnie wypróbujesz to rozwiązanie podczas następnej iteracji. W następnej retrospektywie mówisz o tym, jak to rozwiązanie działało lub nie działało, i w razie potrzeby dokonuj dalszych korekt lub wybierz inny problem do rozwiązania.

Gdy członkowie zespołu zobaczą, że są w stanie dokonać rzeczywistej zmiany w swoim procesie, będą bardziej skłonni do zaangażowania się.

Proces retrospektywny jest taki, że jeśli odwiedzisz wszystkie zespoły w firmie, która dobrze sobie radzi, wszystkie robią to nieco inaczej. Mamy kilka drużyn, które wykonują Kanban, niektóre z XP, niektóre tylko z pojedynkami w poniedziałek, środę i piątek.

Jeśli twój zespół nie lubi sposobu radzenia sobie z kacami, przeprowadź burzę mózgów na kilka sposobów. Wygrałem na bardzo niechętnie deweloperom tylko poprzez konsekwentne słuchanie w retrospektywy i próbuje rozwiązania.

Ok, więc zacznijmy ostro - duża część problemu leży po twojej stronie - słyszysz, ale nie słuchasz. Twój zespół jasno mówi ci o problemach. Musisz zająć się nimi, zamiast obwiniać swój zespół.

Planowanie

Dla nich planowanie to tylko strata czasu, ponieważ po prostu przenosimy przelew do nowego Sprint i i tak nie kończymy pracy, więc po co się tym przejmować.

Dokładnie. Jeśli konsekwentnie nie przeznaczasz odpowiedniej ilości czasu na zadania i są one stale niedoceniane, ma to bardzo negatywne skutki:

• Deweloperzy czują, że są pod ciągłą presją.
• „Nie mogę nic zrobić na czas”.
• Ponieważ proces nie działa, słusznie postrzegają go jako stratę czasu.

Rozwiązanie : Napraw swoje oszacowania, używając kombinacji:

• Punkty opowieści (jako kombinacja czasu i ryzyka).
• Nie zezwalaj na wykonywanie sprintu o wartości> 55 SP
• Szacunki porównawcze
• Planowanie oparte na dowodach

Jako podstawa do tego, absolutnie musisz śledzić czas, jaki faktycznie zajęło ukończenie poprzednich zadań, w tym testowanie, pisanie dokumentacji, pisanie testów, szkolenie użytkowników końcowych, wysiłki integracyjne, wdrażanie. itp.

Gdy masz całkowity czas na dane zadanie, możesz oprzeć oczekiwany czas na tych wcześniejszych zadaniach.

Zapytaj każdego członka, czy powierzone mu zadanie wydaje się bardziej skomplikowane lub łatwiejsze niż wybór wcześniejszych zadań, dostosuj na tej podstawie liczbę przydzielonych zadań.

Jeśli nie korzystałeś wcześniej z SP, radzę zacząć od 1 godziny prawdziwej uczciwej wobec boga pracy = 5SP jako wskazówki. Należy pamiętać, że w zwykłym środowisku programistycznym, dostaniesz może 6 osób dziennie, więc 30SP / dzień max . Nigdy nie dopuszczaj do zadania, które zajmuje więcej niż 2 dni. Z mojego doświadczenia wynika, że ​​powinieneś mieć 2 zadania dziennie.

Jeśli nie wykonasz Planowania poprawnie, pozostałe działania Scruma będą wyglądały na stratę czasu (w tym Planowanie).

Z mocą wsteczną

Podczas Retrospektywy czuję, że chcą powiedzieć „Przestań robić Scrum”. Jedna osoba tak robi, ale pozostałe milczą i za każdym razem muszę sobie z tym poradzić.

Przypomina mi o Daily beatings will continue until morale improves!dwóch poprzednich pracach. Jeśli nie usuniesz przeszkód, masz rację, że to strata czasu.

Ponownie, posłuchaj, co ludzie tak naprawdę mówią. Jeśli skargi podniesione podczas retrospekcji nie zostaną rozpatrzone, po co w ogóle je robić?

Więc:

• Rozważ techniki Six Thinking Hats, aby poprawić komunikację.
• Zmniejsz czas spędzany na retrospekcji, maksymalnie 30 minut.
• Upewnij się, że skargi podniesione podczas Retrospektywy zostaną rozpatrzone przed następnym.

Codzienne SCRUMY

Daily Scrum jest dla nich po prostu stratą czasu, ponieważ żaden z nich nie zawraca sobie głowy rozmową i planowaniem dnia. Po prostu stwierdzają: „Pracowałem wczoraj nad zadaniem X i nad tym dzisiaj popracuję”. I przez większość czasu po prostu żartują, aż zrobię się bardziej surowy.

Wygląda na to, że masz tutaj dwa problemy: spotkania SCRUM są zbyt długie, a twoje planowanie i tworzenie zadań jest do kitu.

Oba mogą zabrzmieć jak spotkanie scrumowe to strata czasu.

Dla długości SCRUM:

• Spróbuj maksymalnie 15 minut.
• Spróbuj wszystkich na stojąco.
• Naprawiona formuła:
  • Co robiłeś wczoraj
  • Co dzisiaj planujesz?
  • Co członkowie twojego zespołu (nie ty!) Powinni wiedzieć o zadaniu, jak wpłynie na nich.
• Nie przejmuj się przeszkodami, jeśli nie zamierzasz się z nimi uporać.

To drugi dowód na to, że twoje planowanie pogarsza twoją sytuację - jeśli nie masz nic konkretnego do zgłoszenia, oznacza to zwykle, że zadanie jest zbyt duże i wszystko, co możesz powiedzieć, to: Pracowałem nad tym.

• Podziel zadania na punkty.
• Upewnij się, że zadania są wystarczająco małe, aby zająć mniej niż jeden dzień. Idealnie, zadanie IMO powinno trwać ~ 3 godziny i odpowiadać około 13 SP, więc możesz wykonać 2 dziennie w większości warunków.

Radzenie sobie z zespołem

Dzisiaj osoba, która zawsze jest przeciwko mnie, powiedziała mi, żebym przestał mówić „Powiedzieli, że to właśnie zobowiązali się do tego Sprintu”, ponieważ jego słowami: „Nigdy nie kończymy Sprintu. Po prostu wykonujemy zadania i przyjmujemy nowe w następny Sprint, aby wypełnić przydział. Robimy KanBan w rzeczywistości. Przestań więc to mówić ”.

On ma rację. Mylisz się. Robisz bastardowany SCRUM i / lub wariację na Kanban. To wcale nie ich wina.

Rozumiem, dlaczego to mówi, ale nie zdaje sobie sprawy, że tak właśnie jest, ponieważ on i wszyscy inni w zespole nie dbają o to.

Nie sądzę, że w ogóle rozumiesz. Być może opiekują się mniej niż kiedyś, jednak obwinianie ich nie tylko niczego nie poprawi, ale może tylko pogorszyć sytuację. Gdyby to było dno, mogliby zacząć kopać.

Po prostu wykonują pracę zamiast radzić sobie z przeszkodami.

I tutaj myślałem, że praca jest tym, o co chodzi w ich pracy. Zastanawiam się, kto miał do czynienia z przeszkodami ... och, racja. Scrum Master. To twoja praca. Mówią ci, co jest nie tak. Napraw to. Nie na odwrót.

Prawdopodobnie dlatego masz tyle problemów w Retrospektywie.

Jak sprawić, by zobaczyli, że żartowanie i szarpanie kół podczas tych spotkań kosztuje firmę dużo pieniędzy?

Zatrzymaj bezużyteczne spotkania, a zamiast tego będą żartować z watercooler. Zobacz także akapit o biciu poprawiającym morale. Jeśli używają humoru jako mechanizmu obronnego, pan ma poważne problemy!

Żartuj sobie - jak w pracy ze swoim zespołem, a nie przeciwko. (Komu zależy na pieniądzach firmy? Jesteś teraz akcjonariuszem?)

Podsumowując

Twoje złe planowanie powoduje, że inne części SCRUM zawodzą, a wszyscy uczestnicy są nieszczęśliwi. Widzą, że nic się nie zmienia, nic nie jest adresowane, a ich skargi nie zostały wysłuchane.

Popraw swoje planowanie, a poprawisz przepływ i morale.

Wykonaj swoją pracę, usuwając przeszkody, a Twój zespół będzie się rozwijał szybciej. Zapytaj ich, co według nich powinieneś zrobić, aby im pomóc.

Co najważniejsze: słuchaj swoich ludzi. Powiedzieli już tobie (i mnie) o co chodzi.

Powodzenia!

Jedną z głównych zasad zwinności jest cofanie się i poprawianie wszystkiego, co jest złe. Obejmuje to nie tylko refaktoryzację kodu i poprawki błędów, ale także naprawę procesu programowania.

Dlaczego więc nie spotkasz się ze swoim zespołem i nie zobaczysz, jak możesz ulepszyć proces rozwoju? Jeśli to oznacza, że ​​nie będzie żadnych spotkań ze scrumem lub standupem, niech tak będzie.

Łamiesz także jedną z zasad zwinnego manifestu : „Osoby i interakcje w procesach i narzędziach”.

Z drugiej strony, jeśli twój zespół uważa, że ​​iteracyjny rozwój jest zły, być może robisz to źle. Nie ma znaczenia, że ​​nie skończysz wszystkiego, co zaplanowałeś na jedną iterację - zawsze możesz przenieść rzeczy do następnej iteracji. Dlatego też oznaczasz rzeczy jako „musi zawierać”, „miło mieć”, itd. Dopóki zapewnisz nową funkcjonalność, robisz to dobrze.

Tylko mały rant: w mojej poprzedniej i obecnej firmie odbyliśmy i nadal odbywamy spotkania standup. Z mojego doświadczenia wynika, że ​​to ogromna strata czasu, ponieważ za każdym razem zmieniają się one w ponad 30-minutowe spotkania z raportami o stanie, a dla mnie nie dostarczają żadnych informacji. Ludzie mówią o swoich problemach, których szczerze mnie to nie obchodzi.
W mojej poprzedniej firmie byli sprytni, rozpoznawali ten problem z awariami i zatrzymali je wkrótce po tym, jak ludzie zaczęli narzekać.

Jeśli chcesz zobaczyć naprawdę dobry film o scrumie, zobacz „ Robert C. Martin - Kraina, o której zapomniał Scrum ”.

Jako priorytet chciałbym spojrzeć na zadania, które wciąż się przenoszą. Niezrealizowanie celów jest niezwykle demoralizujące. Za dużo się angażujesz? Czy są jakieś dzienniki tłuszczu, które należy rozbić? Czy istnieją jakieś wąskie gardła poza twoją kontrolą? Czy masz jasną definicję „zrobione”? Czy wymagania są jasne? Czy godziny na programistę są rozsądne (tj. Uwzględniają administratora, standupy, planowanie, retrospektywy, przerwy na klawiaturę, pracę niezwiązaną z projektem).

Następnie porzuć cokolwiek, co nie działa. Proces bez wartości to tylko złodziej czasu. Awarie mogą pochłaniać dużo czasu, jeśli nie są skoncentrowane i nie zapewniają wartości zespołowi. Godziny lepiej spędzić gdzie indziej. Może także rozważyć podzielenie zespołu, jeśli jest on zbyt duży.

Postaraj się zrozumieć, co motywuje zespół. Miej retrospektywy i, co ważniejsze, działaj na podstawie wyników. Równie ważne jest świętowanie sukcesów, a także patrzenie na niepowodzenia.

Wreszcie, możesz chcieć ocenić podejście mistrzów scrum, którzy odeszli wcześniej, którzy mogliby tak nazwać markę. Pracowałem pod kierunkiem toksycznego mistrza scrum, gdzie każdy podniesiony problem był dodawany do twojego obciążenia, niezależnie od tego, czy o tym wiedziałeś, czy nie. Rezultat końcowy: problemy zostały zignorowane i wszyscy pracowali na swoim małym obszarze przy bardzo małej pracy zespołowej.

Sprawienie, by Twój zespół skutecznie zamknął twój sprint (jak co najmniej blisko 80% historii), jest moim zdaniem najważniejszą rzeczą, jaką możesz zrobić. Jeśli ciągle brakuje twojego zespołu, oznacza to, że musisz skorygować swoje prognozy.

Zespół powinien być na to otwarty, choć może być bardzo trudne, aby programiści byli bardziej realistyczni w zakresie szacunków - pracowałem nad zespołem, który nie zamknął sprintu przez rok (konsekwentnie zamykając mniej niż 50% sprintu) , zawsze niedoceniany i przy każdym planowaniu / retrospektywie byłem samotnym głosem, który mówił im, że twoje szacunki są do kitu, jesteś głupio zbyt pewny siebie, przestań usprawiedliwiać się tym, co uniemożliwiło ci dokonanie oszacowania, a zamiast tego dostosuj oszacowanie, aby odzwierciedlało rzeczywistość ( być może bardziej dyplomatycznie niż to, ale to był podstawowy sentyment) - Gdy zajmujesz taką pozycję, w pełni zgodziłbym się z szefem zespołu, który twierdzi, że proces ten jest stratą czasu, ponieważ w rzeczywistości robisz KonBon, niezależnie od jak to nazywasz. W pewnym momencie jego opinia zostaje potwierdzona przez okoliczności. To'

W pewnym momencie musisz zresetować rzeczy, musisz zmusić zespół do drastycznego zrekompensowania swoich szacunków, aby uruchomić system. Gdy zespół zacznie konsekwentnie zamykać historie, powinien zdać sobie sprawę, że proces zwinności jest głównie zdrowy rozsądek, a brak jego realizacji w jakiś sposób jest szkodliwy dla wydajności. Ale tak długo, jak „zaangażowanie” i „cele sprintu” nie są traktowane poważnie, co dzieje się, gdy nie są konsekwentnie osiągane, to wszystko jest fikcją i zmniejsza wydajność zespołu.

Trudno jest skłonić ludzi do zakupu na znacznie innym sprincie (pod względem szacunków, planowania, zaangażowania). W tym zespole ostatecznie to osiągnąłem z dwóch powodów. Jeden z nich po prostu zbierał dane z JIRA i powiedział: „nie ma na to usprawiedliwienia, liczby są dalekie, zawsze są wyłączone w jednym kierunku, musimy to poprawić, nie chcę wymówek w stylu retro, chcę liczby do zsumowania ”- a drugą była presja ze strony wyższej kadry kierowniczej, którą ostatecznie im wytłumaczyłem, jak…„ Celem tego procesu jest uczynienie naszej osi czasu rozwoju przewidywalną. Jeśli wykonamy stałą ilość pracy co Sprint jest w porządku, niezależnie od tego, nasza tablica musi dokładnie odzwierciedlać to, co robimy. Kierownictwo jest bardziej świadome naszego sukcesu w stosunku do zaangażowania niż do naszej rzeczywistej produkcji, dla własnego dobra, dostosuj projekcję do wyników, aby wyglądało na to, że wykonujesz swoją pracę, a nie spędzasz połowę każdego sprintu nic nie robić. Im bardziej ludzie są usunięci z tego czasu, tym bardziej widzą, że zawodzisz, wymówki, które robisz w stylu retro, nie są nawet czymś w ich zasięgu, po prostu widzą, że zawodzisz. ”

W końcu nasz zespół zyskał przyczepność i wszystko zaczęło działać płynniej i nisko, a oto zaczęliśmy nawet osiągać wyższą wydajność, gdy proces faktycznie zaczął działać. Więc tl; dr - rób wszystko, co jest konieczne, aby rozpocząć sprinty z relatywnie dużym powodzeniem. Jeśli tego nie zrobisz, curmudgeon w twoim zespole będzie nadal potwierdzał swoją odporność na Scruma i ostatecznie będzie miał rację, że twój proces jest w rzeczywistości oszustwem i stratą czasu każdego.

Jako Scrum Master trenujesz i prowadzisz zespół, aby stał się bardziej produktywny. Scrum Scrum to potężne narzędzie, aby się tam dostać, ale Scrum absolutnie nigdy nie może sam stać się celem - w przeciwnym razie wykonujesz Kult Cargo .

Wygląda na to, że uprawiasz Cargo Cult od 3 lat i ludzie zdali sobie sprawę, że to okropna metodologia zarządzania projektami. Dobrą wiadomością jest to, że masz mądrych ludzi , oni mają rację. Niestety, niektórzy ludzie w twojej firmie nazywają to Scrum, ale znowu masz inteligentnych ludzi , nawet powiedzieli ci, że to, co robi zespół, nie nazywa się Scrum.

Planowanie to tylko strata czasu, ponieważ po prostu przenosimy przepełnienie do nowego Sprint i i tak nie kończymy pracy, więc po co się tym przejmować.

Dokładnie. Po co się męczyć? Musisz znaleźć odpowiedź, a raczej musisz zmienić planowanie i sam sprint, więc jest sens planowania. Albo to, albo przestań marnować czas wszystkim bezcelowym planowaniem sprintu. Możesz poprosić firmę o wysłanie cię na szkolenie Scrum Master, ponieważ przeprowadzenie doskonałego planowania sprintu nie jest trywialne.

Podczas Retrospektywy [...] inni milczą i za każdym razem muszę sobie z tym poradzić.

Jeśli masz do czynienia z tym samym problemem przy każdej Retrospektywie, ludzie nawet nie zawracają sobie głowy (już?) Mówieniem podczas Retrospektywy, to tylko strata czasu. O ile Ty lub zespół nie potraficie w jakiś sposób rozwiązać problemów poruszonych w Retrospektywie, spotkanie jest po prostu demoralizujące zespół. Problemy poruszone w Retrospektywie muszą zostać rozwiązane, a następna Retrospektywa powinna poczynić postępy.

Daily Scrum jest dla nich po prostu stratą czasu, ponieważ żaden z nich nie zawraca sobie głowy rozmową i planowaniem dnia. Po prostu stwierdzają: „Pracowałem wczoraj nad zadaniem X i nad tym dzisiaj popracuję”.

Rzeczywiście, po co marnować czas wszystkim, jeśli pracują nad tymi samymi zadaniami przez wiele dni? Mają absolutną rację, że Daily Standup jest rzeczywiście bezcelowy. Standup ułatwia ścisłą współpracę przy wielu zadaniach, z których każde można wykonać w ciągu pół dnia lub krócej. Jeśli twoich zadań nie da się rozbić w ten sposób (z powodu zepsutego planowania sprintu lub ponieważ twoje zadania faktycznie nie pasują do Scruma), nie ma sensu organizować 5-minutowego codziennego spotkania w trybie standup (jest to nie dłużej niż 5 minut, prawda?).

„Nigdy nie kończymy Sprintu. Po prostu wykonujemy zadania i przyjmujemy nowe w następnym Sprint, aby wypełnić limit. Wykonujemy KanBan w rzeczywistości. Więc przestań o tym mówić”.

Rozumiem, dlaczego to mówi, ale nie zdaje sobie sprawy, że tak właśnie jest, ponieważ on i wszyscy inni w zespole nie dbają o to.

Nie, absolutnie nie rozumiesz, dlaczego on to mówi . Masz podstawową przyczynę przeszkody - którą musisz rozwiązać - źle. Nie obchodzi ich to, ponieważ praktyki zarządzania projektem zespołu są do kitu. Dbanie o uprawianie Cargo Cult i cięższe uprawianie Cargo Cult nie powstrzymuje go od bycia Cargo Cult, jedną z najgorszych istniejących metod zarządzania projektami (w twojej obronie: również najczęściej stosowaną).

Co możesz z tym zrobić?

1. Posłuchaj ich obaw. Ponownie jesteście pobłogosławieni tym , że macie mądrych ludzi .

2. Pomóż im rozwiązać przeszkody.

I to wszystko, naprawdę. Musisz eksperymentować z tym, jak zmienić Planowanie Sprintu, Codzienny Scrum i Retrospektywy, aby uczynić je wartościowymi dla zespołu - nawet jeśli chcesz porzucić etykietę Scrum, nadal masz te 3 spotkania o podobnej częstotliwości i podobnym celu w każdym innym metodologia zarządzania projektami tam. Co do tego, jak zamierzasz eksperymentować (częstotliwość, treść, kto jest gospodarzem spotkania, czas, czas trwania itp.), To zaskakująco łatwe: Zapytaj zespół. Nie narzucaj im swoich pomysłów, jeśli powinieneś pozwolić im narzucać ci swoje pomysły (zakładając, że mogą się zgodzić na niektóre).

Jeśli boisz się, że stracisz kontrolę, ustaw wcześniej pewne granice, np .:

• Etykiety spotkań pozostają takie same.
• Spotkania nadal się odbywają, a ich częstotliwość nie może się zmienić więcej niż 2-krotnie.
• Aktualnie eksperymentujesz, więc każda zmiana trwa tylko 2 sprinty, po czym powracasz do starego wzorca (najlepiej daj czas w tygodniach, aby uniknąć dwuznaczności, gdy chcą podwoić czas trwania sprintu).

Myślę, że wszyscy cytują tę samą linię z Agile Manifesto . Zrobię to samo: „Osoby i interakcje dotyczące procesów i narzędzi”.

Jeśli jako mistrz SCRUM chcesz następnie użyć SCRUM do wykonania zadania, musisz podejść do nich jako jedna osoba wchodząca w interakcję z drugą. Rozpocznij burzę mózgów, jak ulepszyć ten proces. Może uda ci się przekonać ich do polubienia SCRUM. Może przekonają cię do zastosowania innego procesu. Dowiedzmy Się!

Wygląda na to, że zespół już rozpoznał, że obecny system nie wykonuje pracy. Czy możesz zachęcić ich, by wierzyli, że da radę? Podajesz kilka przykładów. Jeśli przepełniasz Sprint, aby zawsze przeciekał ... przestań. To twój zespół SCRUM. Pomóż im przestać nadmiernie się angażować. Odepchnij zarządzanie, aby uzyskać trochę oddechu. Użyj SCRUM do tego, do czego jest dobre. Skorzystaj z niego, aby przedstawić kierownictwu dane, które pchają na tyle mocno, że tracą wartość ze swojego procesu. Jeśli zarząd chce SCRUM jako procesu, poproś go, aby pomógł zbudować przestrzeń i energię potrzebną do naprawy. Jako mistrz SCRUM Twoim zadaniem jest rozwiązywanie problemów, aby zespół mógł być produktywny.

Innym przydatnym podejściem może być odrodzenie nowego procesu w starym. Kontynuuj uruchamianie SCRUM w ten sam bezużyteczny sposób, ale odłóż małą część harmonogramu i powiedz „w tej części naszego harmonogramu wymyślimy, jak prawidłowo korzystać z narzędzi”. Nie przesadzaj. Użyj swoich danych. Skoncentruj się na wszystkich swoich spotkaniach. Pozostała część twojego projektu „SCRUM” jako tarczy, aby utrzymać zadowolenie kierownictwa, podczas gdy ty i twój zespół „[odkrywaj] lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym”. Z czasem będziesz chciał umieszczać coraz więcej swoich cennych zadań w tym wiadrze, a stare wiadro będzie powoli umierać. Wkrótce masz żywe środowisko programistyczne i nikt nie jest mądrzejszy.

Lub wymieszaj i dopasuj je. Pracowałem nad programem, który był anty-scrum. Klienci chcieli mieć możliwość dodawania nowych zadań w dowolnym momencie procesu i umożliwić nam natychmiastowe działanie. (To była właściwie rozsądna prośba: ich praca była bardzo niestabilna i często potrzebowali szybkiego wsparcia ... za to nam zapłacono). Oczywiście musieliśmy wymyślić, jak poradzić sobie z problemami „dlaczego X nie jest zrobione, kiedy obiecałeś to podczas sprintu”. Nasze rozwiązanie polegało na zbudowaniu dwuetapowego procesu. Zadania długoterminowe zostały wprowadzone do SCRUM w celu właściwego ustalenia priorytetów. Krótkoterminowe zadania zostały wprowadzone w domowy proces, który koncentrował się na ścisłej interakcji między klientem a deweloperem. Zrozumiano, że klienci mogli naciskać na nas przy użyciu tego krótkoterminowego procesu, ale zrozumieli, że w ten sposób wpłynęło na Sprint Oś czasu i zabroniono im dodawać żądania bez jednoczesnego wysłuchania i rozwiązania problemów z harmonogramem, które spowodowali. Wynik? Zadziałało. Większość zadań została umieszczona w procesie SCRUM, tak jak powinny, a sytuacje kryzysowe współdziałały z nimi płynnie. Podejście brzmiało: „Jeśli chcesz być klientem, stań w kolejce do historii SCRUM. Jeśli chcesz zostać partnerem, możesz zejść i współpracować z nami na co dzień i sprawić, by ten produkt działał ! ”

Mówię to, bo naprawdę wiem. Masz problem z wyższym kierownictwem z przekroczeniem harmonogramu, niezdolnością do ustawienia priorytetów i chęcią dodawania kolejnych elementów, ale nie wypychania dat wydania.

Kiedyś mówiłem, że nie ma metodologii, która mogłaby tak funkcjonować, ale teraz, kiedy widziałem Kanban, mówię, że tak, ale tylko dlatego, że Kanban nie musi się tym przejmować. Nadal działa, gdy jest nadmiernie zaangażowany. To nie przyniesie rezultatów szybciej, ale tworzenie kopii zapasowych w kolejkach nie jest możliwe dla żadnej osoby, więc problem zarządzania leży po stronie zarządzania. Raporty zwrotne pokazują przeciążenie, co jest poprawne.

Z powodu tej zmiany w Scrum Masters i ich sposobie prowadzenia serialu

No cóż, to może być twój problem. Mistrza Scruma nie ma na miejscu, żeby poprowadzić przedstawienie, nie jest liderem projektu. Jest tam, aby upewnić się, że wszystkie zainteresowane strony komunikują się, a operacja jest przejrzysta.

Zastanawiam się, skąd pochodzi drużyna. Czy to możliwe, że byli mniej lub bardziej autonomiczni, zanim Scrum (w tym nieunikniony mistrz Scrum) został na nich zrzucony? Dlaczego Scrum został wprowadzony w pierwszej kolejności? Co miał rozwiązać?

Scrum powinien zapewniać wskazówki, a Twój zespół wyjaśnia, że ​​nie uważają go za pomocny w jakikolwiek sposób. Nie dbają o wskazówki, uważają za niewłaściwe marnowanie czasu. Najwyraźniej przynajmniej jeden decydent uważa, że ​​i tak trzeba się nimi kierować. Kto? Dlaczego? Czy mają rację?

Jest to problem nie ograniczający się do oprogramowania.

W każdym środowisku pracy będą różne osoby o różnych osobowościach i umiejętnościach. Nawet gdyby Scrum był idealną metodą, nadal byliby przeciwko temu ludzie ze względu na ich osobowości i umiejętności.

Programiści radzą sobie z trudnymi zadaniami w racjonalny sposób. Aby to zrobić, każdy programista będzie miał sposób radzić sobie z takimi rzeczami, które mogą okazać się niechęcią do takich rzeczy jak Scrum. Jeśli wszyscy programiści zostali przeszkoleni od zera dokładnie w ten sam sposób, może być znacznie łatwiej korzystać z jednego wzorca, ale w przeciwnym razie konieczna jest adaptacja po stronie programisty lub zarządzania.

Ponadto niezależni myśliciele (programiści i inni specjaliści) często nie lubią, gdy mówi się im, jak to robić, ponieważ taka jest ich praca i łatwo jest się zdarzyć, że dojdzie do starć. Scrum może wydawać się bezsensownym rytuałem dla logicznego myśliciela, który zwykle analizowałby i postępował zgodnie z każdym z omawianych problemów.

Poniżej wydaje się sugerować, gdzie jest problem, ale nie w czym on jest. Jest zdecydowanie więcej niż to. Mogę tylko założyć (z doświadczenia), że programiści próbowali, ale im zapobiegło. Widziałem to wiele razy, gdy programiści chcą coś naprawić, ale coś systematycznego (zarządzanie, polityka firmy itp.) Sprawia, że ​​jest to prawie niemożliwe, więc się poddają. Czy naprawdę ich to nie obchodzi, czy nie zależy im tylko na robieniu czegoś, co ich zdaniem nie pomoże (być może z doświadczenia).

Rozumiem, dlaczego to mówi, ale nie zdaje sobie sprawy, że tak właśnie jest, ponieważ on i wszyscy inni w zespole nie dbają o to. Po prostu wykonują pracę zamiast radzić sobie z przeszkodami. Skarżą się na przeszkody, ale nic z nimi nie robią. A kiedy próbuję pomóc, po prostu wzruszają ramionami.

Cholernie to obchodzili, ale w ciągu ostatnich dwóch lat ich gotowość spadła do mniej więcej dna.

Jak sprawić, by zobaczyli, że żartowanie i szarpanie kół podczas tych spotkań kosztuje firmę dużo pieniędzy?

Jeśli coś zostanie narzucone innym ludziom, to od nich zależy, czy uda im się przekonać ich o korzyściach. Chociaż tak naprawdę nie wierzę w zmuszanie ludzi do robienia rzeczy, sugeruję jak w każdej sytuacji, słuchać wszystkich i opracować metodę, która działa w obecnym środowisku.

Scrum nie jest pozbawiony swoich słabości. Oczywiście mogę mówić za siebie, ale myślę, że deweloperzy nie znoszą tego bez powodu . Moim szczerym zdaniem nie wolno próbować .

Aby zrozumieć, dlaczego, przeczytaj, co każdy mistrz scrum powinien wiedzieć o scrum . To nie jest napisane przeze mnie, ale wszystko, co tam jest, jest reprezentatywne dla mojego doświadczenia, które mogę podsumować jako zwykły terror .

W moim przypadku szczególnie cierpiałem na podstawie punktu 5. Zasadniczo scrum traktował mnie jak dziecko i nieudacznik. Teraz jestem pomysłowym współtwórcą, który pomaga moim kolegom… nic dziwnego, co wolałbym!

Mam teraz nowego szefa (nie-scrum), który po prostu chodzi i rozmawia z ludźmi, i jestem za to bardzo wdzięczny ! Częściowo dlatego, że to działa, mamy również pokój rozmów (używamy materii) do komunikacji między programistami. Jeśli ktoś ma plan, zabieramy go tam. Spotkania służą wyłącznie do dyskusji deweloperów ad hoc, a nie do narzucania sobie sztucznych codziennych terminów.

Otrzymałeś wiele doskonałych odpowiedzi. Oto kilka dodatkowych punktów, które mogą być pomocne:

Zmiana metodologii jest trudna

Jest to ogromne wyzwanie w obszarze roboczym, ponieważ pracujesz pod wpływem bezwładności „tak robimy rzeczy” i pod presją terminów i potrzeb biznesowych.

Masz całkowitą rację, stwierdzając, że Twój zespół musi poświęcić więcej czasu na planowanie, a nie mniej ; że planowanie jest czymś, co obecnie nie jest świetne i wymaga poprawy. Problem polega na tym, że nie dotrzesz tam po prostu narzucając nowe zasady. Nowe zasady stanowią nowe obciążenie, zanim staną się dużą pomocą. A jeśli nie przyniosą natychmiast dużej wartości , dostaniesz raczej unikanie niż współpracę.

Bardzo polecam Roy Osherove na ten temat. Ma krótkie podsumowanie tego, jak planować i wprowadzać zmiany w Twojej firmie , i porusza ten temat znacznie głębiej w tym filmie .

Podstawową obserwacją Osherove jest to, że należy spełnić wszystkie następujące wyzwania:

Motywacja osobista: dlaczego ktoś powinien się zachowywać w określony sposób?
Zdolność osobista: czy mogą to zrobić dosłownie?
Motywacja społeczna: czy istnieje presja ze strony rówieśników na takie zachowanie?
Zdolność społeczna: czy ludzie wokół mnie wspierają moje zachowanie i pomagają mi z tym, kiedy potrzebuję pomocy?
Motywacja strukturalna: Czy istnieją nagrody \ kary za dobre \ złe zachowanie?
Zdolność strukturalna: czy środowisko fizyczne wspiera to zachowanie?

Musisz nauczyć się rozbijać zadania

Wasz zespół uważa, że ​​„pracowałem wczoraj nad zadaniem X i nad tym popracuję ponownie dzisiaj” i wydają się mieć rację w tym sensie, że zadania są cofane o tydzień.

Naprawdę pomocna jest tutaj nauka dzielenia zadań na małe elementy. To, czego szukasz, to odpowiedź na pytanie „OK, pracujesz nad zadaniem X, ale co konkretnie nad zadaniem X dzisiaj pracujesz ?”

Niektóre odpowiedzi mogą być:

• Uczę się tej klasy starszego kodu.
• Naprawiam błąd, którego symptomy to (OBJAWY).
  • Jeśli jest to jakiś ciągły błąd, który zajmuje trochę czasu: „Dzisiaj spróbuję ... (PLAN)”
• Muszę zmienić ten interfejs.
• Piszę testy.
• Integruję nieprzetestowany kod.

... i tak dalej i tak dalej. Możliwość obserwowania tego, co można zrobić w ciągu dnia lub tygodnia, jest jedną z wielkich zalet Agile. Ale to oznacza, że ​​musisz spojrzeć na rozdzielczość poszczególnych dni, a nie na monolityczne zadanie X, które będzie gotowe, gdy tylko będzie gotowe.

Gotowe vs. Dostarczone

Jednym z powszechnych problemów (z Agile i ogólnie planowaniem miejsc pracy) jest to, że terminy zwykle pochodzą od kierownictwa, a nie od programistów. Ten termin może być oddzielony od faktycznej pracy, która ma zostać wykonana - a szczególnie może wymagać dostarczenia rzeczy tak szybko, jak to możliwe.

Problem polega na tym, że „jak najszybciej” to bardzo chaotyczny proces. Zachęca do pokonywania zakrętów; kodowanie „szybkie i brudne”; ignorowanie wytycznych; nie sprzątać po sobie. Zachęca do myślenia: „spróbuj, sprawdź, czy to działa. Jeśli tak, dostarcz. Jeśli nie, spróbuj czegoś innego” - i tak sformułowane, możesz zobaczyć, dlaczego nikt nie jest w stanie przewidzieć, jak długo to zajmie.

Natomiast jeśli są pracy metodycznie, jeśli jesteś o planowaniu i rygorystyczne testy i tak dalej, a następnie skonfigurowaniu kilka drogowskazów i siatek bezpieczeństwa. Może to potrwać dłużej - poświęcasz dużo czasu na rzeczy, które nie sprzyjają natychmiastowej dostawie, i możesz po prostu nie być jeszcze zbyt dobry w tego rodzaju przepływie pracy - ale będzie znacznie mniej niestabilny.

Pytanie, które należy sobie zadać, brzmi: czy programiści ustalają cele sprintu zgodnie z potrzebami i potrzebami, które faktycznie widzą? A może kierownictwo wyznacza terminy, pozostawiając programistom próbę rozłożenia swoich zobowiązań na harmonogram podobny do sprintu?

Jeśli programiści nie mają czasu na zaplanowanie rzeczy lub pracę zgodnie z niezawodnym planem, nic dziwnego, że nie są w stanie dokonać przydatnych oszacowań. :)

To może być niepopularna opinia, ale możesz nie być w stanie nic z tym zrobić.

Mogę sobie wyobrazić, że przez lata istnienia zespołu i fluktuacji liderów odeszli ludzie naprawdę niezadowoleni z zespołu. To, co masz, to pozostałości po ludziach, którzy mogą narzekać, ale nie są zainteresowani podjęciem wysiłków w celu poprawy sytuacji. Chcą po prostu spędzić 8 godzin na hakowaniu kodu, nie przerywanym przez nikogo i po prostu wracać do domu pod koniec dnia. To, co tu masz, wydaje się być poważnym problemem motywacyjnym. Rozwiązaniem tego problemu nie jest scrum master. Problemem jest to, kto płaci tym ludziom.

Jeśli tak naprawdę jest, to jedyną realną opcją jest pozbycie się obecnego zespołu i rozpoczęcie od nowa. Może zostawić jedną lub dwie osoby, które według ciebie są najlepsze w zespole i albo zwolnić, albo przenieść resztę do różnych zespołów. Powinieneś przynajmniej omówić tę możliwość ze swoimi przełożonymi.