Eliminacja utrudnień

Istnieją gotowe metody, z których możemy skorzystać. Scrum jest jedną z nich, ale nie jedyną. Jeśli się na niego zdecydujemy, upewnijmy się, że go rozumiemy i bądźmy gotowi na ogromne trudności w pierwszych Sprintach. To nie Scrum je wygeneruje, tylko uczyni je boleśnie widocznymi – one już są w naszej organizacji. Nie mówmy zatem, że „u nas Scrum coś nie bardzo działa”.

Zamiast odrzucać metodę, szukajmy sposobu, by co Sprint działać lepiej. I celem wcale nie będzie uzyskanie dobrego Scruma, ale doprowadzenie do tego, żeby móc użyć dobrego Scruma i skonsumować korzyści, jakie to daje. Organizacja, która to potrafi (w której Scrum może bez trudu być zastosowany), prawie zawsze jest efektywna i skuteczna w tym, czego się podejmuje. I niemal bez wyjątku jest skuteczniejsza i bardziej efektywna od konkurencji, która zwinnie działać nie potrafi, a również zmaga się ze złożonymi problemami.

Są inne metody (np. Extreme Programming, Crystal), inne podejścia (np. Theory of Constraints, Lean), różne strategie, po jakie możemy sięgnąć (np. Kanban). Używajmy ich świadomie, podobnie jak opisałem to na przykładzie Scruma. Żadne z tych podejść, metod, frameworków czy metodyk nie jest gotową receptą, a jedynie ramą, która musi być wypełniona praktykami, ciężką pracą, kontekstem organizacji. Im lepiej organizacja (jej zespoły) to robią, tym lepsze efekty uzyskują.

A to oznacza, że nie trzeba być idealnym, by móc użyć metod Agile czy Lean. Trzeba być pragmatykiem i dążyć do usuwania deficytów z organizacji, zamiast obrażać się na rzeczywistość, jaką ujawniają te metody i arogancko twierdzić, iż istnieje jakaś metoda, której użycie udowodni, że nic nie trzeba w organizacji zmieniać.

Innym objawem arogancji, o którą możemy się potknąć, jest przekonanie o wyjątkowości sytuacji, w której znajduje się określony zespół lub cała organizacja. Ta wyjątkowość bardzo rzadko jest faktem, za to przekonanie o niej zdarza się wyjątkowo często. I jest wymówką, by uznawać nieefektywność i marnotrawstwo za coś akceptowalnego.

Zespół

Zwinne działanie (i każde inne również) nie przyniesie korzyści bez kompetentnych zespołów. Przyjmując, że korzystamy z empiryzmu, bo zmagamy się z niestabilną złożonością (czyli funkcjonujemy w środowisku o dużej zmienności i nieprzewidywalności), zdecydowanie utopią jest zbudowanie zespołów dobranych idealnie do tego, co będą miały one do zrobienia. Być może na początku da się to zrobić, jeśli skutecznie przewidzimy, w jaką stronę potoczą się sprawy. Szybko okaże się jednak, że kompetencje zespołów rozjeżdżają się z tym, co muszą one aktualnie robić.

Dlatego między bajki możemy włożyć przekonanie, że „zaplanujemy” zwinne zespoły z góry. Stwórzmy je najlepiej, jak potrafimy i pozwólmy empiryzmowi działać. Jeśli faktycznie składy zespołów będzie trzeba zmienić, one same zauważą to najszybciej i poinformują organizację. Pomijając dużo większą elastyczność takiej struktury i jej zdolność do dostosowywania się do aktualnego stanu spraw, da to zespołowi poczucie wpływu na środowisko, w jakim pracuje, a to jest jedno z głównych źródeł zaangażowania.

Rafał Markowicz Rafał Markowicz  

Developer, Scrum Master, praktyk Agile, Professional Scrum Trainer w Scrum.org, Professional Kanban Trainer w ProKanban.org.