Czy dojrzały, sprawny zespół wymaga zarządzania?

Po ostatniej gorącej debacie nad Scrumem zdałem sobie sprawę, że moim problemem jest to, że myślę o zarządzaniu jako dość niepotrzebnej i zbędnej działalności w zwinnym zespole. Uważam, że dojrzały zespół Agile nie wymaga żadnego zarządzania ani żadnego nietechnicznego procesu decyzyjnego. Moim (najwyraźniej błędnym) oczom jest bardziej niż oczywiste, że jedynym odpowiednim i zdolnym do zarządzania dojrzałym zespołem programistycznym jest ich trener (który jest najbardziej kompetentnym technicznie kolegą z odpowiednimi umiejętnościami komunikacyjnymi). Nie wyobrażam sobie, jak mistrz Scrum może przyczynić się do takiego zespołu.

Mam duże trudności z uświadomieniem sobie i zrozumieniem wartości takich rzeczy w Scrumie i menedżerze jako kimś, kto nie jest doświadczonym programistą, ale ma duże umiejętności planowania cykli produkcyjnych, gdy w zespole jest trener. Co to w ogóle znaczy? Jak, u licha, ktoś bez umiejętności w zakresie rozwoju może zarządzać wysoce technicznym zespołem? Być może zarządzanie tutaj oznacza coś innego?

Widzę zarządzanie jako całkowitą stratę czasu i produkt uboczny niedojrzałości. W moim rozumieniu dojrzały zespół jest w pełni samozarządzający. Najwyraźniej się mylę, ponieważ wielu wspaniałych ludzi mówi coś przeciwnego, ale nie mogę się przekonać.

Popełniasz tutaj wiele błędów.

Pierwszy zakłada, że ​​Scrum Master jest menedżerem. Oni nie są. Zasadniczo są one administratorami i koordynatorami. Upewniają się, że wszystko dzieje się zgodnie z harmonogramem Scrum, ale nie muszą ci mówić, jak to zrobić, jeśli jesteś w pełni dojrzałym zespołem Agile. To się po prostu dzieje.

Ale nie monitorują jakości twojej pracy ani nie wypisują twoich wakacji, ani nic takiego. Nie zarządzają także produktem ani projektem; robią to inni ludzie.

Największym błędem, jaki popełniasz, jest założenie, że możesz wyjść z sytuacji opisanej w innych pytaniach („Programiści nie są w tej chwili w stanie wykonywać zwinnych praktyk programowania. Bez testów jednostkowych, bez programowania par, bez CI ( huh? co to jest?) ... masz pomysł. ”)„ w pełni dojrzały zespół Agile ”z dnia na dzień. To po prostu niemożliwe. Zapomnij o tym. Nawet nie próbuj.

Jeśli chcesz uzyskać wyniki z dnia na dzień, spójrz na bardziej ustrukturyzowane metody zarządzania projektami. I zatrudnij menedżerów.

Jeśli firma chce, abyś był zwinny, wymaga czasu, zmiany kultury. I tak, na początku, gdy jesteś w chaotycznym etapie doskonalenia , będzie to wymagało zarządzania. Niezależnie od tego, czy jest to osoba czy grupa, ktoś będzie musiał podjąć pewne decyzje.

Potrzebujesz osoby lub grupy, która będzie odpowiedzialna za przyjrzenie się szerszemu obrazowi, wyjaśnienie obecnej sytuacji zarówno deweloperom, jak i firmie, oraz wyjaśnienie opcji, które masz do ulepszenia, ustalenie, czego potrzebuje firma, a następnie poprowadzenie ludzi przez to.

Minie dużo czasu, zanim będziecie mogli nazwać się w pełni dojrzałym zespołem Agile i samodzielnie zarządzać. Większość zespołów nigdy tam nie dotrze.

W moim rozumieniu dojrzały zespół jest w pełni samozarządzający.

Załóżmy przez chwilę, że masz rację. Nie znam w ten czy inny sposób, więc nie rozmawiajmy o tym.

Problem polega na tym, że nawet samozarządzający się zespół trafia do kogoś z dobrymi umiejętnościami społecznymi i politycznymi, który może reprezentować zespół w innych działach. Ktoś, kto śledzi, co wszyscy robią, kiedy biorą urlop itp. Ktoś, kto zajmuje się bzdurami HR i budżetowaniem. Ktoś, kto kłóci się z grupami QA i PM, aby reszta zespołu nie musiała. Ktoś, kto pośredniczy w nieuniknionej sprzeczce interpersonalnej między deweloperami. Ktoś, kto zaplanuje spotkania i utrzyma morale.

