Dlaczego Scrum nie działa (I co możemy z tym zrobić)

Scrum to najbardziej popularny Agileowy framework. Koniec kropka. Jeśli spojrzymy na VersionOne 11th State of Agile report, Scrum jest praktykowany przez 58% respondentów (68% jeśli zsumujemy Scrum i Scrum/XP hybrid).

lut 14, 2019 1244
Scrum to najbardziej popularny Agile'owy framework. Koniec kropka. Jeśli spojrzymy na VersionOne 11th State of Agile report, Scrum jest praktykowany przez 58% respondentów (68% jeśli zsumujemy Scrum i Scrum/XP hybrid). Pomiędzy skalowaniem frameworków Scrum dominuje: podczas gdy Scrum-of-Scrums ma 27% (1% mniej niż Scaled Agile Framework), Scrum-of-Scrums, LeSS i Nexus łącznie mają 31%. Wierzę, że istnieją dwa główne powody tak dużego stopnia popularności. Pierwszy, Scrum jest prosty w zrozumieniu i przychodzi z jasną formułą - Scrum Guide. Drugi - działa poprzez pomaganie zespołowi w osiągnięciu sukcesu w sprawnym dostarczaniu wartości.

Dlaczego Scrum nie dziala (I co mozemy z tym zrobic).png


Wygląda więc na to, że w pierwszym akapicie doszedłem do wniosku, który jest sprzeczny z moim pierwszym twierdzeniem zawartym w tytule. Więc nie - Scrum naprawdę działa - ale tylko wtedy, gdy z sukcesem uda ci się go zaadaptować. Wierzę, że Scrum jest niezwykle potężny, a jego moc wyłania się z ciasnego połączenia ról, artefaktów i praktyk Scruma. Jego holistyczna natura została podkreślona w samym przewodniku Scruma: "Każdy składnik w obrębie frameworku ma określony cel i jest niezbędny dla sukcesu i wykorzystania Scruma." Oznacza to, że jedynym sposobem na uzyskanie pełnych korzyści ze Scruma jest dosłowne podążanie za Scrum Guide. Nie oznacza to, że nie można uzyskać przynajmniej niektórych korzyści z używania części Scruma (często określanej jako "Scrum, But"), ale:

A) nie powinno się tego nazywać "Scrum"

oraz

B) rzeczywiste wyniki są wysoce nieprzewidywalne.

Dlaczego miał(a)byś chcieć zaimplementować ScrumBut? Cóż, zakładając, że nie jesteś ignoracki/a, głównym powodem byłoby: "Jest to sprzeczne z kulturą naszej organizacji." Pomiędzy głównymi wyzwaniami przyjęcia Agile'a, stwierdzenie "Filozofia firmy lub kultura jest sprzeczna z podstawowymi wartościami Agile" jest na szczycie (i ciągle się podnosi) od conajmniej 6 lat, z wynikiem 63% w zeszłym roku. Tak więc w adaptacji Agile (i Scrum) kluczowe pytanie brzmi: "Jak możemy zmienić kulturę organizacyjną tak, aby obejmowała (a przynajmniej nie będzie sprzeczna) wartości i zasady Agile." Jedna możliwa odpowiedź na to pytanie jest znana jako Larman's 5th Law of Organizational Behaviour: "Kultura podąża za strukturą".

Jeśli chcesz naprawdę zmienić kulturę, musisz zacząć od zmiany struktury, ponieważ inaczej kultura tak naprawdę się nie zmieni. Spraw, by ludzie postępowali inaczej, oni dostosują swój sposób myślenia tak, że ten nowy sposób działania będzie zgodny z ich sposobem myślenia odnośnie ich działań. Tak właśnie działa Scrum (gdy jest w pełni wdrożony) - tworzy strukturę, która zmusza organizację do zwinności.

