Jako kierownik zespołu i programista w zespole Scrum

Zarządzam zespołem 6 osób, które niedawno przeprowadziły się do Scrum.

Mamy Scrum Master (jeden z programistów w zespole) i właściciela produktu.

Ponieważ mam dużo wolnego czasu (ponieważ wiele prac związanych z zarządzaniem, które kiedyś wykonywałem, są teraz wykonywane przez Scrum Master i właściciela produktu), a ponieważ chcę pozostać technicznie istotny, wykonuję pewne prace związane z rozwojem technicznym.

Działam jako część zespołu programistów, angażuję się w niektóre historie z każdego sprintu i uczestniczę we wszystkich spotkaniach jako część zespołu.

Czy uważasz, że to dobry pomysł? Czy może to zaprzeczać „samoorganizacji” zespołu?

Zapoznaj się z rozwijającymi się przemyśleniami Roya Osherovego na temat przywództwa w zespole w zwinnym świecie na stronie 5whys.com

Wiele mówi o trzech kluczowych etapach, przez które przechodzi zespół, przechodząc od Waterfall do Scrum.

Faza przetrwania (w której znajduje się większość zespołów, które widzę) - w której zespół nie ma czasu na naukę - wymaga większego dowodzenia i kontroli, aby stworzyć ten czas nauki z niczego.

Faza uczenia się - w której zespół ma czas na naukę i z niej korzysta - wymaga trenera jak lider, z wybuchem kontroli, gdy nauka będzie wymagała zbyt długiej nauki (na przykład brak kontroli źródła)

Faza samoorganizacji - gdzie zespoły mogą rozwiązywać własne problemy - wymaga bardziej przywódcy typu moderatora, który nie mówi ludziom, co ma robić, ale po prostu zapewnia ograniczenia i cele końcowe. Zespół dotrze tam sam.

Kiedy na OpenVolcano '10 natknąłem się na pomysły Roya, całkowicie straciłem rozumowanie , dlaczego mój zespół przestał się poprawiać. Potem zdałem sobie sprawę, że zespół przeszedł z Survival do Learning i w ogóle nie zmieniłem stylu zarządzania. Zrobiłem to i bardzo mi pomogło.

Sugeruję więc, aby dowiedzieć się, w której z tych trzech faz jesteś, i odpowiednio nimi zarządzać.

Również teraz podejmij decyzję i bądź liderem lub programistą. Nie wpadnij w pułapkę myślenia, że ​​masz wolny czas, dopóki nie przejdziesz do fazy samoorganizacji. A jeśli się tam dostaniesz, zdaj sobie sprawę, że jesteś dobrym liderem zespołu (to trudne ) i przejdź do innej drużyny zamiast się reintegrować.

Komentarze pdr są prawidłowe i zgadzam się z nimi. Ale nie wierzę, aby były uniwersalne we wszystkich przypadkach.

Twój styl zarządzania decyduje o tym, jak dobrze lub nawet powinieneś rozważyć pracę w dwóch rolach.
Jako kierownik zespołu masz władzę nad decyzjami dotyczącymi wydajności i rodzaju kariery zawodowej swoich pracowników. Nieprawidłowe wykorzystanie, rozbieżność władzy między tobą a twoimi pracodawcami może zepsuć twoje próby dołączenia do zespołu programistów.

Tak długo, jak zdajesz sobie sprawę z tej rozbieżności i wyraźnie rozróżniasz swoje role, myślę, że możesz być zarówno menedżerem, jak i programistą. Widziałem to wielokrotnie, a obecnie pracuję nad zespołem w tej samej sytuacji.

Warto zauważyć, że nie można wyeliminować wszystkich skutków nierówności. Będą chwile, kiedy będziesz musiał ugryźć się w język i powstrzymać od porywającej debaty. Będą inni, kiedy będziesz musiał wyciągnąć kartę atutową i wskazać, że ostateczna odpowiedzialność za zespół spoczywa na tobie, więc robisz diktat.

Będziesz potrzebował co najmniej dwóch silnych, doświadczonych programistów w swoim zespole, którzy są politycznie bezpieczni. Ich rolą jest utrzymywanie w ryzach dysparytetu mocy i wzywanie cię, jeśli sytuacja się wyrówna. Możesz poradzić sobie tylko z jednym silnym programistą, ale posiadanie drugiego zapewnia obiektywizm na wypadek, gdybyście obaj znaleźli się w impasie w kwestii.

Szczerze mi się podoba, gdy mój bezpośredni przełożony zachowuje swoje znaczenie techniczne. Ułatwia im to zrozumienie moich trudności i wydaje mi się, że mamy lepszy zespół.

Wcześniej przeszedłem przez podobne doświadczenie, kierując zespołem 6 programistów w zespole Scrum. Poza tym, o czym wspominali pdr i GlenH7, rzeczy, które pomogły:

1. Najlepszy tester w zespole ds. Kontroli jakości był naprawdę dobry w utrzymywaniu odpowiedzialności za jakość naszej pracy, w tym za moją pracę. Kiedy napisałem błędny kod, wezwała mnie do tego w sposób, który byłby trudny dla innego programisty.
2. Zwykle robiłem demo sprintu, zwłaszcza gdy mieliśmy złe sprinty. Ponieważ pracowałem nad wersją demo dyrektora generalnego, zawstydzanie było, gdy rzeczy nie działały. Oprócz upewnienia się, że rozumiem funkcje opracowane przez innych, oznaczało to również, że moje rzeczy musiały być tak solidne, jak innych.
3. Pozwalam innym podejmować decyzje. Moje doświadczenie jest inne niż w przypadku GlenH7, zawsze uważałem za błąd wyciągnięcie karty atutowej. Zamiast tego omówiłem różne konsekwencje decyzji i wyjaśniłem, który deweloper pracował nad czymś, jakie były konsekwencje tego, co uważałem za „niewłaściwy” sposób zrobienia czegoś. Jest wiele powodów, aby to zrobić, ale najważniejszym z nich jest to, że jako lider zespołu nie masz czasu na podejmowanie wszystkich decyzji.
4. Korzystanie z produktu takiego jak Sonar może sprawić, że jakość kodu będzie bardziej obiektywna.