Co to jest zwinne? Filozofia, która rozwija się poprzez praktykę

Pierwotnie stworzony dla zespołów programistycznych, Agile jest obecnie najlepszym podejściem do zarządzania projektami dla branż i firm na całym świecie. Atrakcyjność leży w jej prostocie i elastyczności: brak nakazowych praktyk Agile sprawia, że ​​jest ona bardzo przyjazna. A jednak, kiedy kierowałem transformacjami Agile w kilku firmach, odkryłem, że ta elastyczność prowadzi również do nieporozumień na temat tego, co to znaczy być Agile. Wiele firm przedkłada trzymanie się ram opartych na Agile nad zrozumieniem samej filozofii.

Zamiast tego, kierownicy projektów i trenerzy gromadzący i kierujący zespołami Agile powinni zacząć od szkolenia ich w przyjmowaniu sposobu myślenia Agile, zasadniczo internalizując podstawowe wartości i zasady filozofii. Tylko wtedy powinni łączyć, dostosowywać lub pomijać praktyki z frameworków Agile w oparciu o to, co najlepiej spełnia wymagania projektu.

Śledząc historyczny rozwój Agile i wiążąc jego podstawowe zasady z konkretnymi potrzebami firm i zespołów, ten artykuł może pomóc kierownikom projektów w tworzeniu optymalnej przyszłości dla transformacji Agile. Jak pokazują poniższe przykłady, Agile nie należy traktować wyłącznie jako podejście do zarządzania projektami, ale raczej jako filozofię rozwoju produktu, która w praktyce stale się rozwija.

Zwinni poprzednicy

Opracowany po raz pierwszy w 2001 r. „Manifest na rzecz zwinnego rozwoju oprogramowania”, zwięzły zbiór czterech podstawowych wartości i 12 zasad, był radykalną odpowiedzią na liniowe, obciążające procesy podejścia, obciążone regułami i ryzami dokumentacji. Ale historia Agile rozpoczęła się kilkadziesiąt lat wcześniej od metody usprawnienia produkcji przemysłowej.

Jako poprzednik filozofii skupiającej się na iteracyjnym doskonaleniu, model Plan-Do-Study-Act został opracowany w latach 30. XX wieku przez fizyka i statystyka z Bell Labs, Waltera Shewharta. Po II wojnie światowej jego protegowany W. Edwards Deming zastosował ją do szkolenia menedżerów Toyoty. Metoda była integralną częścią rozwoju Systemu Produkcyjnego Toyoty, głównego źródła szczupłego myślenia z jego wydajną pętlą budowania, pomiaru i uczenia się.

W latach 70. koncepcja została dalej rozwinięta, kiedy Barry Boehm zaproponował technikę Wideband Delphi, wykorzystującą proces iteracyjny do dokładnego i obiektywnego oszacowania pracy i czasu wymaganego do opracowania oprogramowania.

Wraz z rozpowszechnieniem się komputerów osobistych w połowie lat 80. stało się jasne, że oprogramowanie jako produkt i usługa stanie się podstawą sposobu, w jaki ludzie prowadzą interesy. Gdy profesjonaliści zaczęli zwracać dużą uwagę na stopniowe, iteracyjne podejścia do inżynierii oprogramowania, Agile przewyższyło procesy Waterfall jako lepsze podejście do tworzenia i zarządzania.

Naukowcy odkryli, że producenci, którzy wprowadzali innowacje szybciej niż ich konkurenci, stosowali multidyscyplinarną, zorientowaną na zespół metodę, aby przejść przez cykl życia produktu. Jest to powszechnie uważane za inspirację Jeffa Sutherlanda do wynalezienia frameworka Scrum w 1993 roku, co pozwoliło mu realizować pozornie niemożliwe projekty zgodnie z harmonogramem i budżetem, z minimalną ilością błędów.