Wierzę, że Scrum działa dokładnie tak - nie tylko zmienia sposób, w jaki się coś robi, ale także zmienia sposób myślenia i system wierzeń zaangażowanych osób. Ale (i to jest wielki problem!), wprowadzanie ludzi w nowe środowisko z nowymi zasadami jest bolesne*, a więc zmienia sposób myślenia. A przy wyborze pomiędzy dwiema bolesnymi ścieżkami ludzie wybierają tę, która wiąże się z mniejszym bólem. A przynajmniej tę, która według nich przyniesie mniejszy ból**.

To prowadzi nas do zrozumienia kluczowego powodu niepowodzenia Scrum: po prostu wymaga on zbyt wielu zmian (i zbyt wiele bólu), żeby z nim działać. Jeśli kultura organizacji jest wystarczająco zbliżona do Agile, realizacja Scruma działa jak magia: doda napięcia, które wymusi zmiany kulturowe, prowadząc do sukcesu adopcji Scruma i transformacji Agile. Ale gdy odległość między kulturą organizacyjną a Agile staje się zbyt duża, egzekwowanie schematu Scrum działa odwrotnie. Teraz to nie tylko struktura kontra kultura, to struktura i kultura oraz niechęć do bólu w połączeniu. I wszyscy wiemy, jak wiele energii ludzie mogą skierować na awersję do bólu.

W ten sposób Scrum jest z góry skazany na porażkę i w zasadzie istnieją dwa sposoby, jak wydarzenia mogą się po tym rozwinąć. Jeden powraca do stwierdzenia faktu, że "Scrum (i Agile) nie pasuje do naszej firmy". Drugi zmienia Scrum, aby nie przynosił tak dużego napięcia (i bólu). Ten ostatni sposób prowadzi do różnego rodzaju "ScrumBut" i Cargo Cults, a w najlepszym przypadku doprowadzi do frustracji, irytacji i nieproduktywnego zachowania (a w najgorszym przypadku może doprowadzić organizację do totalnej katastrofy).

Scrum nie działa, gdy jest wymuszany na organizacji o słabo kompatybilnej kulturze. Czy to oznacza, że Scrum jest zły? Nie. Ale sugeruje to, że dosłownie podążanie za przewodnikiem Scrum nie jest odpowiednie dla każdej organizacji, a Scrum Master musi dokładnie przemyśleć sposób wdrożenia Scruma. Może to oznaczać, że Scrum nie będzie działał od samego początku, a my postaramy się stopniowo przybliżać naszą strukturę do Scruma, unikając postawy "trafienia za pierwszym razem".

Jest to pierwsza z serii postów na temat mojej percepcji dotyczącej coachingu Agile, jego wyzwań oraz wad. W żadnym wypadku nie twierdzę, że znam wszystkie odpowiedzi. Mam raczej nadzieję, że pisząc to (i zastanawiając się nad waszą opinią), mógłbym to głębiej przemyśleć i być może znaleźć wiarygodną odpowiedź na główne pytanie dotyczące zwinnego coachingu: jak pomóc organizacji przejść przez udaną transformację Agile. W następnym wpisie rozważę niektóre z pytań, które lider zmian powinien rozważyć projektując plan transformacji Agile.

* Używam słowa "ból" tutaj jako "nieprzyjemne odczucia zmysłowe i emocjonalne związane z faktycznym lub potencjalnym uszkodzeniem tkanki lub opisane w kategoriach takich uszkodzeń", zgodnie z definicją Międzynarodowego Towarzystwa Badania Bólu

** Czasami takie porównanie może być bardzo podchwytliwe ponieważ należy brać pod uwagę nie tylko obecny ból, ale mimo że przyjmujemy strategiczny pogląd i porównujemy oczekiwane bóle w pewnym szerszym przedziale czasowym. Ale to nie zmienia głównego twierdzenia

Sergey Makarkin
Chief Program Manager

Udostępnij


Masz jeszcze jakieś pytania?
Skontaktuj się z nami
Thank you.
Your request has been received.