Ta osoba jest menedżerem.

• Przyjeżdżasz do domu jednego dnia i płacisz czek nie ...
• Chcesz odejść, ale zespół jest zbyt zajęty i był przez rok ...
• Twoja żona lub dziecko jest chore i potrzebuje cię do 6 godzin tygodniowo
  przez 6 miesięcy.
• Departament finansów wezwał do cięcia budżetu i ktoś musi iść.
• Ekspres do kawy zepsuł się i nikt nie może go naprawić.
• Twój zespół jest tak dobry, że nie ma żadnych wad do usunięcia i żadnych funkcji do dodania, zabrakło ci pracy - co teraz zrobić.
• Klient nie zapłaci za wykonaną pracę
• Klient chce wykonać więcej pracy niż jest to możliwe i jest gotów za to zapłacić.

Na tej liście nie widzę niczego, co nie przydarzyło mi się w mojej karierze. Nie widzę na tej liście niczego, co wymagałoby rozwiązania umiejętności technicznych. Na tej liście widzę wiele rzeczy, które wymagają konkretnych umiejętności, których, szczerze mówiąc, większość programistów nie ma, i dobrzy menedżerowie, bez względu na to, czym zarządzali w przeszłości.

Przestań pakować menedżerów - poznaj, że masz zestaw umiejętności i że oni mają inny zestaw. Wszystkie te umiejętności są potrzebne w każdej organizacji. Będziesz wykonywać ich pracę tak samo dobrze, jak oni wykonują twoje. Rzadko jest mieć kogoś dobrego w obu zawodach, rzadziej jest mieć kogoś dobrego w obu, który może wykonywać oba jednocześnie. To, co dzieje się bez żłóbka, polega na tym, że rzeczy powoli ulegają erozji. Jeśli masz szczęście, jest dostatecznie wcześnie rozpoznany, zatrudniony zostaje menedżer, a wszystkie nagłe problemy znikają jak za pomocą magii, a Ty możesz zająć się pracą, za którą otrzymujesz wynagrodzenie, zamiast grać głupią politykę biurową (mówiąc z doświadczenie tutaj).

Widzę zarządzanie jako całkowitą stratę czasu i produkt uboczny niedojrzałości.

Łał. Nie pracowałeś ostatnio z dobrymi menedżerami, prawda? (Wszyscy pracowaliśmy z tymi złymi).

Widziałem ludzi, którzy czasami popełniają błąd, zakładając, że wszystko, czego nie do końca rozumieją, jest łatwe.

(Ludzie biznesu są szczególnie winni tego - czy kiedykolwiek otrzymałeś słabe specyfikacje ORAZ ustalony termin?)

W większości firm zespół programistów istnieje jako część większej całości. Menedżerowie istnieją jako interfejs między zespołem a resztą firmy. Dobry menedżer będzie pracował nad tą relacją w obu kierunkach, zapewniając zespołowi to, czego potrzebuje (wymagania, przestrzeń biurowa, nowe komputery, uznanie, premie itp.), A także komunikując (ciągle zmieniające się) priorytety, które wychodzą z biura w rogu .

Biuro narożne istnieje z wielu powodów, z których większość nie dotyczy tego postu.

Pamiętaj, że większość menedżerów podejmuje najlepsze decyzje na podstawie dostępnych im informacji, które mogą nie być takie same, jak informacje dostępne dla Ciebie .

Jeśli miałeś w pełni dojrzały zespół programistów, który był częścią w pełni dojrzałej firmy, która miała w pełni dojrzałych klientów i nic się nie zmieniło, być może wyeliminujesz potrzebę większości zarządzania. Terminem tym jest Utopia .

Powodzenia z tym.

ps - czytaj Nie nazywaj siebie programistą - doskonała rada i wyjaśnia lepiej niż ja, jak postrzega nas reszta świata biznesu.

Zadaniem mistrza scrum lub kierownika w ogóle nie jest występowanie w roli dyktatora. Zadaniem menedżera jest upewnienie się, że jego zespół jest nastawiony na sukces w firmie. Obejmuje to zatrudnienie odpowiednich ludzi, uzyskanie odpowiedniego sprzętu i strategiczne spojrzenie na produkt. Menedżer powinien być jak liniowiec, zachowując szczegóły i szczegóły, które nie są ważne dla sukcesu zespołu od zakłócania jego postępów.

