Sceptyczny w zespole Scrumowym

Moja firma niedawno przeszła na zwinny sposób pracy i w ramach tego zaczęliśmy używać SCRUM. Chociaż czuję się z tym bardzo dobrze i czuję, że ta metoda jest lepsza od tradycyjnej, niektórzy z moich kolegów z drużyny nie podzielają tego samego zdania. W rzeczywistości są bardzo sceptycznie nastawieni do „tych wszystkich zwinnych rzeczy” i nie traktują tego poważnie. Na przykład jeden z członków zespołu zawsze spóźnia się na spotkanie i tak naprawdę nie obchodzi go to. Zarząd IMO stara się tego nie zauważać (może dlatego, że jest nowy, a ludzie przyzwyczajają się do tego).

Moje pytanie brzmi: jak rozwiązać ten problem, nie podnosząc konfliktu w zespole?

W obliczu ekstremalnego sceptycyzmu próbuję kilku rzeczy:

1.) Ja zademonstrować techniki, takie jak TDD, Ciągły wdrażania, programowanie Pair, Wymagania Gathering ze swoimi użytkownikami, krótkie iteracje itp I nie nazywają tych technik Agile lub ględzić o Agile Manifesto (robię harfę na temat oprogramowania rzemiosła - ale to jest inne; p). Po prostu pokazuję członkom zespołu przydatne narzędzia i techniki, które ułatwiają ich życie. Mają tendencję do wskakiwania na agile, gdy widzą korzyści z dnia na dzień.

2.) Nie zmieniam od razu na pełną metodologię SCRUM (lub inną). Zawsze najlepiej jest wprowadzać małe aspekty Agile na raz.

3.) Zgadzam się ze sceptykami (do pewnego stopnia). Agile nie jest srebrną kulą, a SCRUM, Kanban, Lean itp. Również nie są srebrną kulą. Zamiast tego współpracuję z nimi, aby zobaczyć, jakie aspekty mogą odnieść z nich natychmiastowe korzyści (serwer CI zwykle nie wymaga myślenia), a następnie wypróbowuję resztę „Pozwól, aby odstawić stand-upy na tydzień, a następnie przejrzyj”.

Jak każda metodologia, SCRUM i inni muszą faktycznie współpracować z zespołem i organizacją, a nie wyobcować ich.

Aby przejść bezpośrednio do pytania. Podnieś to razem z zespołem:

„Jestem również trochę sceptyczny wobec stand-upów, ale myślę, że jako zespół powinniśmy dać temu dobry start przez 1 tydzień (bez wymówek!), A następnie przejrzeć go, aby sprawdzić, czy to dla nas zadziałało. Co ludzie myśleć?"

Typowy przypadek źle zaimplementowanego Scruma .

Scrum został narzucony zespołowi. (Cały) zespół tego nie wybrał.

Kiedy chcesz go wdrożyć, musisz mieć pełne wsparcie zarówno zespołu, jak i kierownictwa, w przeciwnym razie to nie zadziała.

Odporność na zmiany jest tutaj twoim wrogiem.

Gorąco sugeruję, aby zacząć od nowa i przedstawić Scrum zespołowi i pozwolić mu zadawać pytania.

Jeśli nie uda Ci się sprzedać pomysłu, nie próbuj narzucać go metodami, których nie chcą. Zrobią wszystko, aby to sabotować. Spóźnianie się na codzienne wstawanie jest jednym z takich zachowań.

Pamiętaj, że Scrum może nie być wskazany dla Twojej firmy. Jedynymi osobami, które mogą odpowiedzieć na to pytanie, są ludzie pracujący w bazie. Zespół .

Może się zdarzyć, że koncepcja codziennych spotkań nie stosuje się zbyt dobrze do tego, co robi osoba. Spotkania te nie są bezpłatne.

Jeśli to, co robisz, wymaga długofalowej koncentracji, takiej jak ciężka matematyka, spotkania mogą cię wykończyć i być frustrujące. Pracuję z kimś takim, który woli spotykać się co tydzień, co jest całkowicie rozsądne.

Szczerze mówiąc, gdybym był w zespole programistycznym, prawdopodobnie byłbym tak sceptyczny! Widziałem długą linię metodologii, które miały zrewolucjonizować rzeczy i sprawić, że projekty przyjdą na czas, w ramach budżetu i będą wolne od błędów. To tylko najnowsza wersja. Dlaczego mam wierzyć olejkowi węża? 10 lat temu ci sami ludzie chłostali coś innego, za kilka lat pojawi się coś nowego. Nie zrozumcie mnie źle. Myślę, że niektóre z nowych metodologii przynoszą użyteczne pomysły. Niestety przynoszą wiele dogmatów i głupich pomysłów.

Czy to naprawdę ma znaczenie, jeśli nie wsiądzie na pokład? Po prostu przydziel mu kilka zadań programistycznych i pozwól mu to robić tak, jak chce. Jeśli jego praca jest zadowalająca, niech będzie. Jeśli jego praca nie jest satysfakcjonująca, zastąp go. Dlaczego tak ważne jest, aby ludzie podążali za scrumem?

Przez lata widziałem, jak wielu dobrych programistów rezygnuje lub denerwuje się, ponieważ ich menedżer ciągle wprowadza nowe metodologie. Chcą tylko napisać kod i wykonać zadanie. Zaufaj mi za kilka lat, będziesz przeklinał scrum i skakał na najnowszą modę.

