Czy Agile jest nowym mikrozarządzaniem?

To pytanie gotowało się w mojej głowie przez pewien czas, więc chciałem zapytać tych, którzy przestrzegają praktyk zwinnych / scrumowych w swoich środowiskach programistycznych.

Moja firma w końcu odważyła się wdrożyć zwinne praktyki i zaczęła od zespołu 4 programistów w zwinnej grupie na zasadzie próbnej. Minęły 4 miesiące z 3 iteracjami i nadal to robią, nie pozostając w pełni zwinnym dla reszty z nas. Wynika to z faktu, że zaufanie kierownictwa do spełnienia wymagań biznesowych przy dość dużej liczbie zapytań typu ad hoc z góry.

Ostatnio rozmawiałem z programistami, którzy są częścią tej inicjatywy; mówią mi, że to nie jest zabawne. Nie mogą rozmawiać z innymi programistami przez swojego mistrza Scrum i nie mogą odbierać żadnych połączeń telefonicznych w obszarze roboczym (co może być do pewnego stopnia w porządku). Na przykład, jeśli chcę porozmawiać z moim przyjacielem o kopnięcia, który jest w zwinnej drużynie, nie wolno mi bez zgody mistrza Scrum; który siedzi tuż obok zwinnego zespołu.

Ideą tego wszystkiego lub zwinności jest zapewnienie pełnej próżni zwinnym programistom od wszelkich zakłóceń i zapewnienie im dobrych 6+ produktywnych godzin. Cóż, chłopaki, nie jestem zwinnym guru, ale to, co przeczytałem zwinny dokument dotyczący wdrażania Yahoo i podobne dla innych organizacji, daje mi wrażenie, że zwinność nie jest tania. Wymagają zasobów i budżetu, aby zaszczepić zwinne zespoły i rozwiązać problem po ich przybyciu, aby przywrócić je na właściwe tory.

Na początek wymaga szkolenia dla programistów i coachingu dla menedżerów itp. Itd. Obecny mistrz Scrum był menedżerem, który odbył kilka dni zwinnej klasy szkoleniowej opłaconej przez kierownictwo, która prowadzi teraz ten zwinny zespół. Słyszałem również na spotkaniu, że manifest zwinny nie dyktuje, że zwinny nie jest osadzony w kamieniach i jest dostosowywany inaczej dla każdej firmy. Cóż, wszystko brzmi dobrze i uzasadnione.

Podsumowując, zawsze myślałem, że zwinny powinien przynieść harmonię w zespołach programistycznych, co prowadzi do zadowolenia programistów. Jednak mam wrażenie zupełnie przeciwne, gdy rozmawiam z programistami w zwinnym zespole. Są niezadowoleni, że nie mogą rozmawiać tylko poza pracą, siedzą spokojnie przez cały dzień i pracują, i uważają, że to kolejny sposób zarządzania, aby zwiększyć ich pracę.

Powiedz mi proszę, czy jest to jeden z przykładów dobrych praktyk stosowanych w celu samolubnej przewagi za więcej dolarów? A może tylko my, programiści tacy jak ja, i ten zwinny zespół czuje, że nie lubią pracować w środowisku, w którym oddychają tylko dlatego, że są w pracy.

To firma z branży opieki zdrowotnej, która ma biura w całych Stanach Zjednoczonych. Zdecydowanie czuję się jak agresywny w stylu kowbojskim, co sprawia, że ​​naprawdę nie chcę wcale być agile, szczególnie w mojej obecnej firmie.

Wszystko to ma związek z tym, że zarządzanie jest całkowicie tanie. Wycinanie drogiej kawy w celu uzyskania tańszej wersji, nacisk na oszczędność i produktywność przy zachowaniu jak najbardziej szczupłej sylwetki.

Mam wrażenie, że ktoś z kierownictwa za drzwiami odrzucił ten pomysł, że zwinność sprawia, że ​​produkujesz więcej, abyśmy mogli pokazać naszym szefom, że produkujemy więcej przy tym samym zatrudnieniu. A może pozwoli nam to zmniejszyć liczbę pracowników, jeśli tak jest.

Codziennie odbywają 5-minutowe spotkanie. Ale nie wolno rozmawiać ani rozmawiać z kimś spoza zespołu. Koncentrujemy się na pracy.

Opisujesz dyktaturę kierowniczą, a nie zwinną. Zwinność polega na stopniowym rozwoju w dziedzinie zmieniających się wymagań, a nie na dyktowaniu ludziom indywidualnego podejścia do wykonywania pracy.