Częściowym problemem jest to, że „Scrum Master” jest prawdopodobnie najmniej dokładnie opisaną rolą w całej historii. „Scrum Facilitator” byłby nieco bardziej dokładny, ale jak ktoś wcześniej zauważył, zadaniem SM nie jest zarządzanie zespołem, ale rozwiązywanie problemów, aby zespół (samozarządzający) mógł zająć się swoimi zadaniami. Tak, scrum master jest również odpowiedzialny za dopilnowanie, aby scrum się odbył: zadania są aktualizowane z pozostałymi godzinami, wstrzymania są wstrzymywane i dodają wartości, wypalenia są aktualizowane, a prędkość jest śledzona itd., Ale to wciąż jest coaching i rola ułatwiająca, a nie rola zarządzająca.

Inną częścią problemu jest to, że ludzie w biurach narożnych chcą znać odpowiedzi na pytania typu „kiedy mogę wysłać oprogramowanie?” i „jakie funkcje będzie zawierać?” i są przyzwyczajeni do tego, że mogą zadawać „Kierownikowi projektu” te pytania i uzyskiwać odpowiedzi poparte mnóstwem imponujących wykresów Gantta i niewielką lub żadną wzmianką o niewygodnych rzeczach, takich jak stożek niepewności.

W Scrumie można zacząć od zgrubnej i gotowej listy funkcji „będzie”, „może” i „nie” dla dowolnej daty wysyłki, ale na pewno jest rola dla kogoś - prawdopodobnie mistrza Scrum - dbając o to, by biuro narożne było na bieżąco z nieuniknionymi zmianami na tych listach w miarę upływu czasu. Kusi mnie, aby pomyśleć o tej działalności, wraz z przetwarzaniem uzyskanych informacji zwrotnych i zarządzaniem nowymi żądaniami funkcji jako „zarządzanie”, chociaż zarządzanie różni się od tego, co wielu, wielu Kierowników Projektu mogło zrobić w przeszłości.

Jeśli uważasz, że zarządzanie nie jest potrzebne, kto będzie wykonywał następujące zadania organizacyjne, kto zareaguje w następujących sytuacjach?

• należy znaleźć nowych klientów. Jak sprzedajesz swoje produkty? Jak się reklamujesz?
• materiały muszą zostać zakupione, należy znaleźć dostawców
• należy prowadzić rozmowy dyplomatyczne z innymi firmami, bankami lub urzędem państwowym

Jestem w małym zespole bez menedżera i to działa. Dlaczego? Naprawdę nie wiem.

Myślę, że sprowadza się to do rodzaju osoby, którą jesteś. Niektóre osoby są „komputerami”, więc trzeba je karmić procesem. Inni ludzie są „programistami” i mają zdolność do tworzenia własnego świata i struktury z niczego.

Muszę stworzyć system lub zostać zniewolonym przez innych ludzi; Nie będę rozumować i porównywać: moja działalność polega na tworzeniu. - William Blake

EDYCJA w odpowiedzi na komentarz glenatron:
To coś więcej niż zespół programistów. Mamy dyrektora generalnego, recepcjonistę odbierającego telefon i informatyka. Komunikujemy się z klientami bezpośrednio przez e-mail, telefon lub spotkania. Naszą główną działalnością jest tworzenie własnego produktu i sprzedawanie go, a nie wyszukiwanie umów. Ale są też kontrakty.

Myślałem o tym więcej i oto powody, dla których myślę, że to działa:
1. Tworzymy przede wszystkim własny produkt, a nie kogoś innego.
2. Mamy spójną etykę pracy niezależnie, bez nadzoru.
3. Mamy wiedzę domenową.
4. Szczęście. Garstka ludzi, którzy dobrze się dogadują i dobrze ze sobą współpracują.

Ktoś wspomniał, że firma Valve również nie ma zarządu. Valve tworzy swój własny produkt, zamiast tworzyć czyjś produkt. Myślę, że firma produktowa lepiej nadaje się do samozarządzania. Nie ma ryzyka, że ​​pójdziesz inną ścieżką, niż oczekuje klient, ponieważ jesteś klientem. W firmie zajmującej się grami jest to szczególnie prawdziwe. Spraw, by gra była przyjemna

Nie możesz zarządzać swoją drogą do zabawy. Nie możesz zarządzać swoją drogą do oryginalnego dzieła sztuki.