Agile MVP (najcenniejszy gracz / programista)

Ostatnio byłem zaangażowany w zwinny projekt (wykorzystujący scrum), w którym kierownictwo wpadło na pomysł, aby zespół mianował programistę „MVP”, a także QA „MVP” na końcu każdego sprintu, pod głosowaniem zespół. Następnie MVP otrzymuje niewielką nagrodę pieniężną i bezpłatny lunch, a także trofeum do wystawienia na biurku. Do tej pory mieliśmy dwa sprinty z tym systemem nagród.

Dobro, które z tego wynika, to:

• Naprawiono więcej błędów (to, co chce zobaczyć wyższa kadra kierownicza, zmiana liczby w pożądanym kierunku)
• MVP z każdej „drużyny” zostaje rozpoznany i zyskuje premię do samooceny (czy jest to premia do ego?)

Zauważyłem kilka rzeczy, które uważam za złe strony robienia czegoś takiego (przynajmniej z punktu widzenia programisty):

• Jest kilku programistów, którzy są tak zaniepokojeni liczbą, że obniżyła się jakość naprawionych błędów. Poprawki w jednym obszarze powodują regresje w innym.
• Jest kilku programistów, którzy wybierają błędy „łatwiej / szybciej”, aby zwiększyć liczbę błędów. Chyba może być źle.
• Wyższy priorytet (który przez większość czasu koreluje z „trudniejszym / dłuższym do naprawy”) defekty faktycznie stają się niższym priorytetem.
• Blokowanie defektów nie jest rozwiązywane na czas, ponieważ zwykle trwają dłużej i wymagają większej koordynacji z kontrolą jakości.
• Aspekt zespołowy w zespole deweloperów został utracony. Aspekt zespołowy współpracy deweloperów i kontroli jakości, ponieważ również się nie poprawił, ale tak naprawdę nie zmienił się zbytnio.
• Praca wykraczająca poza poprawki błędów lub praca nad tym numerem nie jest łatwa do rozpoznania / śledzenia.

Uważam, że każdy z powyższych „złych” problemów można rozwiązać do pewnego stopnia, w zależności od tego, jak zespół sobie z nimi poradzi.

Moje pytanie brzmi zatem, czy ktoś z powodzeniem ściągnął coś takiego, gdzie rozpoznajesz MVP na sprint? Jeśli tak, to co według Ciebie przyczyniło się do tego sukcesu?

Zwinny podkreśla wysiłek zespołu , a nie wysiłek poszczególnych osób. Więc nie, to podejście wyraźnie nie jest zwinne.

Zamiast zachęcać do współpracy w zespole, zachęca to każdego członka zespołu do skupienia się na własnym wyniku. Może nawet prowadzić do unikania wzajemnej pomocy członków (lub gorzej), co na dłuższą metę powstrzyma drużynę przed poprawą.

Sugeruję nagradzanie całego zespołu, jeśli wykonali dobrą robotę.

Myślę, że dobrym przykładem -bad- grywalizacja obecnie stosowane. Problem polega na tym, że twoi programiści mieli potencjalną motywację do rozwiązywania problemów i wygrywania przez wyzwania (znajdowanie i naprawianie trudnych błędów) ORAZ, odkąd wdrożyłeś Scrum, pracując jako ZESPÓŁ. Innymi słowy, potencjalnie chcieli zrobić dobrą robotę.

Teraz, przynajmniej dla niektórych z nich, ta wewnętrzna motywacja lub jej część została zastąpiona motywacją zewnętrzną składającą się z tytułów („MVP tygodnia”) i nagród (kwota pieniężna i bezpłatny lunch), które często są częścią mechaniki gry procesu gamifikacji.

Gamifikację można z powodzeniem stosować w pracy, ale trzeba bardzo ostrożnie wykorzystywać motywację wewnętrzną / zewnętrzną. Motywacja zewnętrzna musi napędzać samostanowienie , aby motywacja stała się nieodłączna. Jednak to, co się tutaj wydarzyło, jest odwrotne, programiści „grają w grę”, aby wygrać .