Teoretyczne wartości Agile – wyłaniające się z tych poprzedników – zostały potwierdzone w moim stosowaniu Agile w praktyce, z naciskiem na iteracyjny rozwój, współpracę zespołową i dokładne oszacowanie.

Czym jest Agile w teorii?

Ponieważ firmy nadal przyjmują metody pracy Agile, ryzykują, że uczynią ją bardziej nakazową, niż kiedykolwiek zamierzali twórcy tej filozofii. Z mojego doświadczenia wynika, że ​​liderzy, którzy chcą zastosować Agile, zbytnio skupiają się na ramach – lub zestawach konkretnych praktyk i związanej z nimi nomenklaturze – a niewystarczająco na wartościach i zasadach.

Jak dobrze wiedzą praktycy, którzy są zaawansowani w przekazywaniu zasad Agile, każda organizacja, która chce przejść transformację Agile, musi znaleźć i dostosować podejście, które im odpowiada. Ułatwiam ten proces uczenia się, pokazując zespołom, jak postępować zgodnie z wartościami i zasadami manifestu, a następnie czerpiąc inspirację z frameworków, takich jak Scrum, Kanban i Extreme Programming (XP), aby wdrożyć je w praktyce.

Założenia manifestu są już drugą naturą kierowników projektów Agile:

1. Osoby i interakcje nad procesami i narzędziami
2. Praca produktów nad obszerną dokumentacją
3. Współpraca z klientem przy negocjacjach umowy
4. Reagowanie na zmianę na realizację planu

Często jednak przeocza się zastrzeżenie, które następuje po tych założeniach w manifeście: „To znaczy, chociaż przedmioty po prawej stronie mają wartość, bardziej cenimy przedmioty po lewej stronie”. Wielu praktyków Agile kończy lekceważenie wartości po prawej stronie i skupianie się tylko na tym, co jest po lewej stronie. Wynik? Przeciwieństwo ślepego podążania za strukturami z dużą ilością procesów: brak procesu w ogóle, co jest równie problematyczne.

Osiągnięcie właściwej równowagi między przedmiotami po prawej i lewej stronie stało się kluczem do tego, jak kieruję transformacjami Agile. Przykładem są podejścia do zarządzania w Apple, Google, Amazon, Facebook i Netflix, z których żadne nie subskrybuje pojedynczego frameworka Agile. Przede wszystkim ucieleśniali zasady manifestu, podążając za lub zmieniając części różnych ram w oparciu o to, co najlepiej dla nich zadziałało; dzięki temu dostosowali się do zmian rynkowych i są w stanie szybko dostarczać nowe produkty.

Czym jest Agile w praktyce?

W poniższym przeglądzie zmodyfikowałem oryginalne sformułowanie wartości manifestu. Zmiany w semantyce pomagają wyjaśnić, w jaki sposób stosuję wartości Agile w praktyce.

W pierwszej wartości zastępuję termin „osoby” słowem „ludzie”, ponieważ bycie zwinnym oznacza bycie zorientowanym na zespół. Co do drugiego, oczywiste jest, że oprogramowanie musi „działać”, więc teraz skupiamy się na udanej i terminowej „dostawie”. Trzecia wartość to po prostu „współpraca”, ponieważ dotyczy zarówno współpracujących ze sobą współpracowników, jak i zespołów pracujących z klientami. Wreszcie „ramy” zastępują „podążanie za planem”, ponieważ zapobiega to nieporozumieniu, że planowanie należy całkowicie porzucić.

Ludzie nad procesami

Transformacje zwinne są trudne, przede wszystkim dlatego, że większość firm jest przyzwyczajona do ścisłego przestrzegania procesów. Celem końcowym staje się wykonanie określonej liczby kroków przy pomocy określonego zestawu narzędzi, zamiast opracowania innowacyjnego produktu.