Jeśli pracujesz zwinnie, powinieneś mieć zaległości, z których pracujesz. Użyj scrum, aby rozdawać zadania z zaległości.

Wybrane (najlepsze) zadania są wybierane najpierw na początku spotkania. Kiedy spóźnisz się, przybysz, po prostu daj mu to, co zostało na dzień.

Nie ma znaczenia, czy jest darem Boga w programowaniu, dostaje badziewne zadanie, którego nikt inny nie chciał. Jeśli próbuje wykonać inne zadanie lub pracować nad czymś innym, zespół jako całość musi się na nim oprzeć i zmusić go do pracy tylko przy „wybranym” zadaniu. Prawdopodobnie powinieneś mieć mistrza kompilacji, który może odrzucić jego zmiany, jeśli nie pracuje nad wybraną pracą.

Zespół powinien również wyznaczać cele i potencjalnie wynagradzać. Możesz głosować jako zespół, aby nie nagradzać tych, którzy nie biorą udziału. Zależy to od poziomu własności, jaki kierownictwo przekazało zespołowi zwinnemu. Przypomnij kierownictwo tym, którzy ranią zespół i uniemożliwiają mu sukces.

Przypomnij mu, że jeśli pojawi się na czas, może wziąć udział w tym procesie.

Zespoły Scrumowe powinny się samoorganizować. Scrum działa również poprzez wdrożenie ekstremalnej przejrzystości we wszystkim.

Oczywistą odpowiedzią jest to, że Scrum Master zwołuje spotkanie, wyjaśnia problem (ale nie oszukuj się, wszyscy w zespole już dokładnie wiedzą, na czym polega problem), a następnie mówi im, że mają 1 godzinę, aby dowiedzieć się, co to jest zamierzają to zrobić. Potem siada w kącie i nie odzywa się.

Oczywiście jest to zespół nowy w Scrumie. Kluczem jest więc to, że Scrum Master musi zaakceptować każdą odpowiedź, którą wymyśli zespół. Jeśli je unieważni lub narzuci swoje własne pomysły na rozwiązanie, zniszczy zaufanie, które zespół musi zbudować z nim, że mogą się samoorganizować. Możliwe, że zespół zdecyduje się nic nie robić.

W każdym razie problem powinien zostać przeanalizowany w Retrospektywie Sprint, a skuteczność dowolnego rozwiązania, które wymyślono, może zostać omówiona.

Unikanie „konfliktu drużynowego” wcale nie powinno być czynnikiem.

Zwolnij kolegę z drużyny, wtedy nie wywoła kontrowersji w zespole.

Przejrzyj swoją starszą pracę, wykop wiele przykładów, w jaki sposób podejście polegające na wodospadzie zawodziło Cię wiele razy w przeszłości. Następnie przedstaw skrzynie swojemu koledze z zespołu. Z błyskiem zdrowego rozsądku ujrzy światło.

Programowanie jest działaniem precyzyjnym, więc rzadka osoba nie byłaby wrażliwa na twarde fakty. Przynajmniej teoretycznie.

Kto podjął decyzję o zmianie i dlaczego? Gdzie w ogóle byli sceptycy co do decyzji, czy decyzja została właśnie na nich rzucona?

Czy jesteś zbyt sztywny i / lub szybki we wdrażaniu nowych metod? Czy wypuściłeś dobre (niekoniecznie idealne) produkty, stosując swoje stare metody? Czy pokazałeś sceptykom, w jaki sposób przyniesie im to korzyść? Czy możesz to zademonstrować? Czy osoby, które „widziały światło”, pokazały sceptykom, w jaki sposób przynoszą one korzyści im, zespołowi i firmie?

Prawdopodobnie prosisz ich, aby zaakceptowali wszystko tylko słowami wierzących. Bardziej niż prawdopodobne, że sceptycy przyjęli wcześniej nowe metodologie i nie przyniosły żadnych korzyści, o ile kiedykolwiek zostały zrealizowane.

Może mógłbyś wykonać projekt lub dwa z udziałem tylko wierzących pracujących nad nim przy użyciu nowych procedur. Wykonaj prawdziwe pomiary i pokaż sceptykom prawdziwe korzyści. Może nawet stworzą małą konkurencję między sceptykami i ich starymi obyczajami, a wierzącymi i nowymi obyczajami.

Oczywiście, co robisz, jeśli sceptycy wygrywają?

Spotkaj się z zespołem, aby omówić i dowiedzieć się, dlaczego Twoja firma przeniosła się na SCRUM, i przekonać wszystkich, co sądzą o SCRUM, by zwiększyć wartość obecnego trybu działania. Czasami firmy robią kościste przełączniki (byłem na scrumowych spotkaniach, na których nikt tak naprawdę nie słucha, a wszyscy po prostu grzechotają to, co zrobili wczoraj i odchodzą. Te zespoły zwykle osiągają równowagę w stylu - „Nie będę cię przesłuchiwał, a ty nie zadzierasz” ze mną ”i chodź tam. To tylko strata czasu), więc weź co dla ciebie najlepsze.

Weterani zwykle mają dużą odporność na wszystko, co może zmienić ich obecny styl pracy, więc musisz upewnić się, że jest wystarczająco dużo marchewek, aby mogli zejść z bezwładności. W takim przypadku miałbym albo 1: 1 z tą osobą, albo uczynię go mistrzem scrum :). Gdy powierzysz im odpowiedzialność, znajdą pokój z nim lub całkowicie go zlikwidują, ponieważ nie stanowi to wartości dodanej. Oba są wygrane wygrać.