Nie mogą rozmawiać z innymi programistami przez swojego mistrza Scrum i nie mogą odbierać połączeń telefonicznych w obszarze roboczym

To naprawdę nie jest częścią zwinnych praktyk - i osobny problem.

Dużą motywacją metodologii Agile jest zwiększona komunikacja między programistami. Ograniczanie komunikacji programisty <-> z programistą jest kwestią niezależną od praktyk Agile. Nie twierdzę, że tak się nie dzieje - oczywiście tak jest i jest oznaczane jako część „zwinnego” wdrożenia w Twojej organizacji, ale tak naprawdę jest to kwestia odrębna od zwinności (i nieco wbrew duchowi zwinnego rozwoju, IMO).

To brzmi jak całkiem przewrotna implementacja zwinności. Zwinne, jeśli w ogóle, powinno zmniejszyć mikrozarządzanie, a nie je zwiększyć. Zespół zobowiązuje się, a częścią procesu jest to, że kierownictwo wierzy, że zespół go zrealizuje. Codzienny scrum jest sposobem dla programistów na komunikowanie się ze sobą i sposobem na informowanie o tym, co zrobili, a nie o tym, jak spędzili czas (co jest błędem, który widziałem w kilku miejscach). Nawet proces szacowania powinien usunąć jawne zachowanie czasu z oszacowań, ponieważ powinieneś szacować względną złożoność, a nie to, jak długo zajmie opowieść (kolejny powszechny błąd). Kontrolowanie czasu spędzanego przez programistów jest cechą mikrozarządzania, a usuwanie czasu z procesu jest jedną z podstawowych zasad zwinności.

Opisywane środowisko brzmi jak pseudo-zwinne bzdury odmiany ogrodowej .

Zaangażowałem się w Agile, zanim była to Agile. Około 2000 roku wypaliłem kodowanie, usłyszałem o Extreme Programming, wypróbowałem go i polubiłem. Jako programista dał mi kontekst, w którym najważniejsze było tworzenie solidnego oprogramowania, i dał mi narzędzia do zminimalizowania wielu bzdur, które doprowadzały mnie do szału. Kocham to.

Problem dzisiaj, który szczegółowo wyjaśniam gdzie indziej , polega na tym, że większość ludzi „adoptujących Agile” w tych dniach nie jest zainteresowana poprawą czegokolwiek, co sprawia, że ​​czują się niekomfortowo. Dla nich „Agile” to po prostu nowy kij do pokonania programistów w ten sam stary sposób. W przeciwieństwie do, powiedzmy, sposobu radykalnego zwiększenia wydajności przy jednoczesnym usunięciu wszystkich bzdur, które spowalniają rozwój.

Teraz. Zaczynam firmę i będę używał dużo XP, a także wielu innych sztuczek, które oparłem w świecie Agile. Ale właśnie z powodu takich historii jak ja, wzdrygam się za każdym razem, gdy słyszę o adopcji Agile.

Aby odpowiedzieć bezpośrednio na twoje pytanie: zwinne nie powinno być nowym mikrozarządzaniem. Powinno to polegać na wzmocnieniu pozycji ludzi wykonujących rzeczywistą pracę, aby zrobić gówno. Ale w twoim przypadku Agile brzmi jak najnowsze kłamstwo, które ci mówią, podczas gdy oddają się swoim złym instynktom. Za co naprawdę mi przykro.

To nie jest zwinne.

Po pierwsze, Scrum nie jest zwinny . Scrum, szczerze mówiąc, to bzdury. Wychowałem się w domu programowania ekstremalnego (dosłownie - kazałem Kentowi Beckowi usiąść na kanapie mojego taty i porozmawiać ze mną o testowaniu) i mogę powiedzieć wprost, że Scrum to nie to. Scrum to narzędzie do zarządzania projektami - określony rytm projektu deweloperskiego. Ale nie ma nic do powiedzenia na temat samego rozwoju, a bardzo mało na temat wymagań, planowania i relacji z klientem. XP ma wiele do powiedzenia na ten temat; każda inna metodologia, która chce się nazywać zwinną, musi mieć coś do dodania do rozmowy. Zwolennicy Scruma opisali to nie jako proces, ale jako opakowanie procesu. Mądry człowiek zauważył kiedyś, że opakowanie jest rzeczą, którą usuwasz i odrzucasz, aby dostać się do dobrych rzeczy.

Okej, scrum się skończył!

