Nie macie wrażenia, że Agile jest wszędzie? Jak w starym dowcipie, wrócę do domu i zaraz wyskoczy mi z lodówki. Dla mnie to nic nowego – jestem przecież prezesem firmy tworzącej oprogramowanie. I dlatego wiem, że choć wszyscy chcą być zwinni, często praktyka wygląda nieco inaczej. 

Pisząc ten artykuł zastanawiałem się, jak ugryźć temat, by nie zanudzić osób, które znają temat od podszewki, a jednocześnie przybliżyć tym, którzy dopiero go poznają. Zacznijmy więc od definicji, ale obiecuję, że za chwilę skonfrontuję ją z rzeczywistością. Skupię się na tym, jakie podejście jest moim zdaniem najważniejsze przy budowaniu zwinnych zespołów i czemu tylko nieliczni robią to naprawdę dobrze. 

Czym jest Agile? 

Najprostsza definicja Agile to: „podejście zwinne”, a więc na bieżąco dopasowywane do trwającego projektu i wymagań klienta, które często ewoluują podczas jego trwania. Można zastosować ją do przeróżnych dziedzin życia i biznesu. Ja z oczywistych przyczyn, skupię się na tworzeniu oprogramowania. Dziś śmiało możemy powiedzieć, że Agile to już norma. W dorocznym badaniu Stack Overflow, 86% spośród ponad stu tysięcy zapytanych developerów przyznało, że używa go w swojej pracy – a przeprowadzone było ono blisko dwa lata temu. Rok wcześniej 71% dużych firm twierdziło, że wdraża to podejście w swoich projektach. Z niecierpliwością czekam na wyniki podobnych badań z datą 2020 i jestem pewien, że będą one jeszcze bardziej imponujące. 

Popularyzacja Agile świadczy o jednym – że jest on skuteczny. Nic dziwnego więc, że zastąpił on tradycyjny waterfall, czyli zdefiniowany w inżynierii programowania lat siedemdziesiątych model kaskadowy. Według raportu PWC projekty Agile są o 28% bardziej skuteczne niż te, realizowane za pomocą standardowego podejścia. Jeśli się nad tym zastanowić od strony technicznej, to nie mogło być inaczej – poprzednik zakładał wykonywanie kolejnych czynności po sobie, według ściśle określonego porządku. To schemat daleki od szybkiej reakcji na dynamicznie zmieniające się potrzeby biznesu. Patrząc przez pryzmat człowieka – pogłębiał stereotyp programisty jako zamkniętego na otoczenie informatyka w grubych okularach i kraciastej koszuli, dla którego świat kończy się tam, gdzie linijka kodu. 

Ludzie, nie procesy   

Agile jest oczywiście metodyką pracy, więc musi mieć swój porządek, którego najpopularniejszym wcieleniem jest scrum. To, jak w praktyce budować zwinne zespoły, czym powinien zajmować się product owner, jak planować sprinty, przeprowadzać daily meetingi i na czym powinien skupić się scrum master – to temat na kilka osobnych artykułów. Moje doświadczenie mówi, że najważniejsze to jednak… nie skupiać się na tych rolach za bardzo, tak by nie zapomnieć o innych, równie ważnych czynnikach. Dlaczego? 

Założenia Agile spisane zostały blisko dwadzieścia lat temu w Agile Manifesto, od którego wszystko się zaczęło. Dokument ten mówi jasno: chodzi o ludzi, nie procesy. Podpisuję się pod tym obiema rękami. Dla mnie Agile to sposób myślenia, nie pracy. Mam wrażenie, że coraz częściej o tym zapominamy, a przecież gdy spojrzymy na manifest, to oczywiście, to co znajduje się po prawej jest ważne, ale nie aż w takim stopniu, jak jego lewa część: 

• ludzie i interakcje ponad procesy i narzędzia 
• działające oprogramowanie ponad obszerną dokumentację 
• współpraca z klientem ponad formalne ustalenia 
• reagowanie na zmiany ponad podążanie za planem 

Jak budować prawdziwie zwinne zespoły? 

Rekrutując nowych członków swoich zespołów zazwyczaj zadaję im proste pytanie:  

- „Jak z Twojego doświadczenia wygląda wdrożenie agile?”.  

Bardzo często odpowiedź jest schematyczna:  

- „To proste - codziennie spotykamy się z zespołem, product owner mówi co mamy robić, ja siadam i koduję”. 

W Pragmasoft robimy to zupełnie inaczej. Oczywiście, metodyka jest ważna, ale dla mnie podejście Agile to coś więcej – szeroko pojęte podejście do pracy w zespole i branie za nią odpowiedzialności. To bardzo ważne, abyśmy znali książkowe pojęcia: frameworki, daily plany i swoją rolę w procesie. Jednak bez zrozumienia tych dwóch czynników, praktycznie niemożliwe jest stworzenie zwinnego zespołu, który wygrywa na rynku i jest świetnie dopasowany do potrzeb klienta. 

W Pragmasoft wypracowaliśmy model wzajemnego zaufania i współpracy, w którym wszyscy członkowie zespołu najpierw ustalają z product ownerem, to, czego on będzie od nich wymagać i co razem chcieliby osiągnąć. Następnie omawiają wyzwania i zbierają pomysły na temat planowanego podejścia do projektu. Planują, jak ma wyglądać implementacja rozwiązania, potem dopiero deklarując ramy czasowe. Tym sposobem unikamy pracy tylko od A do B, B do C i tak dalej. Ludzie sami zdecydowanie bardziej angażują się w projekt, ale też biorą odpowiedzialność za jego całokształt – na przykład sugerując product ownerowi, że można zrobić coś inaczej, bardziej optymalnie lub skutecznie. W mgnieniu oka są też na przykład w stanie zastąpić testera, który akurat dziś zachorował. 

Łukasz Korneluk, CEO Pragmasoft

Źródło: http://pragmasoft.pl/pl/blog/agile-to-ludzie-nie-procesy