Manifest Agile ma 25 lat. Czas go przeczytać jeszcze raz.
Agile miał być ucieczką od biurokracji. W wielu firmach stał się nią samą: niekończące się stand-upy, ceremonie bez celu, velocity jako KPI. Ta strona to przypomnienie, czym Agile naprawdę jest — i praktyczne narzędzia, żeby do tego wrócić.
Snowbird, Utah · luty 2001
Odkrywamy lepsze sposoby wytwarzania oprogramowania, tworząc je i pomagając w tym innym. W wyniku tej pracy zaczęliśmy przedkładać:We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Problemy w projektach rzadko wynikają z braku narzędzia. Częściej z tego, że ludzie ze sobą nie rozmawiają. Dobry proces wspiera rozmowę, a nie ją zastępuje.
Jira jako źródło prawdy, a rozmowa jako „off-topic”. Proces, którego nie wolno zmienić, bo „tak ustalił PMO”.
Najlepszym dowodem postępu jest coś, czego użytkownik może dotknąć. Dokumentacja jest wartościowa — o ile pomaga budować i utrzymywać produkt.
„Agile, więc nie piszemy dokumentacji”. Albo odwrotnie: 40 stron „Definition of Ready”, zanim ktokolwiek napisze linię kodu.
Umowa jest potrzebna, ale nie zastąpi wspólnego odkrywania, czego klient naprawdę potrzebuje. Współpraca buduje zaufanie, kontrakt je tylko zabezpiecza.
Product Owner, który nigdy nie widział klienta. Sprint Review, na którym zamiast użytkowników jest prezentacja dla zarządu.
Plan jest hipotezą. Rynek, użytkownicy i technologia zmieniają się szybciej niż roczne roadmapy. Planujemy dużo — ale po to, żeby się uczyć, nie żeby się okopać.
PI Planning zamrażający zakres na kwartał. „Zmiana? Wpiszcie do backlogu, wrócimy do tego w Q3.”
Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas elementy wypisane po lewej.That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck · Mike Beedle · Arie van Bennekum · Alistair Cockburn · Ward Cunningham · Martin Fowler · James Grenning · Jim Highsmith · Andrew Hunt · Ron Jeffries · Jon Kern · Brian Marick · Robert C. Martin · Steve Mellor · Ken Schwaber · Jeff Sutherland · Dave Thomas
© 2001, powyżsi autorzy. Deklaracja może być swobodnie kopiowana w dowolnej formie, ale wyłącznie w całości i z tą informacją. Źródło: agilemanifesto.org. Tłumaczenie robocze.
Kliknij wartość, żeby zobaczyć, co znaczy — i jak ją zepsuto.
Czym jest Agile
Agile to zbiór wartości i zasad, a nie konkretny proces. Zakłada, że w złożonej pracy — a tworzenie produktów jest złożone — nie da się wszystkiego przewidzieć z góry. Dlatego zamiast jednego wielkiego planu robimy małe kroki, szybko pokazujemy efekty i uczymy się na feedbacku.
Scrum, Kanban, Extreme Programming czy Lean to sposoby realizacji tych wartości. Można mieć wszystkie ceremonie Scruma i nie być ani trochę zwinnym. Można nie mieć żadnej i być bardzo zwinnym.
Waterfall dostarcza wartość na końcu — i tylko jeśli wymagania z początku są nadal aktualne. Agile dostarcza po kawałku i koryguje kurs.
12 zasad stojących za manifestem
Każda karta ma dwie strony: zasadę i to, jak w praktyce bywa łamana. Kliknij, żeby odwrócić.
Skąd się wziął Agile
Agile nie spadł z nieba w 2001 roku. To efekt trzech dekad frustracji ciężkimi procesami i eksperymentów z lżejszymi.
Winston Royce publikuje artykuł o zarządzaniu dużymi projektami. Rysunek „kaskady” staje się wzorcem branży — choć sam Royce ostrzegał, że podejście jednoprzebiegowe jest ryzykowne i zachęcał do iteracji.
Hirotaka Takeuchi i Ikujiro Nonaka w Harvard Business Review opisują „The New New Product Development Game”: małe, samoorganizujące się zespoły, które jak drużyna rugby przesuwają piłkę razem, zamiast podawać ją sztafetą.
Powstają RAD, DSDM, Crystal, Feature-Driven Development. Wspólny mianownik: krótkie cykle, bliskość klienta, mniej papieru. Nazywano je wtedy „lightweight methods”.
Ken Schwaber i Jeff Sutherland przedstawiają Scrum jako ramę pracy dla złożonych produktów: empiryzm — przejrzystość, inspekcja, adaptacja.
Kent Beck publikuje „Extreme Programming Explained”. Pair programming, TDD, ciągła integracja, małe wydania. Techniczna dyscyplina jako fundament zwinności.
W lutym 17 praktyków spotyka się w ośrodku narciarskim. Spierają się o metody, ale zgadzają co do wartości. Wychodzą z jedną stroną tekstu: Manifestem Agile. Kilka miesięcy później powstaje Agile Alliance.
David J. Anderson zaczyna stosować zasady Lean i systemy „pull” w zespołach Microsoftu, a później w Corbis. W 2010 wydaje książkę „Kanban”. Fokus: przepływ i ograniczanie pracy w toku.
Schwaber i Sutherland publikują pierwszy Scrum Guide. W 2020 jego wersja zostaje odchudzona do ok. 13 stron — mniej nakazów, więcej celu: Product Goal, „Developers” zamiast „Development Team”.
Najpopularniejsza rama zwinna
Scrum jest celowo niekompletny. Daje minimalną strukturę — resztę zespół dobiera sam. Kliknij wydarzenie w cyklu, żeby zobaczyć jego cel, timebox i najczęstszy antywzorzec.
Wybierz wydarzenie
Każde wydarzenie Scruma to okazja do inspekcji i adaptacji. Jeśli spotkanie nie zmienia żadnej decyzji — przestało być wydarzeniem Scruma, a stało się rytuałem.
Cały Scrum Team
Timebox do 8 h (sprint 1-miesięczny)
Ustalamy, dlaczego ten Sprint jest wartościowy (Cel Sprintu), co da się zrobić i jak to zrobimy.
Developerzy
Timebox 15 minut
Developerzy sprawdzają postęp w kierunku Celu Sprintu i dostosowują plan na najbliższy dzień.
Kontener na wszystkie wydarzenia
Timebox max. 1 miesiąc, stała długość
Rytm, w którym zamieniamy pomysły w wartość. Każdy Sprint to mini-eksperyment kończący się przyrostem.
Scrum Team + interesariusze
Timebox do 4 h
Sprawdzamy rezultat Sprintu z interesariuszami i decydujemy, co dalej. To sesja robocza, nie prezentacja.
Scrum Team
Timebox do 3 h
Zastanawiamy się, jak poprawić jakość i efektywność: ludzie, interakcje, procesy, narzędzia, Definition of Done.
Developerzy + Product Owner
Timebox ciągła aktywność (nie wydarzenie)
Rozbijamy i doprecyzowujemy elementy Product Backlogu, żeby były gotowe do wyboru w przyszłych Sprintach.
Maksymalizuje wartość produktu. Zarządza Product Backlogiem i podejmuje decyzje o kolejności.
Nie jest sekretarzem zbierającym wymagania ani pośrednikiem bez decyzyjności.
Odpowiada za skuteczność zespołu. Uczy, coachuje, usuwa przeszkody, pomaga organizacji zrozumieć empiryzm.
Nie jest project managerem, organizatorem spotkań ani „Jira adminem”.
Tworzą użyteczny przyrost w każdym Sprincie. Sami planują, jak zrobią pracę, i dbają o jakość.
Nie są „zasobami” wykonującymi przydzielone tickety.
Na podstawie Scrum Guide 2020 (K. Schwaber, J. Sutherland), scrumguides.org.
Kanban
Kanban nie zmienia ról ani nie dodaje spotkań. Zaczynasz od tego, jak pracujesz dziś, i ewolucyjnie poprawiasz przepływ. Kluczowa dźwignia: limit pracy w toku (WIP).
Prawo Little’a mówi wprost: czas realizacji = praca w toku ÷ przepustowość. Chcesz szybciej? Rób mniej rzeczy naraz.
Przy tej samej przepustowości obniżenie WIP z 12 do 4 skraca czas realizacji trzykrotnie.
Przykłady wykorzystania
Administracja publiczna
System zarządzania sprawami FBI po latach problemów w klasycznym modelu kontraktowym został przejęty przez FBI i dokończony iteracyjnie, małym zespołem, w krótkich cyklach. Wdrożenie nastąpiło w 2012 r.
Krótkie iteracje i mały zespół potrafią uratować projekt, który wcześniej pochłonął budżet.
Sektor publiczny
Brytyjski Government Digital Service zbudował jedną stronę dla usług rządowych, pracując w fazach discovery → alpha → beta → live i stawiając na potrzeby użytkownika. Swoje zasady opisał w publicznym Service Manual.
Agile działa także w instytucjach — gdy zaczyna się od użytkownika, nie od procedury.
Hardware
Zespół ochotników budował energooszczędny samochód w tygodniowych sprintach, z modułową konstrukcją pozwalającą wymieniać części jak w oprogramowaniu.
Iteracje i modularność nie są zarezerwowane dla software’u.
Zespół nietechniczny
Zespół kampanii wizualizuje pracę na tablicy, ogranicza liczbę kampanii „w toku” i mierzy czas od pomysłu do publikacji. Mniej przełączania kontekstu, szybsze wyniki.
Kanban to najprostszy start: pokaż pracę, ogranicz WIP, mierz przepływ.
Codzienność
Zamiast planować całość od A do Z: najpierw łazienka (największa wartość), test, wnioski, potem kuchnia. Każdy etap daje coś użytecznego i uczy przed kolejnym.
Iteracyjne dostarczanie wartości to po prostu zdrowy rozsądek.
Twój zespół
Mniejsze zmiany, automatyczne testy, ciągła integracja i Definition of Done, które naprawdę coś znaczy. Ryzyko wdrożenia spada, feedback przychodzi szybciej.
Zwinność zaczyna się od technicznej doskonałości, nie od kolejnego spotkania.
Szybki test
Osiem twierdzeń, które słychać w każdym open space. Wynik: 0/0
1/8Agile oznacza brak dokumentacji.
Manifest mówi „działające oprogramowanie ponad obszerną dokumentację”. „Ponad” nie znaczy „zamiast”. Dokumentujemy to, co ma wartość.
2/8Agile to to samo co Scrum.
Agile to zbiór wartości i zasad. Scrum, Kanban, XP czy Lean to różne sposoby ich realizacji. Można być zwinnym bez Scruma — i niezwinnym ze Scrumem.
3/8Manifest Agile nie wspomina ani słowem o stand-upach, sprintach i story pointach.
Ani słowa. Wszystkie te praktyki są narzędziami. Manifest to cztery wartości i dwanaście zasad.
4/8Velocity dobrze nadaje się do porównywania zespołów.
Story pointy są względne i lokalne dla zespołu. Porównywanie velocity zachęca tylko do inflacji punktów.
5/8Daily Scrum jest spotkaniem Developerów, a nie raportem dla managera.
Scrum Guide mówi jasno: Daily jest dla Developerów, służy planowaniu najbliższych 24 godzin w kierunku Celu Sprintu.
6/8W Agile się nie planuje.
Planuje się bardzo dużo — tylko częściej i w mniejszych porcjach. Planowanie jest ciągłe, a plan się aktualizuje.
7/8Zespół ma prawo zmieniać swój sposób pracy.
Retrospektywa istnieje dokładnie po to. Proces, którego nie wolno zmienić, nie jest zwinny.
8/8Story pointy wymyślono, żeby mierzyć produktywność ludzi.
Miały pomóc w prognozowaniu i rozmowie o złożoności. Ron Jeffries, który bywa wskazywany jako ich współtwórca, publicznie żałuje, jak dziś się ich używa.
Kolekcja
Bluza, czapka, kubek i naklejka z logo Make Agile Great Again. Sklep ruszy wkrótce.
Zobacz kolekcję