fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
HOT / 4 minut

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


12.11.2019

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.

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit

6
Dodaj komentarz

avatar
3 Comment threads
3 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
MichalBartłomiej KlimczakRadekMateusz Rus Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of
Mateusz Rus

Dobrze napisane, sam miałem takie epizody, że po prostu SCRUM był wprowadzony w pośpiechu i stał się tylko namiastką, czymś na pograniczu. 2-tygodniowe sprinty i Daily, o których każdy zapominał to za mało.

Dopiero w kolejnej organizacji, do której trafiłem było to tak jak należy. Wyceny, podsumowania, retro, daily codziennie o stałej godzinie. Powód był chyba głównie jeden – Scrum Master był wcześniej developerem z kilkuletnim stażem i wiedział jak tego pilnować.

Radek
Radek

A propos wspomnianego tutaj “Agile manifesto” polecam świetne wystąpienie jednego z autorów “Manifesto for Agile Software Development”. https://youtu.be/a-BOSpxYJ9M

Michal

Zgadza się – bardzo dobre wystąpienie. Dodatkowo Uncle Bob opublikował ciekawy komentarz do tego wystąpienia – https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html

Michal

Pozwolę sobie podlinkować killka swoich przemyśleń odnośnie Agile i Scrum:
– o tym, że Scrum Master/Agile Coach powinien mieć techniczny background i rozumieć problemy developerów – http://itea.org.pl/index.php/2019/01/02/quo-vadis-agile/
– o tym, że Scrum nie zawsze jest dobrym rozwiązaniem: http://itea.org.pl/index.php/2019/10/16/czy-scrum-nadaje-sie-do-projektow-utrzymaniowych/
– podcast o tym, że Scrum to nie tylko spotkania, artefakty i role, ale po pierwsze wartości i filary: https://porozmawiajmyoit.pl/scrum-uzupelnienie/

Scrum jest narzędziem, które pasuje do jednych zastosowań a do innych niekoniecznie. Jeśli widzimy, że w naszym zespole ten framework się nie sprawdza, może warto się zastanowić dla czego – krótki artykuł, który może być pomocny (analizę zacząłbym od punktu 5 :) https://medium.com/@jayhawkins_59300/5-reasons-why-scrum-fails-and-what-you-can-do-to-overcome-them-932e863b43c9

Moja książka

Facebook

Zobacz również