Po drugie, podstawową zasadą XP, która moim zdaniem jest fundamentem każdego zwinnego procesu, jest to, że koncentruje się na deweloperze . Jest to sposób na zapewnienie programistom mocy do wykonywania pracy, o której wiedzą, że muszą ją wykonać i dlatego tak często ich nie ma. Zwinny zespół może mieć strukturę demokracji lub autokracji, ale liderzy są programistami. Istnieją role kierowników projektów i tak dalej - ważne role - ale nie jest to kierownictwo zespołu. Posiadanie menedżera - przepraszam, „mistrza scrum” - siedzenie tam i kierowanie ludźmi to pewny znak, że zespół nie robi zwinności.

Czuję, że powinna być trzecia. Nie ma

Scrum jest bękartem Agile. Jest to najbardziej wodospad ze wszystkich zwinnych metodologii i dlatego jest najpopularniejszy wśród menedżerów.

Wszystkie zwinne metody polegają na tworzeniu działającego kodu bez przeszkadzania. Przeczytaj to jeszcze raz. I znowu.

Wszystko, co przeszkadza w osiągnięciu tego celu, niezależnie od „zwinnych zasad”, jest złe. Jeśli reguły ci przeszkadzają, zmień reguły f * * ! To zwinny sposób, dzięki czemu jest odpowiedni i skuteczny.

Najlepszym przykładem tego jest przez Alistair Cockburna (jeden z inicjatorów agile manifestu)

„Umieść 4-6 osób w pokoju ze stacjami roboczymi i tablicami i dostępem do użytkowników. Niech dostarczą działające, przetestowane oprogramowanie użytkownikom co miesiąc lub co dwa miesiące, a w przeciwnym razie zostaw je w spokoju. ”

Jeśli to działa na jakość twoich facetów, to wszystko, czego potrzebujesz. Nie potrzebujesz mistrza scrum ani żadnej „zwinnej” metodologii. Jeśli siedzi w codziennym scrum działa dla Ciebie, to f * * * to zrobić. Zmuszanie cię do wstania to po prostu żałosne zniesienie twojej zdolności do samodzielnego myślenia.

Jest reakcja na rodzaj zwinności, który robisz. To jest to. Wydrukuj i przypnij gdzieś, gdy nikogo nie ma w pobliżu, i pozwól im to odkryć.

Obecny mistrz Scrum był menedżerem, który odbył kilkudniowe szkolenie zwinne opłacane przez kierownictwo, teraz prowadzi ten zwinny zespół.

To Twój problem. Kierownictwo chce trochę zwinności, tak naprawdę nie wiedzą, co to jest, i narzucają to zespołom. To właściwie co zrobić, jeśli chcesz znacznie zmniejszyć produktywność programistów;)

Nowa propozycja procesu powinna pochodzić od programistów. Lub przynajmniej przejrzeć je i zatwierdzić, jeśli jest to pomysł kierownictwa.

W każdym razie, jeśli deweloperzy odmówią, nie wdrażaj go ! Albo będzie to katastrofa, którą opisujesz.

„Zwinna” i każda inna „metodologia zarządzania” jest często nadużywana w celu wymuszenia mikrozarządzania na ludziach. OTOH jest czasem nadużywane w celu obrony złego wykonania.

„Jesteśmy zwinni” to najczęstsza wymówka, jaką słyszę z powodu braku planowania, braku myślenia o projekcie, funkcjach, jakości i cyklach wydawniczych. Zazwyczaj pochodzi to od deweloperów i niższego kierownictwa. Jest to również szalenie najczęściej używana wymówka, jaką słyszę od menedżerów średniego szczebla, architektów, sprzedawców itp. W odniesieniu do mikrozarządzania, zawsze zmieniających się terminów i list wyróżniających, wymuszających masowe nadgodziny na ludziach (ciągle zmieniające się terminy i listy funkcji zapewniają to oczywiście) itp. Itp. .

Oba oczywiście są często w bezpośredniej sprzeczności i mogą się zdarzyć w tym samym projekcie.

Aby odpowiedzieć na twoje pierwotne pytanie, czy Agile to nowe mikro zarządzanie, powiedziałbym, że nie.

Najpierw przeczytaj ten (manifest Agile), a zauważysz, że nie rozmawianie ze współtwórcami nie jest wymienione.

W rzeczywistości „Indywidualności i interakcje” jest dokładnie odwrotnością nie rozmawiania ze współtwórcami.

Zwinne powinno być nowe samozarządzanie. Jeśli zwinność jest praktykowana poprawnie, wiele decyzji jest podejmowanych przez klienta i programistę, pracując nad odpowiednio rozbudowaną historią użytkownika, która jest dodawana do zaległości wraz z identyfikacją zadań.

