scrum nieprawdziwe opinie i mity

Nieprawdziwe opinie o Scrumie, których nie lubię najbardziej

Agile, Scrum, Zarządzanie projektami IT

Scrum jest łatwy do zrozumienia, ale trudny do opanowania. Tak napisano w Scrum Guide i nie mogę się z tym nie zgodzić. Z tych trudności wyrastają nieprawdziwe opinie o Scrumie. Ten post zatem to moja osobista próba zmierzenia się z tymi z nich, które słyszę co jakiś czas, a których bardzo nie lubię :)

#1 Zwinność to brak planu i ciągłe wrzutki

Waterfall nie dawał zbyt wielu szans na zmiany i szybkie reagowanie na rzeczywistość rynkową. Tym samym Ci, którzy mają szansę pracować zwinnie sądzą, że teraz mają pełne możliwości zakłócania biegu sprintów różnego rodzaju wrzutkami. Nawet jeśli tego nie wyrażają wprost słowami to ich czyny to wyraźnie pokazują – wg nich właśnie na tym polega zwinność. Zespoły próbują z tym walczyć i np. skracają czas trwania sprintów, aby takie wrzuty czekały tylko tydzień. Czasem przesiadają się na kolejkę kanbanową – chociaż zapominają, że tę też trzeba jakoś ułożyć, nadać zadaniom priorytety itd.

I w ten sposób, przez ciągłe wrzuty i zakłócenia, organizacja traci jedną z wielu zalet Scruma – zespół samoorganizujący się, który ma okazję popracować np. przez 2 tygodnie nad wytworzeniem czegoś naprawdę fajnego, w sprzyjającej atmosferze, dając z siebie wszystko. Team ląduje zatem na polu walki o priorytety, konkrety, szarpiąc się o precyzyjniejsze opisywanie wymagań itd. A z reguły i tak okazuje się, że tona rzeczy “na wczoraj” wypycha starszą tonę takich spraw i organizacja znajdzie się ostatecznie w miejscu gdzie wszystko co pilne ma taki sam, “normalny” priorytet. I nikt nie łapie czemu to wszystko się wywala. Przełączanie między wątkami skutkuje tym, że przyrost dostarczany jest wolniej lub z błędami. Wartości gubione są w chaosie walki.

 

#2 Scrum to tylko spotkania, a nie realna praca

Czy serio Scrum tak dużo wymaga? Poza tym czy te spotkania muszą być czymś złym i nie dostarczają żadnej wartości? Dla miesięcznego sprintu to: Daily: 15 min dziennie; Planowanie: do 8 godzin; Review do 4 godzin; Retrospective do 3. Jeszcze doliczmy Refinement, który średnio zajmą 10% czasu w sprincie. Podane czasy są maksymalne – często uda się je zdecydowanie skrócić. Czy to naprawdę dużo?

Może problem nie leży w czasie, a w wartościach jakie spotkania dostarczają? Może daily jest zwykłym statusowaniem, retro to oskarżenia, review okazja do ponarzekania, a refinement to praca bez żadnych efektów? Jeśli tak to na Twoim miejscu też chciałbym, aby trwały jak najkrócej lub nie było ich w ogóle ;-) Jeden znajomy wspominał mi o daily pewnego teamu, w którym pracował jako programista, które to daily trwało przez 1h! Codziennie… Gdzie time-box?

Po prostu, trzeba koniecznie sprawdzić czy formuła, organizacja spotkań i wartości które dostarczają są właściwe. One mają konkretny cel i time-box. Prowadzone dobrze przynoszą wiele korzyści.

 

Nieprawdziwe opinie o Scrumie

#3 Scrum działa tylko z małymi projektami

Tego “mitu” nie lubię szczególnie. Argumenty, na które trafiam to np. “do projektu musi powstać gigantyczna baza danych, infrastruktura, api i inne, których nie da się wytworzyć w jednym sprincie. Przez 12 miesięcy użytkownicy i tak niczego nie zobaczą. Scrum zatem tu nie zadziała”.

Najczęściej argumenty te wynikają z niezrozumienia czym jest Scrum, co oznaczają w nim “potentially shippable” i “Definition of Done”. Oraz o co chodzi w dostarczaniu wartości. Pozwolę sobie zacytować Mike’a Cohna z jego książki “Succeeding with Agile. Software Developement Using Scrum”:

“[…] it is important to remember that the two primary benefits of delivering value each sprint are the ability to solicit feedback as early as possible and the assurance that the team members are never in a position to deceive themselves (even unintentionally) about their progress.

I will grant that on some projects we may not be able to get useful enduser feedback for a few months, but I still want complete, working, tested functionality each sprint. If that funcionality is not quite yet something that my end users will be able to see (or see the value of), then I make sure that my product owner can understand the value of what’s been completed. With the product owner acting as a rigorous judge of whether the team has taken a step in the right direction (always preferring working software over documentation), the team is unlikely to take steps that result in a lot of activity but little forward progress.”

 

