Dlaczego niektórzy sądzą, że Scrum jest g* wart?

Kilka lat temu Scrum oraz Agile stały się bardzo popularne i nagle każdy poczuł wewnętrzną potrzebę bycia zwinnym. To samo było z mikroserwisami – pojawiały się jako główny temat na każdej konferencji niezależnie od omawianej technologii. Z powodu tej popularności wiele firm wpadło w piekiełko mikroserwisów. Tak samo było z Node.js czy Dockerem. Ślepe skupianie się na narzędziach to ryzykowne podejście.

Podczas pracy w małej agencji interaktywnej, wiele lat temu, mój zespół funkcjonował w systemie tradycyjnym. Wtedy też pierwszy raz usłyszałem o Scrumie i się w nim zakochałem. Dlatego gdy zmieniałem pracę, to wybrałem firmę, która chwaliła się, że jest zwinna.

Jednak „Scrum” w ogłoszeniu rekrutacyjnym to za mało. W nowej firmie pracowaliśmy tak naprawdę w systemie tradycyjnym, lecz mieliśmy dwutygodniowe sprinty oraz stand-upy. Na tym Scrum się kończył. Co gorsza, stand-upy odbywały się nieregularnie i po jakimś czasie przestałem być informowany, czy stand-up się odbędzie, czy też nie.

W moim następnym zespole pracowaliśmy bardzo mocno w duchu Agile. Tam tak naprawdę poczułem, czym jest Scrum i jak skuteczne może być to rozwiązanie. Dzień po dniu przekonywałem się o tym, że realizacja projektów bez daily Scrums, planowania, dem itp. jest… bez sensu! A na pewno mało wydajna.

Po kolejnej zmianie pracy trafiłem do zespołu, który traktował założenia Scruma tylko jako sugestie i celowo nie korzystał z niektórych elementów tego frameworka. Heretycy – pomyślałem. Jednak po jakimś czasie zauważyłem, że nie odbijało się to na efektywności wykonywania zadań. Nie było problemu z komunikacją, planowaniem. Każdy wiedział, co ma robić. Wtedy też zrozumiałem, że można być produktywnym bez sztywnego trzymania się Scrum Guide’a.

Wiadomo, że każda firma jest inna, tak jak każdy zespół jest inny. Nie ma cudownego środka, który rozwiąże wszystkie problemy w teamie.

Czy codzienne stand-upy (daily Scrum) są zawsze potrzebne? Czy naprawdę każdy zespół IT w Polsce musi raz dziennie spotykać się na 15 min i rozmawiać o tym, co zrobił wczoraj i co zrobi dzisiaj? A może specjalny kanał na Slacku załatwiłby sprawę? Jeśli wszyscy siedzą koło siebie, to przecież wystarczyłoby się obrócić i powiedzieć: „Zrobiłem zadanie BUG-123, biorę teraz BUG-321, bo ludzie z BOK-u o to prosili”. Nie trzeba się powtarzać, a taka komunikacja wydaje się naturalna. No i co z zespołami, które pracują zdalnie albo w różnych strefach czasowych?

Warto podkreślić, że **nie każdy potrzebuje Scruma**. Jeśli zespół sprawnie wykonuje swoje zadania, to po co to zmieniać, wprowadzając dowolny framework?

Martin Fowler, jeden z autorów Agile manifesto, przypomina, że Scrum został stworzony przez programistów dla programistów. I to jest powód, dla którego właśnie developerzy powinni promować tę ideę. Nie żaden Agile Coach, który nie ma bladego pojęcia, jak dany zespół pracuje i z jakimi problemami się boryka. Członkowie zespołu sami powinni dojść do tego, jaką strategię przyjąć.

Musisz znaleźć kompetentnych ludzi, którzy dobrze się rozumieją na poziomie czysto ludzkim, tak aby mogli współpracować efektywnie. Wybór narzędzi i procesów, których używają, jest już drugorzędny.
Martin Fowler na InfoQ

Spodobało mi się też inne stwierdzenie: czasami żeby być Agile, trzeba zrezygnować ze Scruma. Jeśli w zespole i/lub organizacji nie ma wystarczającej świadomości, to próby wprowadzania zmian na siłę tylko spowolnią działania, zwiększą frustrację oraz pogorszą morale.

Dlatego też w Agile manifesto na pierwszym miejscu znajduje się zasada: Ludzie oraz interakcje ponad procesami i narzędziami.

A czy Wy pracujecie w Scrumie, czy może używacie innego frameworka, takiego jak Waterfall lub Kanban?
Jakie są Wasze doświadczenia z metodyką Agile?
Podzielcie się swoimi spostrzeżeniam w komentarzach poniżej!

PS Jest to tłumaczenie mojego artykułu z bloga developer20.com.