Zwinność a status quo

Jedną z zasadniczych przyczyn, dla których powstał SCRUM, Kanban System i inne metodyki z rodziny Agile było poszukiwanie takiego sposobu pracy, który pozwalałby reagować na ciągłe i nie dające się efektywnie przewidywać zmiany; mogą one bez trudu zniweczyć wysiłki zespołów developerskich w realizowaniu celów biznesowych, a i same cele równie szybko potrafią się pozmieniać.

Dlatego podstawą SCRUM jest gotowość do zmiany i umiejętność dostosowania się w możliwie najkrótszym czasie. To wymaga takiego zorganizowania sposobu pracy i narzędzi używanych przez zespół, by dostosowanie było proste i jak najmniej kosztowne.

Czytającym SCRUM Guide lub książki na temat tej metody czasami umyka dość podstawowy fakt: każdy sprint jest eksperymentem, na końcu którego dokonać należy oceny wyników tego eksperymentu i zdecydować o niezbędnych zmianach. Dotyczy to zarówno produktu, jak i procesu. Jeśli niemożliwa stanie się adaptacja (lub inaczej: nie będzie możliwe dokonywanie zmian), eksperyment może stać się bezcelowy, bo i tak nie uda się wdrożyć w życie wniosków wyciągniętych po jego zakończeniu.

Obrona status quo

Aby nie było za łatwo, dążenie do zmian często spotyka się z oporem i obroną obecnego stanu rzeczy. Jest to naturalny odruch, wynikający najczęściej z obawy przed nieznanym. Przy czym ta obawa jest w znacznej mierze pochodną braku świadomości, że nieznane (w postaci zmian otoczenia, na które żadnego wpływu nie mamy) i tak do nas przyjdzie. Dlatego mimo, iż status quo wydaje się bezpieczną przystanią, wcześniej czy później ulegnie zmianie; lepiej zatem samemu jej dokonać ewolucyjnie, niż radzić sobie z odłożoną w czasie rewolucją.

W dużych organizacjach status quo bywa konserwowany również w efekcie źle przeprowadzonego rachunku zysków i strat związanych z proponowaną zmianą. Chcąc dokonać zmian świadomie, dąży się do zebrania informacji tak, by obraz spraw przed podjęciem decyzji był kompletny. To wymaga narzędzi i czasu i daje złudne poczucie kontroli nad rzeczywistością. Pojawia się potem od razu argument za zachowaniem status quo: zmiany mogą pozbawić „kontroli” i wymagać inwestycji w narzędzia, które pozwalają na zbieranie informacji niezbędnych do podejmowania decyzji, więc są niepożądane.

Sprint przez płotki

W rezultacie dążenia organizacji do zachowania status quo wiele zespołów SCRUMowych nie może działać w pełni zwinnie. Bywają przymuszane do raportowania stanu prac w takiej formie, że wpływa to wprost na sposób, w jaki pracują. Narzucane są narzędzia, które dostosowane są do potrzeb zupełnie innych użytkowników niż zespoły developerskie, więc nie pomagają a czasami utrudniają organizowanie pracy zespołu. Zdarza się, że proces, jakiego musi się trzymać zespół, jest zdefiniowany odgórnie i nie może być przez developerów samodzielnie modyfikowany. Równie upiornym ale częstym zjawiskiem jest dążenie do unifikacji narzędzi, procesów (i procedur).

Zwinny, czyli nieograniczony

Jednym z gwarantów zwinności w SCRUM jest pozwolenie zespołowi na samodzielne organizowanie swej pracy. To oznacza, że organizacja musi ustąpić pola zespołom i zrezygnować z prób moderowania sposobu ich pracy. Dotyczy to zarówno procesów, jak i narzędzi czy sposobu komunikacji. Bez wątpienia jest to wyzwanie dla kadry zarządzającej, by jednocześnie ograniczyć kontrolę i zrezygnować z wpływania na to, co dzieje się wewnątrz zespołów developerskich. Jakkolwiek wydaje się to przepisem na katastrofę, daje zaskakująco pozytywne efekty.

Dlatego chcąc działać w sposób zwinny należy nieustannie rzucać wyzwanie status quo tam, gdzie objawy jego istnienia są dostrzegalne. Nie chodzi tu rzecz jasna o zmienianie wszystkiego cały czas, ale o możliwość zmiany (adaptacji) wtedy, kiedy tego potrzeba, i w takim zakresie, jaki jest niezbędny.

A jak ma się status quo w waszych organizacjach? Nikt o nim nie słyszał, bo poszło popijać herbatkę z Yeti, czy też ma się dobrze? Jak radzicie sobie z obawami i oporem przed zezwoleniem na pełną samoorganizację w zespołach developerskich?