Poza tym, co to oznacza mały projekt? Taki na 2 miesiące jest mały dla teamu 7 deweloperów? A może roczny jest de facto kilkoma dwumiesięcznymi albo kilkudziesięcioma, ale jeszcze krótszymi? Może, gdy spojrzymy na cały roczny projekt, jak na coś co składa się z dużo mniejszych to uda nam się zrozumieć, że to kwestia tego jak dzielimy duże rzeczy. Czasem będzie ciężko dostarczyć “potentially shippable”, dzielić na odpowiedniej wielkości kawałki pasujące do sprintu. Ale nawet jeśli to jest trudne to czy oznacza od razu, że nie można tego zrobić? Poza tym potentially nie oznacza, że rzeczywiście projekt zostanie wydany użytkownikowi. To znaczy, że potencjalnie można byłoby to zrobić, ale jeśli produkt nie jest jeszcze w takim stanie, że chcemy się na to zdecydować to tego nie robimy. Co nie zwalnia nas z obowiązku dostarczenia działających, przetestowanych, zintegrowanych z resztą “systemu” elementów w każdym sprincie.

 

#4 W Scrumie brakuje dyscypliny, którą daje tylko podejście kaskadowe

Wyjątkowo głupie podejście. Jeśli projekty prowadzone są transparentnie, z regularnym spotkaniami, na których prezentowana jest wykonana praca itd., to jakim cudem ludzie mogą być mniej zdyscyplinowani? Może nie chodzą jak w wojsku, z drącym się sierżantem do ucha, ale czy o taką dyscyplinę chodzi w projektach IT?

Interesariusze mogą w bardzo krótkich odstępach czasu zobaczyć co jest wytwarzane, reagować. To skutkuje większą koncentracją nad tym, aby team dostarczył coś z czego może być dumny, czym może się pochwalić, że zrobił dobrze. W Scrumie feedback jest ciągle dostarczany, więc cały czas wiemy czy idziemy we właściwym kierunku. Czy w takiej atmosferze ktoś może być niezdyscyplinowany?

A może takie opinie na temat dyscypliny w Scrumie to efekt braku zaufania do ludzi? Być może ten kto tworzy takie opinie lubi poczucie bezpieczeństwa i kontroli, które są po prostu łatwiej dostrzegalne w kaskadowym podejściu i sztywnej postawie?

 

#5 Scrum rozwiąże wszystkie problemy

Nie rozwiąże, mimo tego że jest super :) Scrum to po prostu narzędzie. Nie lekarstwo. Może akurat problem leży w nieumiejętnym zarządzaniu całą organizacją, złej komunikacji na szczeblach menedżerskich, złym traktowaniu ludzi, negatywnym nastawieniu i nie jest związany w ogóle z metodami wytwarzania i wystąpiłby przy Waterfallu czy każdej innej praktyce? To co jest fascynujące w Scrumie to fakt, że sprzyja transparentności, zaufaniu i dobrej komunikacji. Sprzyja, ale jej nie zapewnia, bo nadal czynnik ludzki decyduje o tym czy się uda czy nie. Nie wystarczy stworzyć backlogu, powiedzieć, że od dzisiaj pracujemy w Scrumie i projekty się same ułożą. To tak nie działa :) No i potrzebny jest czas – dojrzewanie to proces. Niestety często jest tak, że Scrum wprowadzony jest częściowo i firma żyje w pewnej bajce – tam gdzie Scrum mógłby pomóc nie pomoże, bo go nie ma, ale ponieważ wdrożono pewne jego elementy (np. artefakty) to słychać szepty, że “Scrum nie działa w naszym przypadku”.

Od stwierdzeń typu “Scum jest lekiem na wszystko” lub “Scrum nie działa”, jeśli nie zostaną odpowiednio szybko ubite, niedaleko leży wniosek, że “Scrum się jednak nie sprawdza (czyli nie leczy wszystkiego), więc go zmieńmy na ….”. Zatem piąta opinia jest wyjątkowo niebezpieczna. I sądzę, że przy takim braku konsekwencji żadna metoda pracy się nie sprawdzi.

Nieprawdziwe opinie o Scrumie znikajcie! ;-)

Początkowo sam nie rozumiałem wielu kwestii. I do dzisiaj się uczę Scruma i zwinności. Długa drogą przede mną. Wiem jednak, że ucząc się, popełniając błędy można wiele zrozumieć. Ważne, aby mieć otwarty umysł, zadawać pytania i nie bać się odpowiedzi. Sprawdzać je i testować w praktyce. Jeśli podzielasz jedną z wymienionych wyżej 5 opinii to mam nadzieję, że chociaż zasiałem ziarenko przemyśleń :) Podziel się swoim zdaniem w sekcji z komentarzami.

Wykorzystane w poście grafiki / zdjęcia: Patrick Tomasso, Joanna Malinowska

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *