Agile, czyli metodyka zwinna, a może wcale nie metodyka? Czym jest Agile i 12 zasad AGILE „metodyki” zwinnej? Kiedy w ogóle stosować Agile? Jakie są zalety prowadzenia projektów wg Agile? Dzisiaj wszystko, co warto wiedzieć o Agile i o metodykach zwinnych na start.
“Metodyka” Agile
Dlaczego słowo metodyka wrzuciłem w cudzysłów? Bo Agile jest na tyle modnym słowem, że przyczepia się do wszystkiego. O metodyce powiem czy jest czy nie jest, jak o tym myśleć, bo dużo osób jak usłyszy Agile to myśli, że tam jest pewne rozwiązanie na wszystkie problemy.
Co to jest Agile? Zacznijmy od definicji Agile to iteracyjne podejście do zarządzania projektami i tworzenia oprogramowania, które pomaga zespołom dostarczyć wartość klientom szybciej i przy mniejszej liczbie problemów. Zamiast stawiania wszystkiego na jedno wielkie wdrożenie zespoły Agile dostarczają pracę w niewielkich ale użytecznych przyrostach. (źródło definicji: attlasian.com/pl/agile).
W skrócie jak myśleć o Agile – to pewien sposób podejścia do wytwarzania czegokolwiek. Nie chcesz tego robić na zasadzie dużej kobyły, gdzie najpierw sobie zaplanujesz, później przygotujesz i czekasz na wynik. Agile powstało, dlatego, że są sytuacje, w których nie do końca wiesz co chcesz uzyskać. Wtedy planowanie, myślenie nic nie da, bo niektóre rozwiązania można zrobić tylko wtedy, gdy robi się je w trakcie doprecyzowując. Popełniasz dużo błędów, żeby sobie uświadomić o co naprawdę chodzi. Są projekty, które w ten sposób warto poprowadzić, ale są też projekty, w których już ktoś dobrze wymyślił pewne rzeczy i tam nie ma co wydziwiać. Tradycyjne projekty typu budowa mostu, wiesz jakie są zasady budowania mostów, zbudowano ich miliony, jest więc pewna rama według której będziesz postępował. Jednocześnie w trakcie wytwarzania możesz działać w zwinny sposób, bo na froncie robót dzieją się różne rzeczy – coś nie dojedzie, coś się zmienia, mimo całej analizy coś idzie nie tak. W skrócie zwinność polega na tym, żeby nie zakładać, że jesteś w stanie wszystko przemyśleć od początku do końca, tylko ruszyć w drogę i dać sobie prawo do dopracowania rozwiązania w trakcie. To jest esencja Agile. Problemy będą inne niż w projektach, w których dokładnie wiesz co robisz.
SCRUM, Lean, Kanban, Extreme Programming i inne
Powstało bardzo dużo rozwiązań, które jakoś starają się filozofię Agile przełożyć na narzędzia, metody i techniki, które można wykorzystać. Są podejścia bardziej lżejsze i takie, które są bardziej złożone.
Do tych lżejszych będzie należał SCRUM, gdzie cała metoda jest opisana, cały framework jest opisany na 16 czy 20 stronach, nigdy nie pamiętam, ale to małą ilość. Mówi o tym, że jak będziesz pracować w ten sposób to zachowasz zwinne zasady, jednocześnie masz zespół, który dostarcza wartość kawałkami i to wszystko rośnie.
Lean software development to połączenie podejścia z produkcji z software. Kanban, Extreme Programming – wykorzystywałem częściowo to podejście jak tworzyłem moja własną metodę.
Zwinność u źródła dotyczyła małych zespołów, bardzo dziwne jest to, że ta zwinność faktycznie działa przy mniejszych zespołach, a przy większych logika zaczyna się załamywać. Ludzie dążyli do tego, żeby stosować podejście Agile na większych zespołach i tak powstało Scrum-of-Scrums, Large-scale Scrum, Scaled Agile Framework itd. Jest cała masa metod, które mówią o zwinności na większą skalę. Nie neguję ich, warto rozumieć dlaczego takie powstały i gdzie możesz je zastosować, bo nie ma szansy, żeby wybrać z tego coś w miarę szybko.
Dzisiejszy film to kolejny odcinek, w którym bierzemy pod lupę Scrum Guide. Opowiem o teorii i filarach empiryzmu w Scrumie, czyli przejrzystości, inspekcji oraz adaptacji.
Definicja SCRUM
Definicja jest następująca – SCRUM to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.
Pierwsza bazowa rzecz – uproszczone ramy postępowania, ma być proste, daje pewną perspektywę w której działamy i pokazuje jak działać, żeby osiągnąć pewien rezultat. Wytwarzanie wartości – nie chodzi o to, żeby pracować więcej, tylko, żeby na koniec mieć rezultaty. Adaptacyjne rozwiązywanie złożonych problemów – adaptacyjne oznacza, że uczymy się. Musimy się nauczyć jak doprowadzić do danego rozwiązania, jak ze sobą pracować. Scrum nie powstał po to, żeby go używać do każdej rzeczy, to odpowiedź na sytuacje, gdzie mamy złożony problem, którego nie da się łatwo przeanalizować. Scrum to ramy postępowania, które pozwalają ci przepracować taki problem i przerobić na kawałki pracy, które da się przerobić, zebrać feedback i poprawić. Jeżeli zespół nie ma jasności jak coś zrobić to można wpaść w pułapkę, to nie róbmy, albo poczekajmy aż ktoś powie. Całe rozwiązanie kryje się pod spodem. Jak natrafisz na taką sytuację to Scrum jest dobrym pomysłem. Cynefin framework jest jednym z najfajniejszych modeli opisujących rzeczywistość, że nie jest ona jednoznaczna. Jedne projekty są poukładane, inne chaotyczne.
Teoria Scrum
Po kolei, zobaczmy co mówi nam Scrum Guide o teorii Scrum. “Fundamentem Scruma jest empiryzm i koncepcja lean. Istotą empiryzmu jest to, że wiedza wynika z doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować.” To teraz się zastanówmy. Według mnie wiedza wynika też z innych źródeł, nie tylko z doświadczenia i tego co można zaobserwować. Warto robić to co mówią starsi, bardziej doświadczeni. Jak mówią nie rób tego, to warto posłuchać, po to, żeby się nie wpakować w problemy. To oczywiście oznacza, że pewnego doświadczenia nie zdobędziesz, ale to oszczędza życie. Nie jest tak, że nie zgadzam się ze stwierdzeniem z przewodnika, faktycznie tak jest, że dostajesz jakieś zasady, na nich pracujesz i dopiero jak doświadczysz pojawia się głębsze zrozumienie. Kwestia wyważenia tego w praktyce. Potrzebujemy czegoś doświadczyć, żeby zebrać z tego głęboką wiedzę, to jak najbardziej ma sens.
Jeśli nie wiesz jeszcze na czym polega zarządzanie projektami, na pewno warto odwiedzić artykuł – Zarządzanie Projektami – co to właściwie jest.
“Koncepcja lean ogranicza straty i koncentruje się na tym co najważniejsze.” Jak najbardziej się z tym zgadzam. Weźmy się do roboty i skupmy na tym, żeby nie robić roboty bez sensu, dla samej formy.
“Scrum wykorzystuje iteracyjne, przyrostowe podejście w celu zwiększania przewidywalności oraz kontrolowania ryzyka.” Jak to tłumaczyć sobie na życie? To oznacza małymi krokami do przodu, dlatego, że trudniej dzięki temu wpaść w przepaść. Scrum został zaprojektowany i działa dobrze w pewnym środowisku, w którym małymi kawałkami musisz zorientować się o co chodzi. Skakanie w przepaść skończy się słabo. Dlatego przy projektach złożonych w których robi się podejście Waterfallowe, jak nie wiadomo z czym się będziemy mierzyć, prawdopodobnie strzelimy sobie w kolano. Dlatego iteracyjnie krok po kroku Scrum prowadzi nas dalej.
“Scrum polega na pracy grup osób wspólnie posiadających wszystkie umiejętności oraz specjalistyczną wiedzę potrzebne do wykonania pracy oraz dzielą się tymi umiejętnościami bądź nabywają je w miarę potrzeby.” Albo masz ekspertów, których zebrałeś i wiedzą o co chodzi, albo masz przestrzeń na ich rozwój. Pytanie jak to jest u Ciebie. To ważny punkt filozofii. Dostajesz ludzi, którzy są nowi, nie ma czasu na ich rozwój i jedziemy, to nie jest dobre. Pozyskiwanie wiedzy jest częścią projektu. Zabudżetowanie sobie części czasu, pieniędzy na to, żeby się nauczyć to dobry pomysł.
“W Scrumie odbywają się cztery formalne wydarzenia umożliwiające inspekcję i adaptację w ramach obejmującego je wszystkie wydarzenia jakim jest Sprint. Wydarzenia te są konstruktywne i produktywne, ponieważ tworzą filary empiryzmu w Scrumie, czyli przejrzystość, inspekcję i adaptację.” To jest genialne, ze względu na prostotę, a te wydarzenia które się dzieją wyciągają wszystko na wierzch. Ludzie muszą zobaczyć jak jest, dać sobie feedback, nie ma za dużo miejsca na kombinowanie. Scrum jest skonstruowany tak, żeby zebrać doświadczenie, wartość i podziałać.
Pierwszy filar empiryzmu w Scrum – Przejrzystość
Promuję to gdziekolwiek się da, jeżeli nie wiesz jak jest naprawdę i tworzysz kulturę, w której bardziej opłaca się coś zamiatać pod dywan to podejmujesz decyzje na ślepo. Jest taki okres, szczególnie na początku, że nie wiesz co się dzieje i działasz bardziej na czuja. W pewnym momencie zaczynasz zbierać dane i możesz mierzyć się z rzeczywistością. “W Scrumie ważne decyzje podejmowane są na podstawie zaobserwowanego stanu jego trzech artefaktów.” Minimalna ilość artefaktów w Scrumie ma spory sens. Wiesz w każdym momencie co się dzieje, to prowadzi do sytuacji, w której możesz podejmować sensowne decyzje. “Przejrzystość umożliwia inspekcję” Jak nie wiesz, nie możesz zajrzeć jak działa mechanizm, to nie jesteś w stanie przejść do kolejnego etapu. “Inspekcja bez przejrzystości prowadzi do błędów i strat.” Dlaczego nie wszyscy mogą chcieć przejrzystości? Jak spojrzymy na statystyki problemów w projektach, to 55% ma problem z tchórzem projektowym. Ludzie nie mówią jak jest naprawdę, bo bardziej opłaca im się ukryć prawdę, albo zwalić winę na kogoś innego. Ponad 80% projektów ma problem z manipulowaniem priorytetami. Im bardziej to jest mgliste tym większa szansa, że ugrasz coś dla siebie. Jest dużo elementów, które sprawiają, że przejrzystość wcale nie jest prosta dla wdrożenia, ale bez niej nie ma efektywności. Nie zrobimy sensownej inspekcji i nie poprawimy tego co się dzieje.
Drugi filar empiryzmu w Scrum – Inspekcja
“Artefakty Scruma oraz postępy w dążeniu do uzgodnionych celów muszą być poddawane częstej i rzetelnej inspekcji, aby możliwe było wykrycie potencjalnie niepożądanych odstępstw lub problemów.” Wracamy do cyklu Deminga, esencją Inspekcji jest stanięcie w prawdzie. Jak naprawdę jest, to fajne doświadczenie, które warto samemu sobie przećwiczyć, stanięcie w prawdzie jak jest. Nie chodzi o kontrolę, chodzi o sterowanie, zobaczenie jak jest i podjęcie sensownych decyzji. “Aby to ułatwić Scrum zapewnia stały rytm w postaci pięciu wydarzeń.” Stały rytm pozwala na wyeliminowaniu błędu pomiaru. Jeżeli w różnych odstępach czasu sprawdzasz projekt, to trudno jest sprawdzić skąd wynikają odchylenia pod kątem dostarczeni zakresu. “Inspekcja bez adaptacji jest uznawana za bezcelową.” Czy czasem spotkania statusowe nie są sztuką dla sztuki? Spotykacie się, nic z tego nie wynika, nie ma przypisanych osób i następnych kroków. Po co sprawdzać jak jest, jeżeli nic z tym nie zrobimy. Inspekcja nas kosztuje, więc wyciśnijmy z niej jak najwięcej. “Celem wydarzeń w Scrumie jest wywoływanie zmian.” Warto popatrzeć na to głębiej. Stałe doskonalenie, świadomość tego, że musimy się zmieniać. Jak zaczyna zespół ze sobą pracować to dużo rzeczy nowych zaczyna wyskakiwać, jeżeli podchodzimy z podejściem adaptacyjnym, będziemy musieli się zmieniać to szczególnie na starcie warto wyciągać jak jest, co się dzieje. W Scrum każda zmiana ma swój koszt, jeżeli jest to transparentnie pokazane to klient wie, że jeżeli chce wrzucić więcej pracy do zrobienia, to musi za to zapłacić kosztem nie zrobienia czegoś innego.
Trzeci filar empiryzmu w Scrum – Adaptacja
“Jeśli jakikolwiek aspekt procesu wykracza poza dopuszczalne limity lub jeśli uzyskany produkt jest niemożliwy do zaakceptowania stosowany proces lub wytwarzane materiały należy odpowiednio skorygować.” Jeżeli ustalamy jakieś limity, to ustalamy też jakiś poziom efektywności. Musimy mierzyć, sprawdzać ja jest. Plan jest po to, żebyśmy mieli się od czego odchylać. Jeżeli produkt jest słaby to wyciągnijmy, że nie pasuje, poprawmy jak najszybciej.
“Oczekuje się, że Scrum Team wprowadzi modyfikacje natychmiast po uzyskaniu jakiejkolwiek nowej wiedzy w wyniku inspekcji.” Słusznie. Kojarzycie taki obrazek, gdzie goście pchają na kwadratowych kołach, jeden przychodzi z kółkiem a oni mówią, że nie mają na to czasu. Pytanie czy masz czas naprawić taczki. Ten czas też powinien być wpisany w zakres.
Podsumowując empiryzm i lean. Doświadczenie i staramy się zrobić to prosto. Przejrzystość, wiemy jak jest, dopasowujemy się. To esencja.
VIDEO
Skąd się wziął Agile
Zaczęło się od spotkania kilkunastu doświadczonych managerów IT, którzy pracowali nad tym jakie sposoby zarządzania wytwarzaniem oprogramowania będą najlepsze. Stworzyli Manifest zwinnego wytwarzania oprogramowania. W skrócie chodziło o to, że IT miało taki problem, że przychodził np. dział sprzedaży z komunikatem “zróbcie mi, żebym miał raporty ze sprzedaży”, 9 miesięcy później ktoś dostawał gotowy produkt od IT, następnie szedł komunikat “ale nie o to nam chodziło”. Ponieważ IT się zamykało w swojej jaskini, dwa różne światy, nie rozumieli się wzajemnie, na koniec powstawało coś z czego nikt nie był zadowolony. Nie można było pokazać wartości.
Powstał więc manifest, który skupia się na kilku rzeczach. Po pierwsze lepsze sposoby rozwiązania tworzenia oprogramowania, polegają na tym, że skupiasz się na ludziach i współpracy bardziej niż na narzędziach i procesach. Działające oprogramowanie ponad kompleksową dokumentacją. Współpraca z klientem nad negocjacje kontaktów i odpowiadanie na zmiany ponad podążanie za planem. Cenimy procesy, dokumentację, negocjacje i plan, ale ważniejsze są interakcje, działające oprogramowanie, współpraca i odpowiedź na zmiany. Temat chwycił. Jest w tym dużo prawdy, tak warto pracować. Agile sprowadza się do manifestu i do 12 zasad, które zostały dodane do niego przez twórców i osoby, które brały udział w spotkaniu. Te zasady nie są obowiązkowe do stosowania zawsze. Manifest i 12 zasad to wszystko co definiuje Agile. Cała reszta to są zastosowania, sposoby, różne techniki i to nie jest biblia.
Chcesz być Agile popatrz na Manifest, na zasady, postaraj się je zrozumieć i dopiero poszukaj narzędzi, które pasują do tego w jaki sposób pracujesz. To najsensowniejsze podejście.
12 zasad Agile
1. Najważniejsze jest zadowolenie klienta przez wczesne i stałe dostarczanie działającego oprogramowania – nastawienie na wartość.
2. Otwarcie się na zmianę wymagań, nawet na późnym etapie produkcji – cel ponad zakres.
3. Dostarczenie działającego oprogramowania często, od kilku tygodni do kilku miesięcy, z nastawieniem na skracanie tego czasu – wartość i doskonalenie.
4. Przedstawiciele biznesu i developerzy muszą pracować wspólnie i codziennie w trakcie trwania projektu – współpraca.
5. Budowanie projektu wokół zmotywowanych jednostek. Dawanie im środowiska i wsparcia, którego potrzebują oraz zaufanie, że wykonują swoją pracę – przywództwo.
6. Najbardziej efektywną metodą przekazywania informacji w zespole jest rozmowa twarzą w twarz – współpraca.
7. Działające oprogramowanie jest główną miarą postępu – pułapka długu technologicznego! Robisz, żeby działało a potem się okazuje, że na przykład coś jest nieserwisowalne. Akurat tą zasadę warto zrozumieć trochę głębiej, bo tworzy ona najwięcej problemów.
8. Procesy zwinne promują stabilne środowisko. Sponsorzy, developerzy i użytkownicy powinni utrzymać stałe tempo cały czas – dyscyplina. Kolejny element na który rzadko się zwraca uwagę.
9. Stałe zwracanie uwagi na techniczną doskonałość i dobry design wspiera zwinność – pułapka perfekcjonizmu. Działające oprogramowanie i techniczna doskonałość. Te dwie zasady warto ze sobą połączyć, bo inaczej albo zrobimy coś co nie będzie serwisowalne, albo będziemy tak długo łupać tematy, gdzie wrócimy do rzeczywistości sprzed Agile.
10. Sztuka maksymalizacji pracy, która nie zostanie wykonana, jest kluczowa- prostota.
11. Najlepsze architektury, wymagania i design pojawia się w samoorganizującym się zespole – przywództwo i doskonalenie.
12. W regularnych odstępach czasu zespół dokonuje refleksji jak mógłby być bardziej efektywny, a potem zmienia i dopasowuje swoje zachowanie zgodnie z sytuacją – doskonalenie.
Zanim zaprosicie kogokolwiek do rozmowy o zwinności wydrukujcie sobie Manifest Agile i przedyskutujcie co o nich myślicie, które wam pasują, jak je rozumiecie. To punkt startowy do tego jakiego Agile potrzebujecie.
Podsumowując – wartość, cel, doskonalenie, współpraca, przywództwo, dyscyplina i prostota to punkty wokół których warto krążyć.
Kiedy stosować “metodyki” Agile?
Trochę inaczej będziemy pracować w sytuacji standardowych kontraktów, które są najczęściej podpisywane na zasadzie fixed price. Jest określona cena za dany zakres. Jeżeli masz przypisany stały zakres to czas i koszt potrafią się zmieniać, bo nie do końca jesteś w stanie przewidzieć czas trwania i koszt. Dlatego przy kontraktach fixed price dostawca wpisuje sobie w cenę kontraktu ryzyko. Przy zwinnym podejściu działa to inaczej – czas i koszt są stałe. Umawiasz się z zespołem, który będzie pracował zwinnie , że będzie pracował przez 10 miesięcy, w tym czasie co miesiąc dadzą wydanie oprogramowania, albo konkretnej wartości, ale co powstanie w ciągu tych 10 miesięcy to trzeba dopiero odkryć. Tu się pojawia pierwszy problem – wywalę kasę i nic z tego nie będę miał? Jeżeli wrzucisz kasę i nie będziesz tego kontrolować w zdyscyplinowany sposób, to tak się skończy, ale można do tego podejść inaczej. Mamy kontrakty albo fixed price albo time and material. To podejście było dawno stosowane – jak analizujesz projekt to robisz podejście time and material, bardziej zwinny sposób. Później jak jest doprecyzowane co ma być w zakresie to drugą część kontraktu podpisujesz na zasadzie fixed price.
To prowadzi do myślenia kiedy zwinność ma sens a kiedy nie. Przy tematach, gdzie nie do końca znasz zakres popracuj zwinnie. W tematach, gdzie masz dokładny zakres popracuj na fixed price.
Jakie są zalety prowadzenia projektów “metodą” Agile
Szybki feedback i reakcja. To zdecydowanie jest to co lubię w podejściu zwinnym. Dostajesz coś, informacja zwrotna, korygujemy i jedziemy dalej. Świetny sposób pracy i weryfikowania oczekiwań oraz niepopełniania błędów na dużą skalę.
Skupienie na rezultacie i “lekkość”. Skupiasz się nad tym co chcesz osiągnąć i nie dodajesz dużo biurokracji.
Skuteczne, jeżeli wiesz co robisz. Jeżeli masz zdyscyplinowany zespół, który rozumie jak zgłaszać problemy, bez zamiatania pod dywan to super działa. Jeżeli nie masz zespołu, który potrafi tak działać to zwykle się wysypie.
Wady “metodyki” zwinnej
To nie jest metodyka. To pewna filozofia działania i wartości, które przekładają się na to jak będziesz organizować swoją pracę i co będzie twoim kompasem. Do tego dodajesz dopiero metody SCRUM czy inne. Jeżeli masz dobrze zdefiniowane zasady, masz je dopasowane do dojrzałości zespołu to działa. Jeżeli oczekujesz, że będzie to odpowiedź na wszystkie problemy to jej tam nie znajdziesz.
Ujawnia niekompetencję dużo szybciej. Wtedy samoorganizacja zespołu leży, trzeba go poprowadzić w hierarchiczny sposób.
Łatwa do zrozumienia, trudna do zastosowania. Wszyscy się zgadzają, że “to jest fajne”natomiast, żeby stosować prostotę, utrzymać feedback, przywództwo itd to nie jest łatwe nawet w zespołach, które się lubią i mają wysokie kompetencje.
Agile w praktyce
Jak szukasz jakiejś metody to spotkasz PDCA czyli cykl plan – do- check – act. Planujesz, robisz, sprawdzasz, poprawiasz. To stary dobrze znany cykl Deminga, praca w iteracjach. Wymyślono to już dawno temu.
Bonus na koniec
Manifest Agile trzeba czytać obrócony na bok. Dlaczego tak i co to znaczy? Wyszło nam z naszych badań, że skupienie się na ludziach działa, jeżeli masz podstawy związane z procesami, z dobrym kontraktem, dokumentacją itd. Manifest trzeba czytać obrócony na bok, bo pisali go ludzie, którzy byli bardzo doświadczeni i wiedzieli co robić. W momencie, kiedy jesteś świetny technicznie skupianie się na ludziach jest tym co napędza projekt. Natomiast jeżeli skupisz się na ludziach bez podstawy technicznej, procesowej itd to wszystko się wypierdzieli, albo zwiniesz projekt albo firmę. Firmy dokładnie tak rosną – najpierw są zarządzanie hierarchicznie później dojrzałość procesów rośnie zaczyna być większe skupienie na ludziach i podejście zwinne, turkusowe dzieje się gdy jest osiągnięty bardzo wysoki poziom dojrzałości procesów.
Agile, Lean, Prince2, co wybrać? Jeśli zastanawiasz się co zastosować u siebie w firmie to zapraszam cię do kontaktu z nami https://leadership-center.pl/kontakt/
VIDEO
Kategorie: Strategie i metodyki
