Scrum: radzenie sobie z brakiem motywacji

Zgodnie z tym , „Scrum opiera się na wysoce zmotywowanych, ściśle współpracujących, wielofunkcyjnych i samoorganizujących się zespołach”. Jak zatem radzić sobie ze współpracownikami, którzy mogą nie być tak zmotywowani do przejęcia na własność kodu? Jak zdobyć kogoś zainteresowanego przejęciem własności?

Nie wiem, czy to jest problem twojego zespołu, ale na pewno było to dla nas, kiedy wprowadziliśmy scrum. Nasze kierownictwo przyszło do nas pewnego dnia i powiedział: od tej pory nie będziecie pracować w pojedynczych silosach. Zamiast tego będziesz pracował jako scrum. Oto kilka nowych procesów, które wszyscy musicie śledzić i postępować zgodnie z nimi.

Kluczem jest to, że nigdy nie przyszli do nas, programistów, i zapytali, jak wy chcecie pracować? co sprawi, że będziesz szczęśliwszy bardziej wydajny?. Usłyszałem więc: „nie masz już żadnego kodu. Wszystko, co napiszesz, zostanie zdeptane (wiesz, własność zespołu). Nie poruszysz ani nie podniesiesz palca, ponieważ teraz będziemy zarządzać twoim czasem z godziny”. Aha, a teraz masz nudną 15-minutową interwencję codzienną, podczas której ludzie będą dyskutować o sprawach, na których ci nie zależy, a zwykle zajmie to 30 minut, a następnie co dwa tygodnie będzie nudne 4-godzinne spotkanie planistyczne, które z pewnością będzie do kitu całe życie z ciebie.

W rzeczywistości nie jest to Agile ani Scrum, to tylko przejście od jednego stylu zarządzania do innego stylu, w którym wszystko jest nadal centralnie kontrolowane, i to nie tylko wyssało ze mnie całe życie, ale także dało mi wiele darmowych czas zaktualizować moje CV.

W ciągu ostatnich dwunastu miesięcy, po tym jak wiele razy lobbowałem za kierownictwem naszego zespołu, aby spróbować czegoś innego, faktycznie podjął mnie moich sugestii i myślę, że mieliśmy bardzo udany rok.

Uważam, że kluczową zmianą dla nas było zapewnienie programistom znacznie większego głosu i swobody w wyborze sposobu pracy. Kilka rzeczy, które zrobiliśmy:

1. Podziel duży „zwinny” zespół programistów na 3 małe, aby każdy miał tylko 3-4 programistów. To sprawia, że ​​wszyscy są zaangażowani, a jednostki nie są zagłuszone.
2. Upewnij się, że wszyscy w tym samym zespole pracują w tym samym obszarze funkcjonalnym, aby ludzie dbali o to, o czym mówią inni w standupach i planach iteracji.
3. Zamiast zarządzania po prostu wybrania, kto nad czym pracuje i przypisywania historii / zadań, wpadliśmy na zaległości, a sam zespół miał wiele do powiedzenia na temat podziału pracy.
4. Ponieważ mieliśmy wielu nowych członków, zaczęliśmy od systemu silosów, w którym każda osoba ma główny zakres odpowiedzialności. Umożliwiło to nowym osobom skupienie się na mniejszym obszarze nieznanego produktu, a także szybsze odczucie, że nie grają w cudzej piaskownicy. Ale 6-8 miesięcy po rozpoczęciu programu obszary te zaczęły się zmieniać, gdy granice stały się bardziej szare. Teraz faceci w zespołach, w których pracuję, są dość swobodnie wchodzący w kod innych lub zatrudniający innych programistów.
5. Kluczowe były recenzje kodu wszystkich zgłoszeń (i to była pierwsza rzecz, o której wspomnieliśmy, kiedy tworzyliśmy Scrum):
   • Transfer wiedzy w zakresie technik / metod programowania
   • Był świetny dla innych do nauki kodu, którego inaczej by nie widzieli
   • Twój zespół ma szansę na komunikację i kontakty towarzyskie, co poprawia dynamikę zespołu
   • I przypuszczam, że recenzje kodu wychwycą błąd lub dwa, ale ich wartość widzę głównie w powyższych aspektach.
6. Kierownictwo musi słuchać zespołu. Jeśli zespół mówi, że coś nie działa lub musi zostać zmieniony, i po prostu to ignoruje, wówczas członkowie zespołu po prostu sprawdzą i pozwolą kierownictwu zająć się projektem. Jeśli chcesz, aby ludzie byli zmotywowani, należy je nabyć, a otrzymają je tylko wtedy, gdy robią to, co uważają za słuszne, a nie to, co każą im robić z góry.

Istnieje wiele powodów braku motywacji, ale prawdopodobnie najczęstszym jest brak poczucia, że ​​masz coś do powiedzenia. Kiedy nasz zespół zaczął robić scrum, zauważyłem, że najmniej zmotywowani ludzie o scrum odwrócili się po tym, jak zobaczyli, że ich sugestie z retrospekcji zostały wdrożone.

Kilka drobnych problemów może być demotywujących. Na przykład jedną rzeczą, która pojawiła się w zeszłym tygodniu, był członek zespołu, który nie lubił spotkań o 4:00. Łatwo to naprawić.

Innymi słowy, najlepszym sposobem, aby dowiedzieć się, co motywuje Twój zespół, jest zapytanie go.

Dając im indywidualną własność nad kodem.

Wiele sklepów działa na modelu „własności zespołowej”. Jest to idealne rozwiązanie do współpracy krzyżowej i zmniejszenia ryzyka, ale nie tak świetne do motywowania osób do bycia osobiście odpowiedzialnym. Własność zespołu może skutkować średnim kodem, ponieważ nie ma indywidualnej zachęty do posiadania.

Rozwiązanie: Przypisz osoby do każdej sekcji kodu, aby były szafarzami tej części kodu, ale pozwól zespołowi na pełny dostęp do całej bazy kodu.

Zobacz także: https://softwareengineering.stackexchange.com/a/33464/1204