5 faktów o transformacji zwinnej

Nigdy nie byłem fanem horrorów. Ale Halloween zawsze mi się podobało. Jako dziecko uwielbiałem wkładać przerażające kostiumy i straszyć nimi przyjaciół i innych ludzi. I przyznam, że lubię dreszczyk emocji towarzyszący wejściu do dobrze przygotowanego domu strachu w Halloween.

Jednakże przy każdej transformacji agile są też aspekty, które mogą przyprawić o zimny dreszcz – i te chwile nie są tak ekscytujące.

Przeanalizujmy więc wspólnie te pięć rzeczy i porozmawiajmy o tym, czym dokładnie są i dlaczego nie są tak straszne, gdy się je właściwie zrozumie.

1) Ahhh! W Agile nie ma fazy projektowania!

Architekci i pracownicy działu programistycznego często są zaniepokojeni brakiem wyraźnej fazy projektowania w Agile. Choć prawdą jest, że zwinne zespoły unikają faz projektowania na początku projektu, nie oznacza to, że projektowanie jest zaniedbywane.

Projektowanie w projekcie agile charakteryzują dwie cechy: jest emergentne i intencjonalne.

Emergentne projektowanie kształtuje się z czasem. Zamiast początkowej fazy projektowania, projektowanie jest procesem ciągłym. Design powstaje podczas tworzenia oprogramowania.

Projektowanie jest jednak też intencjonalne. Oznacza to, że design nie powstaje przypadkowo. Jest kierowany przez doświadczonych pracowników technicznych projektu lub nawet konkretnego architekta.

Gdy te osoby martwią się o jakąś część systemu, Product Owner powinien spriorytetyzować jeden lub dwa [Product Backlog Items]( "Product Backlog Item") z tego obszaru. Daje to zespołowi szansę na bliższe poznanie tej części systemu poprzez opracowanie jej niewielkiego fragmentu. Pomoże to znaleźć właściwy projekt dla tego obszaru.

Gdy design powstaje w ten sposób przez decyzje zespołu, fakt, że w Agile nie ma wyraźnej fazy projektowania, przestaje być straszny.

2) Pomocy! Staję się generalistą!

Jednym z najbardziej rozpowszechnionych mitów w Agile jest to, że zwinne zespoły nie chcą specjalistów i zamiast tego chcą, żeby każdy w zespole był generalistą.

Wiele osób boi się tego z dwóch powodów: po pierwsze, nie każdy lubi wykonywać każdy rodzaj pracy. Po drugie, często pojawia się obawa, że posiadanie czterech rzeczy na pół przyzwoitym poziomie zamiast jednej na poziomie doskonałym może w przyszłości wpłynąć na atrakcyjność na rynku pracy.

Wyobrażenie, że każdy w zwinnym zespole musi być generalistą, jest błędne. Gdy coahuję zespół, który ma najlepszego specjalistę JavaScript na świecie, chcę, żeby ta gwiazda robiła świetne rzeczy z JavaScript, a nie żeby uczyła się być administratorem bazy danych.

Tak, w zwinnych zespołach chce się mieć członków z różnorodnymi umiejętnościami: na przykład testera, który też trochę koduje. Najprościej jest mieć kogoś, kto równie dobrze wykonuje oba rodzaje pracy. Jeśli na przykład Twój zespół ma nierównowagę w zakresie prac programistycznych i testowych, pomocne jest posiadanie w zespole kogoś, kto może zarówno programować, jak i testować.

Jednym z celów w Agile jest tworzenie interdyscyplinarnych zespołów. Oznacza to, że zespół posiada wszystkie umiejętności potrzebne do stworzenia gotowego, działającego przyrostu produktu w iteracji. Nie oznacza to jednak, że każdy członek zespołu musi posiadać każdą umiejętność potrzebną w interdyscyplinarnym zespole.

Jeśli myśl o zostaniu generalistą jeży Ci włosy na głowie, będziesz mieć ulgę dowiadując się, że specjaliści są mile widziani również w interdyscyplinarnych zespołach.

3) O nie! Nie mamy ani planów, ani prognoz!

Menedżerów często przeraża myśl, że zwinny zespół nie może planować ani prognozować poza bieżącą iteracją lub Sprintem.

Na szczęście nie jest to do końca prawdą.

Tak, zwinne zespoły rezygnują ze złudnego komfortu nadmiernie zaplanowanych projektów z nieprzejrzystymi wykresami Gantta i dokładnymi harmonogramami daleko w przyszłość. Nie oznacza to jednak, że zwinne zespoły nie są w stanie planować i prognozować przyszłości.

Dużą zaletą metod zwinnych jest to, że zespół w każdej iteracji przegląda i dostosowuje cały proces programistyczny. Bierze pomysł w postaci prostej User Story i implementuje tę funkcję. Oznacza to, że zespoły mogą mierzyć swoje postępy co kilka tygodni. W ten sposób dowiadują się, ile pracy potrafią wykonać.

Porównajmy to z tradycyjnym projektem programistycznym, który może mieć fazę analizy, fazę projektowania, fazę kodowania i na koniec fazę testowania. Gdy takie zespoły chcą mierzyć swoje postępy, mogą za każdym razem jedynie stwierdzić, jak szybko wykonują jedną (lub może dwie) z tych prac. Szybkość projektowania przez zespół nie mówi nic o tym, jak szybko radzi sobie z kodem lub testowaniem.