Aby to naprawić, możesz poprosić kierownictwo o zmianę zasad:

• przyznawać punkty odpowiadające trudnościom i priorytetowi biletów. Spraw, aby naprawienie trudnego do znalezienia / odtworzenia błędu było znacznie bardziej interesujące pod względem punktowym.
• przyznawać punkty za wspólne rozwiązywanie problemów (ponownie ZESPÓŁ). Tutaj możesz uzyskać więcej programistów do interakcji z kontrolą jakości. Podaj punkty za problem rozwiązany wspólnie przez programistę ORAZ na przykład kontrolę jakości.
• podaj różne tytuły, jeden za najwięcej punktów, a drugi za najwięcej biletów. Powinno to zaspokoić instynkt konkurencyjny programistów.
• możliwe ustanowienie przyjaznej rywalizacji między Dev i QA poprzez zsumowanie punktów każdego członka zespołu

Innym problemem jest ograniczenie możliwości pojawienia się błędów regresji. Możesz na przykład zastosować punkty ujemne, ale jestem pewien, że nie jest to dobry pomysł, ponieważ byłaby to forma kary. Być może lepiej byłoby automatycznie rozpocząć sprint z kilkoma punktami, jeśli w poprzednim tygodniu nie wykryto błędu regresji. Jeśli wykryte zostaną błędy regresji, programista rozpocznie od 0.

Ponadto w „gamifikacji” występuje „gra”. Podstawowym aspektem gry jest to, że grasz / uczestniczysz dobrowolnie. W kontekście pracy może to być narzucone przez kierownictwo, co ma miejsce w tym przypadku, ale zwykle nikt nie powinien być do tego zmuszany.

Podsumowując, to MVP niekoniecznie jest złym pomysłem, ale podejście to można nieco zmienić, aby biznes (rozwiązywanie ważnych błędów) był na pierwszym miejscu i kładł nacisk na pracę zespołową, a nie na osoby indywidualne.

Pewne grupowe uznanie wysiłków członka zespołu może być cennym czynnikiem motywującym, ale w tym przypadku wydaje się, że jest niewłaściwie stosowane. Stwierdzasz, że MVP jest wybierany w drodze głosowania, ale jest wiele wzmianek o liczbie błędów naprawionych na sprint. Wygląda na to, że Twój czas ma zabawną definicję MVP - przypuszczam, że osoba, która zasługuje na tytuł „najcenniejszego”, to osoba, która w tym sprincie zwiększyła wartość oprogramowania. Jeśli członek zespołu wybiera błędy, które można szybko naprawić, przebija je tak szybko, jak to możliwe i powoduje błędy regresji i inne problemy po ich zakończeniu, to nie dodaje wartości, tworzy więcej pracy dla każdego, kto ma śledzić je w celu zidentyfikowania i rozwiązania tych problemów.

Sugeruję, aby spróbować rozpocząć właściwą dyskusję następnym razem, gdy twój zespół uzyska jeden z tych głosów. Nie rób z tego pokazu rąk; omów to najpierw. Jeśli wydaje się, że ktoś zdobywa głosy na podstawie liczby dokonanych przez niego „poprawek”, wskaż (taktownie), gdzie te poprawki spowodowały regresje, i zasugeruj, że być może osoba, która naprawiła te regresje, powinna zostać nominowana do oczyszczenia innych osób bałagan. Jeśli ktoś spędził cały sprint podporządkowany jednemu nieprzyjemnemu problemowi, zwróć uwagę na zespół, podkreślając fakt, że chociaż liczba poprawek tej osoby wynosi jeden, to samodzielnie rozwiązali poważny problem z twoim oprogramowaniem - problem, który był tak paskudny, że nikt inny nie chciał go dotknąć.

