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

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

Czytającym Scrum Guide lub książki na temat metody Scrum czasami umyka dość podstawowy fakt: każdy Sprint jest eksperymentem, na którego końcu dokonać należy oceny wyników tego eksperymentu i zdecydować o dalszym sposobie działania (dostosować plany, jeśli okaże się to niezbędne). Stawiamy tezę, że coś da się zrobić i że przyniesie to spodziewaną wartość – a potem sprawdzamy, czy faktycznie tak się stało. To sprawdzenie dotyczy zarówno produktu, jak i procesu, bo przecież niemożność uzyskania oczekiwanej wartości często wynika nie z przyczyn obiektywnych, ale jest wynikiem nieefektywnej organizacji pracy Zespołu.

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. A wtedy reagowanie na zmienność otoczenia i potrzeb może okazać się niemożliwe lub będzie spóźnione i nieskuteczne.

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 konserwowane 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. Celem jest, co oczywiste, przeprowadzenie analizy, która posłuży za podstawę dalszych działań w poczuciu, że wszystko już wiadomo. To wymaga narzędzi i czasu, ale daje złudne poczucie kontroli nad rzeczywistością. Pojawia się potem niestety od razu argument za zachowaniem status quo: zmiany mogą pozbawić tej złudnej „kontroli” i wymagać inwestycji w narzędzia oraz praktyki zwinne, więc są niepożądane.

Sprint przez płotki

W rezultacie dążenia organizacji do zachowania status quo wiele Zespołów Scrum nie może działać w pełni zwinnie. Bywają przymuszane do raportowania stanu prac w takiej formie, która wpływa wprost na sposób, w jaki pracują. Narzucane są narzędzia, które dostosowane są do potrzeb zupełnie innych użytkowników niż Developerzy, 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 Zespół samodzielnie modyfikowany. Równie upiornym i częstym zjawiskiem jest dążenie do unifikacji narzędzi, procesów i procedur.

Zwinny, czyli rozsądnie nieograniczony

Jednym z gwarantów zwinności w Scrumie jest pozwolenie Zespołowi na samodzielne zarządzanie swoją pracą (jej organizowanie). To oznacza, że organizacja musi ustąpić pola Zespołom i zrezygnować z prób moderowania ich pracy w Sprintach. Dotyczy to zarówno procesów, jak i narzędzi czy sposobu komunikacji. Nie chodzi przy tym o danie pełnej swobody, ale o zapewnienie wystarczającej przestrzeni, by ci, co wykonują pracę, mogli samodzielnie wybrać sposób swojego działania, zamiast ślepo trzymać się narzuconych procedur. Im dojrzalszy jest Zespół, tym większej swobody będzie potrzebował, by móc dalej się rozwijać.

Bez wątpienia jest to wyzwanie dla kadry zarządzającej, by ograniczyć kontrolę i zrezygnować z bezpośredniego wpływania na to, co dzieje się wewnątrz Zespołów. 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 Scrum?