Byłem przerażony, widząc, że ta mentalność daje początek dochodowemu „przemysłowi Agile”. Jak wyjaśniają założyciele Agile, Ward Cunningham i Jon Kern, wiele firm sprzedaje oprogramowanie, które, jak twierdzą, pomoże firmom „przejść na Agile”. Jednak przejście na Agile oznacza przyjęcie filozofii, a nie używanie oprogramowania i przestrzeganie zalecanego przez nią programu.

Osiągnięcie odpowiedniej równowagi nie polega na wyeliminowaniu procedur, ale raczej na znalezieniu tych, które najlepiej wspierają cele rozwojowe każdego zespołu. Dla jednego z moich klientów, dużej organizacji zajmującej się technologią korporacyjną, wdrożyłem Disciplined Agile, podejście opracowane w IBM. Łączy wiele praktyk z wielu frameworków, w tym Scrum i Kanban. Wykorzystuje iteracyjny rozwój, ale jest nieco bardziej obciążony procesem niż tradycyjne Agile, szczególnie w początkowej fazie, ponieważ ma na celu wypełnienie luk pozostawionych przez Scrum. Zdyscyplinowany Agile pracował dla tego klienta, ponieważ organizacja była bardzo zorientowana na proces. Pozwoliło mi to spotkać się z zespołami w połowie drogi, uzyskać ich wpisowe i przekonać je do przyjęcia przepływu pracy Scrum.

Włączyłem spotkania dopracowujące zaległości, spotkania przeglądowe i codzienne scrumy, aby ułatwić współpracę wewnątrz i między zespołami. Udoskonalenie zaległości jest częścią Przewodnika po Scrumie, ale spotkania doskonalące już nie. Dodałem je, aby umożliwić zdrową rozmowę o tym, dlaczego planowaliśmy wdrożyć określone funkcje w nadchodzących sprintach, co jest pomocne dla nowicjuszy Agile. Wybrałem również nazewnictwo „kamienie milowe” – termin używany w zarządzaniu projektami Waterfall – ponieważ był on bardziej znany klientowi. Przeglądy i codzienne interakcje scrum są konwencjonalnymi elementami Przewodnika Scrum, ale ustrukturyzowałem je pod względem harmonogramu, czasu trwania i przepływu.

Dodatkowo, podczas gdy ścisłe przestrzeganie Scruma oznaczałoby, że każda osoba byłaby w pełni poświęcona jednej z ról wymienionych w Przewodniku po Scrumie, w zespołach mojego klienta byli ludzie, których umiejętności nie pasowały do ​​jednej z ról. Zastosowanie metody Disciplined Agile pozwoliło mi podzielić obowiązki na tych stanowiskach między wielu członków zespołu i stworzyć proces, który wykorzystał mocne strony zaangażowanych osób.

Dostawa oprogramowania nad dokumentacją

Innym powodem, dla którego wolę niestandardowe przepływy pracy Scrum lub Kanban niż ścisłą zgodność z dowolnymi ramami, jest to, że dają mi możliwość dodania minimalnego opłacalnego produktu (MVP) do planu jako celu. Wywodząca się z Lean praktyka tworzenia MVP jest spójna z rozwojem iteracyjnym i stała się popularną techniką wśród praktyków Agile. Pozwala zespołowi skutecznie dostarczać użytkownikom wysokiej jakości oprogramowanie i inne towary, a następnie udoskonalać je w oparciu o informacje zwrotne. Zastosowanie go w ramach podejścia hybrydowego, w dużej mierze opartego na Scrum lub Kanbanie, zwiększyło zdolności moich zespołów do tworzenia produktów spełniających potrzeby klientów.

Obecnie pracuję z amerykańskim startupem i wykorzystuję tę metodę w budowaniu rynku kryptowalut dla NFT. Skupiamy się na tworzeniu MVP, więc piszemy tylko minimalną dokumentację potrzebną na razie. Chociaż to podejście jest skuteczne w przypadku szerokiej gamy produktów, jest szczególnie przydatne w przypadku kryptowalut i transakcji NFT, które należą do nowej, eksperymentalnej kategorii, która szybko się zmienia. Zamiast opracowywać kompletne specyfikacje i funkcje oraz wielokrotnie je zmieniać przed wydaniem, możemy poświęcić ten czas na uwzględnienie opinii użytkowników, aby usprawnić rozwój naszego rynku.