Codzienny scrum dotyczy komunikacji, a nie zarządzania. Będą dyskusje na temat równoważenia priorytetów i obciążenia, ale osoba zarządzana w scrumie jest, mam nadzieję, mistrzem scrum. Jako programista uczestniczę, mówię, co zrobiłem, co zamierzam zrobić i jakiej pomocy potrzebuję. Wtedy mistrz scrum powinien włączyć się do akcji, usuwając przeszkody dla moich postępów.

Zwinne zespoły nie mogą mieć poczucia, że ​​codzienna praca jest zarządzana hierarchicznie. Jeśli decyzje podejmowane są z daleka przez kogoś na szczycie hierarchicznej organizacji, nadszedł czas na decentralizację procesu decyzyjnego! Dla niektórych osób i niektórych organizacji może to być pomost zbyt daleko. Jeśli poniższe informacje nie są zgodne z twoją organizacją:

Żyć Agile Manifesto

„Odkrywamy lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym”.

Unikaj „Poznaj nowego szefa, tak samo jak stary szef”. Pochodź zwinnie w zespole w jak największym stopniu. Czasami dzieje się tak, wybierając koalicję chętnych do wzięcia udziału w próbnym projekcie z wykorzystaniem Agile. Jeśli możesz utworzyć zespół Agile z wolontariuszy lub zaproszonych członków, którzy mają doświadczenie w dobrej pracy zespołowej, mogą to wypracować. Skorzystaj z małego zespołu przy krótkim projekcie, być może dla klienta wewnętrznego lub wysoce dostępnego.

Uwzględnij zmianę. Być może możesz przejść szkolenie, ale może twój budżet jest napięty i pieniędzy po prostu nie ma. Inne możliwości mogą również zapewnić poprawę. Poczytaj trochę, poproś członków zespołu, aby dowiedzieli się, co mogą na temat Agile i nauczali się nawzajem. Być może będziesz w stanie znaleźć nowych lub istniejących pracowników posiadających kwalifikacje do modelowania i kierowania w adaptacji Agile.

Zwinne drużyny są jak drużyny piłkarskie pracujące na rzecz powszechnie rozumianego celu. Od kilku lat jestem częścią zwinnych zespołów, a kluczem jest skuteczna i wydajna komunikacja między wszystkimi zainteresowanymi stronami. Menedżerowie / mistrzowie Scrum są jedynie pomocnikami zespołu, a tradycyjne zarządzanie / mikro zarządzanie zabije ducha zespołu.

W zespołach, w których pracowałem, zachęcamy do grania w gry zespołowe po godzinach pracy, aby poprawić koleżeństwo wśród członków. Zebrałem tutaj te myśli .

Aby odpowiedzieć na twoje pytanie: Nie. Agile nie jest formą mikrozarządzania. Ale jak każde narzędzie, ludzie mogą go używać nieprawidłowo. Zwinność jest cudowna, jeśli jest właściwie wdrażana i gdy ludzie są z nią zgodni.

Moje przemyślenia na temat „Deweloperzy nie rozmawiają z nikim oprócz mistrza scrum”:

Pracowałem wcześniej w miejscu, w którym była to reguła. JEDNAK zasada była bardziej związana z proszeniem ludzi o wykonanie zadań. Na przykład nie mogę losowo pójść do testera i poprosić go o wykonanie testów w ciągu kilku godzin. Muszę porozmawiać z mistrzem scrum, aby mogli omówić ze swoim członkiem zespołu, w jaki sposób ta praca będzie pasować do sprintu, jeśli jest to nagły wypadek (lub jeśli trzeba go zepchnąć do zaległości na przyszły sprint).

W takim przypadku zrozumiałem pojęcie „deweloperzy nie rozmawiają ze sobą”, ponieważ tak naprawdę przełożyło się to na wykonywanie zadań przez jeden punkt kontrolny, dzięki czemu dany programista nie jest przepracowany lub jest tak zajęty wykonywaniem zadań awaryjnych, że nie mogą zrealizować swojego planu robota skończona.

W przeciwnym razie deweloperzy POWINNI rozmawiać ze sobą. Zawsze. Pomaga szybciej pracować z problemami, zbliżyć się do zespołu i szybciej dostarczać.

Żeby zaoferować inną perspektywę: byłem także w środowisku, w którym ludzie myśleli, że deweloperzy „za dużo mówią”. Po przysiadu okazało się, że w rzeczywistości przetłumaczone na „deweloperzy nie są wystarczająco niezależni, aby wykonać własną pracę. Ponieważ wszystko jest tak rozdrobnione, deweloperzy muszą udać się do trzech innych osób, aby wykonać małe zadanie”.

