Problem „kulawego Scruma”

Jak pełnić rolę scrumową w firmie, która ma „kulawego Scruma” – takie pytanie otrzymałem podczas szkolenia od jednego z Product Ownerów. W poniższym artykule próbuję na nie odpowiedzieć.

W naszym kontekście to nie ma sensu…

Kolejny typowy przypadek to ustalenie, że organizacja naprawdę nie potrzebuje podejścia zwinnego, bo nie boryka się z niestabilną złożonością. Nie myjemy okien łopatą (choć pewnie na upartego dałoby się), nie używajmy więc metod zwinnych (w tym Scruma) tam, gdzie nie ma to sensu. Pozostaje otwartym pytaniem, czy w dzisiejszych czasach są jeszcze domeny dostatecznie stabilne, by nie było potrzeby korzystania z empirycznej kontroli procesu – ale to temat na zupełnie inny artykuł. Przyjmijmy, że mamy silne przekonanie, że właśnie w takiej domenie funkcjonujemy.

Co wtedy? Ciężko być Product Ownerem i pełnić „scrumowe role” tam, gdzie Scrum nie ma sensu. Zapewne sięgniemy po inne metody, więc musimy dokonać transpozycji tego, za co chcemy odpowiadać, na role i/lub odpowiedzialności w tych innych metodach. Przecież nie chodzi o „etykietę”, pod jaką będziemy wykonywać pracę, ale o realny sens i wartość tej naszej pracy, nieprawdaż? No, chyba że jednak chodzi o „etykietę” – ale wtedy pewnie będziemy wyznawcami kultu cargo wspomnianego wcześniej, lub to my (niestety) tłoczyć będziemy na siłę Scruma do organizacji, w której jest on zbędny.

Poziom niewiedzy jest ogromny…

Przyjmijmy, że odkryliśmy, iż „kulawizna” naszego Scruma wynika z niewiedzy lub braku doświadczenia. Najlepsze, co można zrobić, to połączyć w spójną całość trzy działania. Po pierwsze postępować najlepiej, jak potrafimy jako Product Owner (albo ScrumMaster lub Developer), zgodnie ze Scrumem (a przynajmniej tak, jak go rozumiemy w danym momencie). Po drugie poszerzać swoją wiedzę o Scrumie, innych metodach zwinnych, praktykach i narzędziach (tego nigdy dość), a jak trzeba, uczyć tych rzeczy innych (Scrum Master wręcz ma obowiązek to robić). Po trzecie poszukiwać możliwości zmienienia stanu spraw, w szczególności poprzez unikanie oceniania innych, że „źle robią Scruma”, a zamiast tego pomaganie im w robieniu go choć troszkę lepiej lub chociaż danie im przykładu, jak można działać lepiej (w swoim zespole) i dlaczego się to opłaca.

Ten scenariusz jest bardzo podobny do pierwszego: na razie nie potrafimy lepiej działać w Scrumie, ale dążymy, by to zmienić. Różnica polega na tym, czy musimy aktywnie usuwać coś, co blokuje możliwości, czy raczej jest to pasywne ograniczenie wynikające z braku umiejętności, których dopiero nabywamy. O ile w pierwszym scenariuszu być może trzeba walczyć ze status quo, które będzie się mocno bronić, o tyle w tym przypadku borykać się będziemy głównie z własnymi ograniczeniami.

Czy istnieją inne scenariusze?

Niewątpliwie tak, opisałem kilka typowych i podpowiadam (na tak zwanym metapoziomie) jak sobie z nimi radzić. W praktyce nigdzie nie ma „instrukcji wdrożenia” do Scruma, nie ma też czegoś takiego jak „idealny Scrum”. Powód: to metoda ramowa (ang. framework), więc zawiera tylko minimalny zbiór zasad i praktyk, które zawsze musimy czymś uzupełnić, i w które jakoś musimy się wpisać. Im lepiej to zrobimy, tym więcej potencjalnych korzyści z tego będziemy mieli. Ot, cała magia Scruma.

Pamiętajmy też, że nie da się za dużo zmienić na raz, ani nie da się za wiele zmienić w krótkim czasie. Jest to jednocześnie o wiele trudniejsze, jeśli brak silnej woli zmian u tych, których zmiany te dotyczą. Inaczej mówiąc, należy być cierpliwym (ale nie masochistą) i stawiać sobie realne cele do osiągnięcia, czyli oczekiwać niewielkich, ale trwałych zmian. Póki cokolwiek się zmienia i tempo nie powoduje, że my stracimy motywację do dalszego działania, jest światełko w tunelu.