Najważniejsze przy transformacji agile jest zaakceptowanie niepewności – przyznanie, że niemożliwe jest poznanie całej funkcjonalności przed rozpoczęciem projektu – a następnie wybranie jednej z wielu metod dostosowania się do niej. Gdy zespoły to zrozumieją i będą mierzyć ilość pracy w każdej iteracji, powinno to uspokoić management i prowadzić do wiarygodnego planowania.

4) Pomocy! Stracę pracę!

Wyobrażenie transformacji agile zespołu lub całej firmy może naprawdę przestraszyć niejednego menedżera, bo wielu obawia się, że po transformacji ich stanowisko stanie się zbędne.

To zrozumiałe. Oczywiście byłoby straszne, gdyby rozpoczęcie transformacji miało oznaczać, że własna rola staje się niepotrzebna.

Nigdy jednak nie pomagałem firmie w transformacji agile i nie słyszałem, żeby powiedziano: „Okej, osoby pełniące taką i taką rolę nie są nam już potrzebne. Wszystkie zostaną zwolnione." To się nie stanie. Oczywiście może się zdarzyć, że dany tytuł stanowiska nie jest już potrzebny lub adekwatny, ale te osoby nadal mają pracę. Wierzę nawet, że w większości przypadków wychodzą na tym lepiej, z pracami bardziej dostosowanymi do ich potrzeb niż wcześniej. Pewnie jest tak, że niektóre osoby mają przez to mniejszą bezpośrednią kontrolę nad pracownikami i decyzjami i są z tego powodu sfrustrowane – czasem nawet tak sfrustrowane, że odchodzą z firmy.

Ponieważ nigdy nie widziałem, żeby osoby o określonych rolach lub umiejętnościach były po prostu zwalniane przy transformacji agile, uważam, że strach przed tym jest tak nieuzasadniony jak strach przed apokalipsą zombie.

5) Uhhh! W Scrumie jest za dużo spotkań!

Jak większość ludzi, nienawidzę spotkań. Ogólnie rzecz biorąc, chodzi mi o to, dlaczego robię to, co robię. W większości dni nie mam w ogóle żadnych spotkań. Co za szczęście.

Mimo to nawet ja mogę przyznać, że niektóre spotkania są ważne i użyteczne. Dotyczy to czterech standardowych spotkań w Scrumie: Sprint Planning Meeting, Daily Scrum, Review i Retrospektywa.

Sama myśl o wszystkich tych spotkaniach sprawia, że niektóre osoby pocą się ze strachu.

A problem ze spotkaniami w Scrumie polega na tym, że mają nazwy. Gdy coś ma nazwę, można to łatwiej atakować. Z mojego doświadczenia wynika, że większość zespołów przed Scrumem miała więcej spotkań. Te spotkania jednak nie miały nazw i były najczęściej zwoływane spontanicznie, żeby wyjaśnić konkretne kwestie.

Można to szybko sprawdzić eksperymentem. Znajdź w swoim kalendarzu dowolny miesiąc, w którym nie pracowałeś jeszcze z Agile. Zsumuj czas, który spędziłeś w tym miesiącu na spotkaniach. Następnie zsumuj czas, który teraz spędzasz na spotkaniach Scrum i porównaj obie liczby.

Myślę, że wynik Cię zaskoczy. Ponieważ spotkania w czasach przed transformacją agile nie odbywały się regularnie i powtarzalnie, nie miały nazw i dlatego nie zapadały w pamięć tak jak np. „Sprint Planning Meeting".

Najważniejsza wskazówka, żeby przestać bać się spędzania zbyt dużo czasu na spotkaniach, to krótkie spotkania. Od czasu do czasu pracuję z zespołami, które muszę zachęcać do poświęcania nieco więcej czasu na spotkania.

Większość zespołów spędza jednak zbyt dużo czasu na spotkaniach Scrum. Gdy uda się je skrócić i utrzymać zwięzłość, nie powinny już nikomu sprawiać strachu.

Podsumowanie: Zrelaksuj się… te duchy nie są prawdziwe!

Chodzenie przez dom strachu i przebieranie się jest zabawne, bo wszyscy wiemy, że to tylko pozory. Duchy, potwory, wampiry, wilkołaki i szaleńcy z piłą łańcuchową nie są prawdziwe.

I te pięć agile'owych mitów opisanych tutaj też nie jest prawdziwe. Nie ma nic złego w byciu trochę przestraszonym na początku. Edukacja i doświadczenie szybko jednak zdemaskują te mity i dadzą Ci poczucie bezpieczeństwa.

Jeśli jednak sam chcesz zobaczyć agile'ową rzeczywistość i mity o Scrumie i spółce, rzuć okiem na naszą Agile Journey, gdzie dokładnie przedstawiamy role, albo zostań teraz certyfikowanym Scrum Masterem lub odwiedź nasze Agile Leadership Training.

Ten tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.

Innowacje w firmie

=> Co wyróżnia innowacyjne firmy?

Realizowana strategia

=> Dowiedz się, jak przenieść swoją strategię firmy na wyższy poziom.

Niepokonane firmy

=> Jak wygląda nowoczesne zarządzanie innowacjami w firmie?