Czego potrzebujesz, aby odnieść sukces dzięki Agile?

W niektórych organizacjach adopcja zwinna może się nie powieść, pracowałem nawet dla firmy, w której wodospad był jedynym (prawdziwym) sposobem, ale tylko dlatego, że wypróbowali Agile przy projekcie i zawiodły.

Kiedy zapytałem ludzi, którzy wciąż pamiętali, że (byłem młodszy), byłem mocno zamknięty, jakbym przypominał im zły koszmar, który naprawdę się wydarzył.

Nie wiem, dlaczego projekt się nie powiódł. W Internecie można znaleźć zasoby, z których wynika, że ​​zwinność Agile to niektóre firmy, ale przyczyny są głównie ekonomiczne. Pomyślałem więc, że poproszę tutaj o opinie.

Jakie są przyczyny niepowodzenia Agile w niektórych organizacjach? Lub, inaczej mówiąc… Czego potrzebujesz, aby odnieść sukces w Agile?

Potrzebujesz kadry zarządzającej, klientów i programistów, aby zrozumieć i wspierać zwinny sposób myślenia i metody zwinne. Bardziej szczegółowo:

• Kierownictwo musi czuć się komfortowo, słysząc prawdę, w przeciwieństwie do tego, czego tradycyjnie oczekują, aby usłyszeć (tj. „Tak, projekt jest na dobrej drodze” przez 11 miesięcy ... a potem nagle „Ups, musimy opóźnić termin o kilka tygodni ... eee, miesiące ... eerm ... "na samym końcu). Muszą też czuć się swobodnie, pozwalając każdej ze stron wykonywać (i ponosić odpowiedzialność) swoją pracę. Najważniejsze, że programiści podejmują techniczne decyzje i szacunki. Więc nie ma ścisłej kontroli i mikro-zarządzania.
• Klienci muszą zrozumieć, że Agile wymaga ich głębokiego i ciągłego zaangażowania w proces rozwoju, a nie tylko „złożenia zamówienia”, a następnie odebrania dostawy kilka miesięcy później. Muszą też czuć się komfortowo z powodu braku specyfikacji dużych stałych wymagań i widocznego braku zaangażowania zespołu programistów w dostarczanie tego, o co początkowo zostali poproszeni.
• Deweloperzy muszą swobodnie przyjmować odpowiedzialność, podejmować decyzje, otwarcie się komunikować i pracować w zespole. Nie oznacza to „własności kodu”, „samotnych kowbojów” i bezowocnego obwiniania innych za problemy, które sam zespół może rozwiązać.

Z mojego doświadczenia wynika, że ​​jest to pierwszy punkt, który najczęściej kryje się za nieudanymi projektami Agile, ale pozostałe dwa mogą również powodować problemy.

Aktualizacja

Przez „zarządzanie” rozumiem nie tylko bezpośredniego kierownika projektu, ale także wyższe poziomy. Jak bardzo słusznie zauważył @Michael, niektóre mniej lub bardziej zewnętrzne podmioty (np. QA lub zewnętrzny podmiot przydzielający zadania) mogą również wpływać na sukces / porażkę projektów Agile, ale przypuszczam, że jest to możliwe tylko wtedy, gdy pozwala na to ich lider i / lub jeśli obowiązki i linie dowodzenia nie są jasne w organizacji.

Potrzebujesz:

• Ludzie, którzy chcą być bardzo otwarci i szczerzy . Widoczność jest najważniejsza, ponieważ potrzebujesz zaufania na wszystkich rodzajach granic warstw.
• Klienci i menedżerowie, którzy naprawdę chcą usłyszeć prawdę.
• Ludzie, którzy chcą i potrafią na nowo zdefiniować swoje role, tak aby odpowiadały potrzebom w tej chwili .
• Wolność do zmiany procesów, które nie pracują w tej chwili .
• Ludzie, którzy są gotowi przyznać się do błędów i je odwrócić .
• Możliwość rzucać razem środowisk budowy i testowania do woli . (Jest to ważniejsze i droższe niż ludzie to przyznają).
• Tyle tablic, ile możesz wypełnić ścianami.

Wydaje się to takie proste, ale wiele z nich to duże pytania w tej branży.

Zwinny projekt najczęściej kończy się niepowodzeniem, gdy kluczowy gracz odmawia zwinności lub (gorzej), gdy ktoś nie jest szczerze zainteresowany sukcesem projektu lub wręcz go sabotuje. Ten ostatni może zabić każdy projekt (podobnie jak wiele innych rzeczy), ale zwinne procesy dają ludziom większą elastyczność, w tym elastyczność prowadzenia destrukcyjnej polityki.

Przykłady:

• Kontrola jakości nalega, aby klienci nie widzieli oprogramowania, chyba że przejdzie miesięczny cykl testów ręcznych
• Zarządzanie nakłada nierealistyczne terminy
• Klient odmawia priorytetyzacji wymagań („ wszystkie mają najwyższy priorytet!”)
• Ktoś, kto nie jest bezpośrednim interesariuszem, ale ma siłę polityczną, wciąż przypisuje długie, niepowiązane zadania kluczowemu członkowi zespołu, a kierownik projektu nie może temu zapobiec.

Mogę udzielać rad jedynie na podstawie własnego doświadczenia.

Jeden pracodawca, którego kompletnie zawiodłem w Agile. Prace były wykonywane na zasadzie ad hoc, testy nie istniały, a wymagania zostały udokumentowane w wiadomościach e-mail i protokołach ze spotkań. Jedyną zastosowaną metodą rozwoju była anarchia, czyli „kodowanie ogniowe i zapomnienie”. Wdrożenie jakiejś metody inżynierii oprogramowania byłoby niemożliwe, ponieważ programiści byli zbyt przepracowani, aby skonfigurować oprogramowanie do zarządzania projektami do śledzenia historii.

W innym pracodawcy nasz zespół miał heroicznego członka, który desperacko próbował ustanowić najlepsze praktyki Agile - mieliśmy tablicę Kanban, śledzenie problemów, korzystaliśmy z TDD i BDD (chociaż same w sobie nie są Agile, zwykle są obecne w grupach Agile) . Niestety brakowało nam takich rzeczy, jak punkty fabularne, sesje szacunkowe, planowanie wydajności, wykresy wypalenia, wykresy prędkości - rodzaj przydatnych narzędzi Agile do zarządzania projektami, które umożliwiają płynny przepływ pracy. Jako klasyczny objaw błędu Agile, kiedy nasza tablica Kanban się zapełniła, kupiliśmy większą płytę: /

Miejsce, w którym obecnie przebywam, wykorzystuje punkty historii jako sposób planowania pojemności z dwutygodniowymi iteracjami, TDD, codziennymi awariami, retrospektywnymi iteracjami po iteracji i programowaniem par w większości rzeczy. Wynika to z całkowitego zaangażowania zarządu i edukacji klientów.

Uważa, że ​​aby Agile odniosło sukces w firmie, potrzebujesz następujących rzeczy:

• Kierownicy projektów, którzy rozumieją Agile i którzy będą odpowiednio korzystać z narzędzi.
• Programiści, którzy rozumieją Agile, są otwarci i szczerzy, z dyscypliną wymaganą przez Agile
• Wpis od klienta. Muszą docenić zalety Agile i chętnie słuchają rad od swoich programistów w zakresie tego, co można opracować w określonym przedziale czasowym.

EDYCJA: Konieczne jest również upewnienie się, że dobrze rozumiesz, dlaczego przydatne są codzienne stójki i krótkie iteracje.

Moje doświadczenia z porażką Agile nie miały nic wspólnego z ekonomią, ale z polityką korporacyjną / departamentalną / osobistą.

Na poziomie osobistym są po prostu ludzie, których osobowości się zderzą. Zmuszenie ich do zwinnego zespołu, a nawet gorzej sparowanego zespołu programistycznego, zwiększy ich niechęć do siebie do punktu wrzenia. To może stać się bardzo nieprzyjemne, bardzo szybko i skutkować takimi aktami sabotażu, które są warte reality show, zmieniając spotkania scrumowe w okrągłą drużynę strzelającą do winy, a nawet gorzej.

Ponadto istnieje zarządzanie programowaniem. Widziałem, że dzieje się to źle na dwa różne sposoby.

Pierwszy to „kult kultu zwinnego”, w którym kierownik nalega na przestrzeganie manifestu i jakiejkolwiek klasy / książki / strony internetowej, którą dokładnie przeczytali, nie rozumiejąc powodu, dlaczego i kiedy ich używać, a kiedy improwizować. To tak, jakby menedżer Agile czeka na magię, ponieważ dokładnie śledzi zaklęcie. Ta procrustowa implementacja Agile może spowodować szereg problemów, które doprowadzą do niepowodzenia projektu.

Drugi to „Agile In Name Only”, w którym używana jest terminologia, taka jak sprinty i scrum, ale tak naprawdę to tylko etykiety starych praktyk, takich jak mikro-zarządzanie, nieuczciwość w górę iw dół łańcucha dowodzenia, długie bezużyteczne spotkania o statusie i inne tego typu rzeczy . Projekty kończą się niepowodzeniem, tak jak kiedyś, ale teraz Agile można winić za to, a nie za złe zarządzanie.

Powyżej jest brak wpisu ze strony klienta / klienta projektu. Osoby te będą miały własne priorytety wydziałowe i mogą być odporne na współpracę z zespołem programistycznym, chyba że zostanie wyraźnie zaznaczone, że jest to istotna część ich pracy przez ich kierownictwo. Może to pogorszyć polityka departamentalna lub polityka korporacyjna. Na przykład, zarówno operacje, jak i marketing mają wkład w projekt, a twój zespół obraca się w kółko, ponieważ obie strony nie mogą się z niczym zgodzić. Innym przykładem jest konflikt między polityką korporacyjną dotyczącą zarządzania czasem i fakturowania. Odkryłem, że łatwiej było sobie radzić z klientami zewnętrznymi niż wewnętrznymi. Podobało im się skupienie na tym procesie i wiedzieli, że dostają wartość swoich pieniędzy.

IMO „Agile” kończy się niepowodzeniem, gdy nie ma hurtowego zakupu tych praktyk. Mam na myśli to, że Agile polega na „kliencie” (zazwyczaj innym dziale lub menedżerze), rozumiejąc, że:

1. Nie wiedzą w 100%, co chcą robić od oprogramowania, nawet jeśli myślą, że tak
2. Nie mają pojęcia, ile czasu zajmie ukończenie, nawet jeśli uważają, że tak
3. Powiedzą im, jak długo to potrwa i muszą je zaakceptować lub ograniczyć funkcje, aby dotrzymać terminu
4. Będą musieli wybrać funkcje każdej iteracji i nie otrzymają pełnej, w 100% kompletnej aplikacji za jednym razem.

Wszystkie te rzeczy są bardzo trudne do przełknięcia dla większości menedżerów, a IMO jest pierwszym powodem, dla którego trudno jest wykonać Agile - menedżerowie są przyzwyczajeni do powiedzenia „To będzie zrobione przed x datą” i do wykonania tego „Magicznie” do tej daty (po tym, jak programiści wprowadzili w 80-godzinne tygodnie) i jest 180, aby zdać sobie sprawę, że zespół programistów powie ci, że ten projekt zostanie ukończony za 3 miesiące, a jedynym wyborem, jaki masz, jest zaakceptowanie go lub zmniejszenie wymagań, aby uzyskać zrobiono to wcześniej.

Po drugie, należy zaufać zespołowi programistów. Idąc w parze z punktem 1 powyżej, bardzo niewielu menedżerów wydaje się ufać opinii osób zatrudnionych jako eksperci; jeśli programista twierdzi, że projekt zajmie x czasu, a x to więcej niż kierownictwo myśli, że zajmie, to nigdy nie jest to przypadek „Nie wiem, jak pisać oprogramowanie, więc programista prawdopodobnie ma rację” to więcej ” Ci bezużyteczni programiści chcą wygłupiać się w pracy, więc powiedzieli, że zajmie to 3 miesiące ”.

Po trzecie, Twój zespół programistów musi stać za Agile; oznacza to, że nie skracamy kątów i nie ignorujemy ciągłych informacji zwrotnych i pytań „Czy to prawda? Kiedy x się zdarzy, co powinien zrobić Y”? Nawet jeśli nie postępujesz zgodnie z TDD lub programowaniem w parach, Twój zespół programistów musi być wystarczająco kompetentny, aby postępować zgodnie ze zwinnymi procesami (np. Sprinty, iteracje). Wymaga to posiadania lidera / menedżera, który potrafi właściwie oszacować zadania i rozumie, że nie musisz nadawać priorytetu każdej funkcji, możesz mieć zaległości w pracy i nie powinieneś przepracowywać ludzi.