Wybranie łatwych poprawek i wykonanie ich w pośpiechu lub przypadkiem nie jest cenne, więc programiści, którzy to robią, prawdopodobnie nie powinni kwalifikować się jako kandydaci do MVP. Wybierając nowego MVP, zapomnij o zespole i znajdujących się w nim ludziach i spójrz na oprogramowanie. Wybierz najważniejszą zmianę w tym oprogramowaniu od ostatniego razu. Mam tu na myśli singla ; „nie tak wiele drobnych błędów” nie jest znaczącą zmianą. Czy naprawiono szczególnie rażący błąd? Czy dodano świetną nową funkcję? Po ustaleniu, co to za jedna wielka zmiana, zapytaj, kto był za nią odpowiedzialny. Jedna z tych osób jest prawdopodobnie Twoim faktycznym MVP. Jeśli jedyną różnicą jest „nie tak wiele drobnych błędów”, to tylko i wyłączniewtedy liczenie błędów jest prawidłową miarą MVP - i nawet wtedy spojrzałbym na stosunek błędów naprawionych do błędów regresji spowodowanych. Każdy błąd, który ktoś powoduje, odejmuje co najmniej 1 od ich liczby. W rzeczywistości powiedziałbym więcej niż 1, ponieważ zła poprawka spowoduje nieznany błąd, który musisz następnie znaleźć, co jest gorsze niż znany błąd, który został już znaleziony. Znany błąd wymaga naprawy; nieznany błąd wymaga wysiłku zapewnienia jakości, a wysiłku programisty naprawić, a następnie istnieje ryzyko, że nie uda mu się to zrobić.

Teoretycznie, jeśli programiści zdadzą sobie sprawę, że drogą do nagrody jest rozwiązanie mniejszych, większych problemów, będą dążyć do tych trudnych, złożonych, blokujących defekty. Będzie to czasem wymagać od nich, aby się połączyli, albo dlatego, że nie ma wystarczająco dużo mięsistych problemów, aby je obejść, albo dlatego, że problem jest na tyle trudny, że wymaga więcej zestawów oczu . Być może zasugeruj, że w takich przypadkach nagroda może być dzielona, ​​jeśli nie jest od razu jasne, który z zestawów ludzi pracował więcej w celu naprawienia błędu - i pamiętaj, praca wykonana! = Napisane wiersze kodu. Deweloperzy prawdopodobnie to wiedzą, ale powiedzieliście, że zarządzanie jest zaangażowane, a zarządzanie nie zawsze rozumie ten punkt.

I hej, jeśli wszystko inne zawiedzie, zapomnij o programie MVP. Porozmawiaj z innymi programistami spoza scrum i zwróć uwagę na negatywny wpływ nagród MVP na oprogramowanie. Sprawdź, czy uda ci się je zignorować, czy nie sprawi, że będzie to taka wielka sprawa. Zostaw trofeum w szufladzie, wydaj nagrodę pieniężną na drinka dla zespołu po pracy, skorzystaj z darmowego lunchu, aby zdobyć coś, czym możesz się podzielić, na przykład babeczki. Agile to system zespołowy; podkreślanie indywidualnych ryzyk związanych z wydajnością, które stawiają zespół przeciwko sobie. Zjednoczeni stoicie, podzieleni, wysyłacie oprogramowanie wypełnione błędami, po terminie przekroczenie budżetu.

Jest to klasyczny przykład tego, w jaki sposób określona praktyka (publiczne uznanie za MVP) może mieć znaczący, ale pośredni wpływ na zachowanie twojego zespołu. Wykracza to poza zachęty, motywacje i nagrody i dotyka pomysłów w psychologii środowiskowej / behawioralnej i architekturze decyzyjnej. Fajne rzeczy.

