Broken Window Theory 

Dlaczego Broken Window Theory? Kilka tygodni temu, w poście dotyczącym Tajemniczego Agile Coacha pisałem o psuciu Scruma. Poruszyłem tam zagadnienie wybierania z metodyki najbardziej nam pasujących elementów i implementowaniu ich do naszego środowiska z nadzieją, że ich implementacja pomoże…

Broken Window Theory

Teoria zbitej szyby (ang. Broken Window Theory) narodziła się w Stanach Zjednoczonych w 1982 r. Dwóch naukowców, James Q. Wilson i George L. Kelling opublikowało artykuł, w którym zobrazowali jej sens na dwóch przykładach.

Pierwszy dotyczył budynku, w którym część szyb została wybita przez wandali. Zauważono, że pozostawienie szyb w takim stanie zachęca innych do dalszej destrukcji budynku (wybijania kolejnych szyb) lub w najgorszej sytuacji do włamania do budynku i zajęcia go przez osoby niepożądane.

Drugi przykład dotyczył chodnika, na którym znajdowały się śmieci. Pozostawienie go w takim stanie spowodowało eskalację problemu –  ludzie będą zostawiali na coraz to więcej śmieci, w dalszej kolejności (poprzez obniżenie rangi okolicy) mogą pojawić się też inne niepożądane zachowania, np. włamania do samochodów czy rozboje.

Test Zimbardo

Zanim Wilson i Kelling opublikowali swój artykuł, w 1969 r. Philip Zimbardo, psycholog ze Stanford, przeprowadził test, który weryfikował Broken Window Theory na prostym i sugestywnym przykładzie.

Postanowił on zbadać zachowanie ludzi mieszkających w dwóch różnych miejscach w odpowiedzi na tę samą sytuację. Zaparkował on samochód pozbawiony tablic rejestracyjnych w Bronxie (dzielnica Nowego Yorku) oraz w Palo Alto (miasto w Kalifornii).

Reakcje zaobserwowane w trakcie eksperymentu były skrajnie różne. Auto pozostawione w Nowym Yorku zostało „zaatakowane” w kilka minut po pozostawieniu go na miejscu parkingowym. Grabieży dokonała rodzina, która wymontowała z samochodu chłodnicę i baterie. Po pierwszej rozbiórce samochodu sprawy potoczyły się bardzo szybko, został zniszczony w oka mgnieniu. Ostatecznie służył on jako plac zabaw dla dzieci.

W tym samym czasie samochód w Palo Alto stał w stanie nienaruszonym przez ponad tydzień. Sytuacja zmieniła się dopiero wtedy, gdy sam autor eksperymentu naruszył samochód przy użyciu młota. Posiadający ślady dewastacji pojazd szybko zaczął podlegać temu samemu procesowi, co ten stojący w Nowym Jorku.

Zimbardo zauważył, że większość wandali dewastujących samochód w obu przypadkach to „normalni”, schludnie ubrani ludzie, jak również to, że na pozór były to osoby szanowane. Spostrzegł, że większą tendencję do destrukcji wykazywali ludzie mieszkający w miejscach o „podejrzanej” przeszłości, jak również to, że przyzwolenie do niszczenia cudzego mienia było większe w miejscu gdzie ludzie wykazywali bierną, apatyczną postawę.

Wandalizm, a Scrum

Co eksperyment polegający na niszczeniu samochodu w latach 60 XX wieku ma wspólnego ze Scrumem? Każda osoba pracująca na projektach prowadzonych metodyką zwinną na początku zwraca uwagę na wszystkie odstępstwa od zasad opisanych w Scrum Guide. Szczególnie, jeśli jest świeżo po szkoleniu.

„Przesuńmy Daily Scrum o 10 min, bo wykonuję ostatni commit” albo „nie róbmy tym razem Sprint Retrospective, bo przecież nic się szczególnego nie wydarzyło a dowieźliśmy właśnie 91% prognozy”.

Czy takie odstępstwa nie są właśnie zachowaniem polegającym na wybijaniu szyb, jedna po drugiej, w naszym „budynku” zwanym Scrum? Czy powinniśmy biernie przyglądać się temu, jak nasz Scrum, atakowany przez wandali staje się ruiną?

Odpowiedzi na to pytanie znamy wszyscy. Nie! Nie po to mozolnie budowaliśmy podstawy i mury tego „budynku”, aby teraz biernie przyglądać się jak jest burzony. Sam proces niszczenia nie musi być celowy, przecież jeśli jedna Retrospektywa się nie odbędzie nie stanie się nic złego. Problemem jest jednak to, że jedna retrospektywa pociągnie za sobą kolejne.

Mechanizm ten jest dobrze znany i łatwy do zobrazowania dla wszystkich, którzy byli na diecie albo trenowali na siłowni – ominięcie jednego treningu albo zjedzenie jednego pączka, tworzy wyłom, po którym cały misterny plan treningowy czy dieta idzie w odstawkę.

Jak w takim razie postępować?

W opublikowanym przez Jamesa Q. Wilsona i George’a L. Kellinga artykule o Broken Window Theory znajdziemy też nadzieję. Najskuteczniejszą metodą walki jest zauważenie i zaadresowanie problemu, kiedy jest jeszcze mały. Naprawa jednej lub kilku wybitych szyby, czy posprzątanie zaśmieconego chodnika, kiedy nie znajduje się na nim jeszcze dużo śmieci będzie łatwiejsza, niż duża akcja wymierzona w usuwanie skutków działania wandali.

Podobnie rzecz ma się ze Scrum. Podjęcie akcji naprawczych (np. poprzez uświadomienie zespołowi korzyści wynikających z przeprowadzenia Retrospektywy) spowoduje, że „zdusimy” problem w zarodku.

Kto powinien zauważyć problem i zaadresować go we właściwy sposób? Najlepszą do tego osobą będzie Scrum Master, który „dbając o rozumienie i stosowanie Scruma w organizacji” jest do tego najlepiej przygotowany. Oczywiście idealnie byłoby, gdyby wsparł go w tym (lub nawet wyręczył) sam zespół deweloperski.

Lepsze jest wrogiem dobrego

Scrum w najnowszej wersji, w polskim języku został opisany na 22 stronach. Zawierają one m.in. informacje o trzech rolach, pięciu wydarzeniach i trzech artefaktach. Czy to dużo? Czy faktycznie powinniśmy „grzebać” przez silniku, jeśli pracuje on dobrze i nie powoduje problemów w eksploatacji?

Lepsze jest wrogiem dobrego. Autorzy ograniczyli się do niezbędnego minimum, aby zapewnić prawidłową pracę zespołu deweloperskiego. Zaproponowany przez Kena Schwabera i Jeffa Sutherlanda framework jest na tyle lekki, że nie ma potrzeby ograniczania go o dodatkowe elementy.

A co z tymi, którzy twierdzą, Scrum w ich organizacji nie działa? Odpowiedzi mogą być dwie. Albo wybiliśmy już zbyt dużo szyb w naszym „budynku” i potrzebny będzie remont generalny, albo doświadczamy zupełnie innego problemu, którym może być np. skala naszego projektu i wynikające z tego wyzwania.

Zanim jednak uznamy, że problem wynika z otoczenia, bądź specyfiki naszej sytuacji, wróćmy do 22 stron Podręcznika Scrum i sprawdźmy czy kiedykolwiek stosowaliśmy się do wszystkich opisanych w nim zasad. Bo być może nasza budowla została wzniesiona z już wybitymi szybami.

Uwielbiamy taką tematykę i nie możemy się powstrzymać, żeby nie wplatać jej w nasze szkolenia Scrum i agile.