Współpraca nad umowami

Wspomniana wcześniej duża organizacja technologiczna dla przedsiębiorstw polegała w dużej mierze na umowach dotyczących wielu projektów o stałych kosztach. Kontrakty określały metody, jakich użyją do wykonania pracy, a także konkretne osoby, które będą odpowiedzialne za każde zadanie. Po podpisaniu umów nie można było zmienić bez długiego procesu składania wniosków.

Częścią transformacji, którą kierowałem, była priorytetowa współpraca w stosunku do tych sztywnych umów. Wdrożony przez nas plan zastąpił umowy dokumentami jednostronicowymi. Każdy stwierdził, że zgodziliśmy się używać Agile do współpracy — z naszymi klientami, a także kolegami z zespołu i kolegami z różnych zespołów — między wyznaczonymi datami rozpoczęcia i zakończenia. Cokolwiek wyjdzie ze współpracy, będzie rezultatem. Nie podałem konkretów, jakie mogą być gotowe produkty. Ponieważ prosiliśmy klientów o opinie i uwzględnialiśmy je w rozwoju naszych produktów, usunięcie specyfikacji z naszego dokumentu planu sprawiło, że byliśmy bardziej otwarci na ich odpowiedzi i zachęciliśmy ich do bardziej aktywnej współpracy z nami.

Aby zaangażować kierownictwo, poprosiłem ich, aby pozwolili mi poprowadzić weryfikację koncepcji z jednym małym zespołem pracującym z jednym małym klientem, który wyraził obawy, że czasy rozwoju są zbyt długie, nawet zanim jakiekolwiek wymagane zmiany spotęgują problem. Dzięki bezpośredniej współpracy tego klienta z naszym właścicielem produktu, byliśmy w stanie wprowadzić zmiany w trakcie opracowywania i znacznie skrócić czas dostawy.

Te wyniki skłoniły kierownictwo do udostępnienia planu większej liczbie zespołów. Ogólnie rzecz biorąc, uproszczona umowa i nasz przepływ pracy Agile skróciły czas potrzebny na opracowanie i wprowadzenie funkcji produktu na rynek.

Adaptacyjność ponad frameworkami

Inny mój klient, firma zajmująca się technologiami medycznymi, również nie zdołała znaleźć równowagi pod względem uznania znaczenia obu stron wartości Agile, a mianowicie reagowania na zmianę zgodnie z planem. W tym przypadku jednak popełnił błąd, który popełnił mój klient z branży technologii korporacyjnych: zamiast zbyt sztywno przestrzegać procesu, przeindeksował elastyczność, jednocześnie w dużej mierze zaniedbując proces. Inżynierowie rzadko wiedzieli, nad czym powinni pracować, ponieważ nie było priorytetów ani harmonogramu. Stracili czas i produktywność, próbując to rozgryźć każdego dnia i wykonywali mniej ważne zadania przed bardziej kluczowymi.

Zaproponowałem wdrożenie Scrum CEO i CTO, wyjaśniając, że sprinty zmusiłyby inżynierów do zdyscyplinowania i planowania w dwutygodniowych przyrostach, w przeciwieństwie do decydowania, nad czym pracować każdego dnia. Poradziłem również, aby zatrudnili właściciela produktu, co naprawi brak odpowiedzialności zespołu za produkt. Poprosiłem dyrektorów, aby dali mi trzy lub cztery miesiące na pracę z ich zespołami, zanim będą mogli spodziewać się wyników.