Kiedy więc menedżerowie postanowili przejść na agile, spodziewali się, że pomogą to dostarczyć informacje we właściwe miejsca i powstrzymają fragmentację wewnątrz organizacji. Niektórzy byli rozczarowani, że po wdrożeniu Agile, deweloperzy wciąż biegali w tę iz powrotem. Ale nie zdawali sobie sprawy, że dzieje się to coraz mniej. Zajęło to jednak trochę czasu. Może dlatego, że tak dzieje się w Twojej organizacji, być może ludzie oczekują od firmy sprawnego rozwiązywania problemów z dnia na dzień. To po prostu nie tak działa.

Oryginalny autor Smith Janes mógł dać doświadczenie. Ale to typowe problemy, które znalazłem w projekcie Agile.

1. Większość organizacji, programiści powinni pracować w wielu projektach, w Agile / scrum. Sprinty nigdy nie są uważane za ten fakt. twój Scrum Master zakłada, że ​​powinieneś skończyć z twoimi historiami pod koniec sprintu. Twój Scrum Master może być poświęcony tylko jednemu projektowi, ale nie deweloperom. TO JEST ZAKŁÓCENIE - nie musisz po prostu odbierać telefonu lub zezwalanie na połączenie telefoniczne.
2. Widziałem projekty Agile, w których planowany jest Sprint, Historie zawarte w Sprint, bez skulenia się .. w połowie lub w połowie sprintu .. Programiści stwierdzający, że zależności nie zostały rozwiązane, wymagania lub historia nie są ukończone opowiadane ... jest jednym z nadużyć w większości zwinnych projektów.
3. Testowanie: TTD .. tak, jest bardzo dobre .. ale widziałem większość projektów Agile całkowicie polegających na TTD ... brak zakresu lub czasu na testy funkcjonalne lub testy na ludziach. Kolejne nadużycie ... Wiele Scrum Masters również nie znasz ani nie rozumiesz znaczenia testów funkcjonalnych. Twój fragment kodu może działać idealnie, jeśli nie spełnia potrzeb biznesowych .. jest bezużyteczny .. Dzieje się tak, gdy biznes nie uczestniczy z dużym wyprzedzeniem ... lub uczestnictwo jest ... ale nie odzwierciedla podejmowania decyzji biznesowych .. Na koniec obwiniamy deweloperów, nie dostarczyłeś funkcjonalności .. albo skończy się to zmianą w ostatniej chwili ... bardzo długie godziny, ponieważ twój Scrum master nie chce ponosić winy za niedokończoną historię.

Nadużywaj tutaj ... albo niski udział firmy lub uczestnika nie posiadającego pełnej wiedzy, albo przedsiębiorca odpadający w trakcie sprintu.

1. Nie wszystkie projekty są odpowiednie dla Agile ... Większość menadżerów lub mistrzów scrum nie wie o tym ... Projekty konserwacyjne. Początkowo można założyć, że usterka może zostać wykonana w ciągu 8 godzin, zaakceptowanych w sprincie. Po spędzeniu 4 godzin okazało się, że jest to Java / inny produkt ... (Niedawno miałem do czynienia z defektem związanym z Quartz Scheduler ... wewnątrz naszego projektu) i ta wada może doprowadzić do uaktualnienia produktu / paczki. Sprzedaż z biurokracją, zatwierdzeniem, finansowanie, nowa wersja lub aktualizacja powinny zostać zatwierdzone przez Internal Engineering itp., 5. Kontrola: ten krok wykonuje tylko garść projektów Agile. Jeśli w ogóle zostanie zrobiony .. Zarządzanie, Scrum Master nigdy nie wziął odpowiedzialności za nieudane historie.
2. Parowanie ... Wielu programistów traktuje parowanie jako miejsce nadużyć współpracowników .. krytykuje inne projekty, praktyki kodowania .. rater traktuje jako pracę zespołową., Uczy się od siebie nawzajem ... Kolejny sposób nadużywania Agile / Scrum.

Zwinność to zdecydowanie dobra metodologia. Chyba że twoja organizacja nie przestrzega całkowicie lub nie jest przeszkolona .... Jest nadużywana ... skutki uboczne 60+ godzin pracy / tydzień, obwinianie, niska moralność.

Agile to mikrozarządzanie w przebraniu. W Agile nie ma miejsca na inicjatywę ani kreatywność. Usunęło to zabawę z programowania, aby niekompetentni menedżerowie mogli zachować kontrolę nawet bez pojęcia z technicznego punktu widzenia.