Pytanie brzmi - w jaki sposób możesz zaprojektować proces, aby Twój zespół po prostu naturalnie robił wszystkie właściwe rzeczy, bez konieczności wprowadzania sztywnych zasad lub zmuszania ludzi do zrobienia czegoś?

Pisałem o wykorzystaniu afordancji (w tradycji Design of Everyday Things ) Donalda Normana ) do procesów jako mechanizmu projektowania procesu, który działa dla twojego zespołu. Podstawową ideą jest to, że praktyki w procesie bezpośrednio wpływają na zachowanie danej osoby. Jako takie pojawiają się problemy, gdy afordancje w twoim procesie nie są w pełni dostosowane do wartości twojego zespołu.

Przeprowadziłem kilka warsztatów na ten temat i od czasu do czasu ten konkretny problem pojawia się jako przykład w grupach. Zastosowanie teorii afordancji w sprawie, którą podzieliłeś się z pytaniem, może wyglądać mniej więcej tak ...

Załóż, że Twój zespół ceni sobie spójność, przewidywalność i kod wysokiej jakości.

Masz listę negatywnych zachowań, które zaobserwowałeś, i wszystkie one wynikają z użycia wskaźników defektów do wyboru MVP zespołu. Na przykład koledzy z drużyny naturalnie chcą przypadkowo wybierać i naprawiać błędy, negatywnie wpływając na wszystkie trzy twoje wartości. (Zakładam, że wcześniej też był problem, i to właśnie doprowadziło do pomysłu MVP).

Zamiast pojedynczego MVP opartego na wskaźnikach defektów, spróbujemy zmienić zachowanie zespołu, wprowadzając niewielkie, ale znaczące zmiany.

• Pozwól każdemu dać „zespołowe uznanie” dowolnej (i wszystkim, nie tylko jednemu) osobom, które w widoczny sposób przyjmą twoje wartości zespołowe. Sprzyja to przewidywalności poprzez demokratyzację systemu wartości zespołu poprzez przykłady. (Właściwie to robimy w naszym zespole ..)
• Rozpocznij programowanie w parach (lub przypisz „kumpli błędów”) do wszystkich napraw błędów. Sprzyja to jakości poprzez zniechęcanie do pochopnych lub niedocenianych decyzji programowych i zachęca do konsekwencji, ponieważ kumple będą łagodzić nieprzewidywalne zachowania. (Pomysł ten jest często sugerowany podczas warsztatów, wydaje się intuicyjny ..)

A to tylko kilka przykładów, które pokazują podejście i zaczynają ...

Wspaniałe w tym podejściu jest to, że aktywnie projektujesz zmiany procesu i masz uzasadnione powody, dla których dokonujesz zmian procesu. Podobnie jak w projektowaniu obiektowym lub interfejsu użytkownika, możesz nawet mierzyć wyniki, aby zrozumieć, czy coś działa, czy nie.

Jedną z najłatwiejszych zmian, aby zapewnić coś w rodzaju programu MVP, jest nagradzanie członków zespołu za to, że są najbardziej wartościowi dla sukcesu zespołu, a nie są najtrudniejszymi pracownikami.

Zrobiliśmy to z powodzeniem, rozpoznając ludzi, którzy nawet nie pracowali nad błędami lub funkcjami, ale zrobili coś niesamowitego, co sprawiło, że wszyscy w zespole odnieśli większy sukces. Na przykład mieliśmy jednego programistę, który podjął się mentoringu grupy nowych członków zespołu, aby mogli poznać architekturę i sposób działania. Nasza prędkość przyspieszyła, ponieważ mieliśmy nowych rekrutów zdolnych do szybkiego i skutecznego dostarczania wyników, nawet jeśli pojedynczo spadła prędkość jednego dewelopera, ponieważ spędzał więcej czasu na pomaganiu reszcie zespołu.

Nagradzaj pracę zespołową, a zespół zauważy, że liczy się ZESPÓŁ, a nie ich osobisty sukces.