Po uzyskaniu ich aprobaty najpierw przedstawiłem wartości i zasady Agile, a następnie przeszkoliłem zespół w zakresie backlogu produktu i różnych technik jego aranżowania, w tym tworzenia eposów i historyjek użytkowników oraz tworzenia podzadań. Techniki i spotkania, które uwzględniliśmy w naszym przepływie pracy, są odchyleniami od tradycyjnego Scrum, ponieważ nie pojawiają się w Przewodniku po Scrumie. Włączyłem je do planu, ponieważ eposy, historie i podzadania rezonowały z zespołami podczas szkoleń, a spotkania sprzyjały owocnym dyskusjom.

Uwzględniłem również pojęcie prędkości, późnego dodatku do XP, który mierzy szacunkowe łączne nakłady pracy dla wszystkich historyjek użytkownika w każdej iteracji produktu. Użyłem jednak terminu „pojemność”, który wolę, ponieważ podkreśla, ile członkowie zespołu mogą odebrać, a nie jak szybko mogą wykonać zadania.

Dla oszacowania zacząłem od rozmiaru T-shirtów, techniki, która mierzy projekty i zadania jako małe, średnie i duże; w miarę postępów zespołu przestawiłem się na punkty fabularne, bardziej tradycyjną technikę szacowania. Punkty fabularne są często nadużywane przez zespoły niewtajemniczone w Agile, które próbują zamienić je na godziny lub dni pracy, nadmiernie skupiając się na ramach czasowych i oceniając ludzi na podstawie ich zdolności do dotrzymywania terminów.

Rozmiary koszulek są bardziej abstrakcyjne, co ułatwia zespołom uniknięcie tej pułapki. Jednak jest też mniej precyzyjny. Kiedy więc zespół zrozumiał, jak szacować w kategoriach względnych, przestawiłem je na bardziej wyrafinowaną technikę.

Zanim zespół ukończył dwa sprinty, kierownictwo wyższego szczebla było w stanie zobaczyć, jak ich pracownicy pracują wydajniej i skuteczniej komunikują się. Deweloperzy po raz pierwszy nawiązali kontakt z interesariuszami i kierownictwem wykonawczym. Spotkali się z zespołem obsługi klienta i zrozumieli, w jaki sposób wdrożone przez nich funkcje poprawiają życie użytkowników.

Takie podejście szybko doprowadziło do podniesienia jakości oprogramowania firmy i skrócenia czasu dostarczania nowych funkcji z miesięcy do tygodni.

Jaka jest przyszłość Agile?

Pandemia COVID-19 stworzyła nową rzeczywistość, w której zespoły nie mogły już być kolokowane, co było preferowanym sposobem pracy w Agile, gdy został poczęty. Jednak idea, że ​​musi tak pozostać, jest mitem: ponieważ praca zdalna stała się powszechna, stało się jasne, że bliska komunikacja jest całkowicie możliwa dzięki oprogramowaniu do wideokonferencji. Zespoły, z którymi teraz pracuję, są w pełni rozproszone, a szkolenia prowadzę zdalnie. Niektóre zespoły decydują się nawet na pracę asynchroniczną, używając narzędzi takich jak Notion i Loom, a także wtyczek Slack, takich jak Standuply.

Rozproszony model współpracy to nowy świat pracy, którego centrum stanowi zwinność. Równowaga między życiem zawodowym a prywatnym zapewniana zespołom zdalnym ma pozytywny wpływ na morale i dobre samopoczucie psychiczne, co zwiększa produktywność i jakość; stawia ludzi ponad procesami, jest elastyczny i elastyczny, co czyni go kwintesencją Agile.

Trenerzy Agile, mistrzowie Scrum i kierownicy projektów powinni powrócić do korzeni filozofii i przedstawić ją tak, jak zrobili to twórcy manifestu: elastyczny i dynamiczny zestaw wytycznych dotyczących rozwoju i dostarczania. Powinni uczyć kierowników i liderów zespołów, że chociaż mogą czerpać inspirację z zarządzania projektami, tak naprawdę nie zarządzają niczym w Agile — kierują zespołami i pozwalają im wykonywać swoją najlepszą pracę.