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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.