Trzy relacje z frameworkiem
Zanim powiem, kiedy rama staje się klatką - musimy porozmawiać o tym, jak w ogóle do niej wchodzimy. Bo jest kilka wejść. I każde ma swoją cenę.
By the book
Scrum Guide mówi, że sprint trwa od jednego do czterech tygodni. W jednej firmie dostałem odpowiedź: “Robimy dwa tygodnie, bo tak jest w książce.” Fine. Zapytałem: “A co dostarczacie po tych dwóch tygodniach?” Cisza. Potem: “No… pracujemy.”
To jest relacja “by the book”. Precyzja co do formy, głucha cisza co do celu.
Co to daje:
- Wspólny język - wszyscy wiedzą, co to Sprint Review
- Bezpieczeństwo - “robimy jak w Guide, nie możemy być winni”
- Przewidywalność struktury
Co to kosztuje:
- Energia idzie w przestrzeganie rytuałów, nie w wartość
- Każde odchylenie od “podręcznika” staje się problemem do rozwiązania
- Zespół zaczyna pytać “czy to jest zgodne ze Scrumem?” zamiast “czy to działa?”
Od zera
Byłem kiedyś w firmie, gdzie Product Owner powiedział: “Scrum nas spowalnia, robimy po swojemu.” I rzeczywiście - zbudowali swój proces. Zwinny, dopasowany, skuteczny. Przez sześć miesięcy. Potem firma urosła. Dołączyli nowi ludzie. I okazało się, że “po swojemu” było zakodowane w głowach trzech oryginalnych członków zespołu, a nikt nie potrafił tego przekazać.
Podejście “od zera” ma prawdziwą wartość - zmusza do myślenia. Do pytania “dlaczego?”. Ale “od zera” bywa też odcięciem od cudzych błędów… i od cudzych rozwiązań na te błędy. Ktoś to już przerabiał. Ktoś zapłacił za tę lekcję. Może warto skorzystać?
Co to daje:
- Właścicielstwo procesu - naprawdę twój, a nie cudzy
- Brak ślepego podążania za modą
- Autentyczna elastyczność
Co to kosztuje:
- Reinventujesz koło - często krzywe
- Tracisz czas na eksperymenty, które ktoś przeprowadził dwadzieścia lat temu
- Skalowalność staje się koszmarem, bo “twój system” żyje tylko w głowach
Ze zrozumieniem
To trzecia droga. I najtrudniejsza - nie dlatego, że wymaga więcej wiedzy, ale dlatego, że wymaga więcej odwagi do zadawania pytań.
Widziałem to w zespole w sektorze naftowym (tak, coaching poza IT to inna przygoda). Liderzy rozumieli, po co jest Sprint Review - nie dlatego, że “Scrum Guide tak mówi”, ale dlatego, że potrzebowali regularnej pętli feedbacku od biznesu. Kiedy jeden ze stakeholderów zniknął na dwa miesiące, nie płakali nad “brakiem zgodności z frameworkiem”. Zaprojektowali alternatywny mechanizm. I wrócili do Review, gdy stakeholder wrócił. Środek. Nie cel.
Co to daje:
- Framework jako narzędzie, a nie jako dogmat
- Elastyczność bez chaosu
- Umiejętność modyfikacji bez utraty sensu
Co to kosztuje:
- Ciągłą potrzebę wyjaśniania “dlaczego” - szczególnie nowym osobom
- Ryzyko, że “ze zrozumieniem” staje się wymówką dla “jak mi wygodnie”
- Więcej rozmów, mniej pracy na autopilocie
Kiedy framework staje się klatką
Są sygnały. Kilka konkretnych, z pola walki.
Rytuał bez celu. “Robimy retrospektywę w piątek.” Świetnie. Co zmieniliście po ostatnich pięciu retro? Cisza. Robimy retro, bo “tak się robi w Scrumie”. Ceremonia bez efektu. Teatr procesu.
Obrona procesu, nie wartości. “Nie możemy skrócić sprintu, bo mamy dwa tygodnie.” Dlaczego dwa tygodnie? “Bo tak zaczęliśmy.” Kiedy ostatnio pytaliście, czy to tempo wciąż służy waszemu produktowi?
Mierzenie zgodności z frameworkiem, nie efektu. W jednej firmie mieli na dashboardzie “Scrum Maturity Level”. Osiemnastka na dwadzieścia. Byłem zachwycony. Zapytałem o Time to Market - nie mierzą. O NPS - nie mierzą. O to, czy użytkownicy w ogóle używają tego, co dowożą. Patrzyli na mnie jak na kosmitę.
Kiedy framework staje się klatką? Kiedy pytasz “czy robimy to zgodnie z frameworkiem?” zamiast “czy to nam służy?” Subtelne. Ale jak wejdzie w nawyk - potrafi zamrozić całą organizację.
Myślenie od pierwszych zasad - jak to wygląda naprawdę
“First principles thinking” - brzmi jak coś z konferencji TED. Elon Musk. Baterie. Blah blah. W praktyce? To po prostu rozkładanie problemu na mniejsze części. I pytanie “dlaczego?” przy każdej z nich - aż nie zostanie ci nic, co przyjmujesz na wiarę. Zamiast “bo inni tak robią.”
Wygląda to tak…
Pracowałem z liderem dużej jednostki biznesowej w firmie ubezpieczeniowej. Transformacja od roku. Scrumowali jak z książki. I mieli problem: Sprint Review wyglądał jak prezentacja zarządowi, a nie jak pętla feedbacku.
Zapytałem: “Po co robisz Sprint Review?” “No… bo Scrum Guide mówi.” “Okay. Ale gdyby Scrum Guide nie mówił - po co byś to robił? Czego potrzebujesz po każdym sprincie?”
Cisza. Potem: “Właściwie to potrzebuję wiedzieć, czy to, co zbudowaliśmy, idzie w dobrym kierunku.” “I jak teraz wiesz?” “Nie wiem.”
Trzy pytania. I już wiedział, że ma demo-dla-zarządu, a potrzebuje mechanizmu-uczenia-się. To dwie różne rzeczy. Framework dał mu narzędzie. On musiał zrozumieć, do czego je użyć.
Myślenie od pierwszych zasad nie polega na wyrzucaniu frameworków. Polega na rozumieniu, jaki problem framework rozwiązuje - i czy twój problem jest tym samym problemem. Czasem jest. Czasem nie.
Mój ulubiony moment
Mam ulubiony moment w pracy z organizacjami. Nie jest nim moment, kiedy zespół skutecznie wdroży Scrum. Nie kiedy wypełni wszystkie ceremonie. Nie kiedy osiągnie “Scrum Maturity Level 18/20”.
Mój ulubiony moment jest wtedy, kiedy ktoś - lider, Scrum Master, Product Owner, developer - mówi:
“Słuchaj, to nie ma sensu. Po co my to w ogóle robimy?”
To jest ten moment. Kiedy framework przestaje być święty.
Ale uwaga - ten moment nie bierze się znikąd. Poprzedza go zwykle frustracja. Kilka sprintów, które “zaliczyliśmy”, ale nic nie dowieźliśmy. Kilka retro, po których nic się nie zmieniło. Kilka Daily, na których wszyscy powiedzieli “u mnie wszystko OK”, a sprint skończył się klęską. Kiedy frustracja jest wystarczająco duża - pojawia się pytanie. I to pytanie jest początkiem prawdziwej pracy.
Co po nim następuje? Zależy. Czasem rozmowa, która trwa dwie godziny i kończy się: “OK, to jak naprawdę chcemy pracować?” Czasem zmiana jednej ceremonii, żeby sprawdzić, czy coś się poprawi. Czasem świadoma decyzja, że ten fragment frameworka im nie służy.
Świadome. To klucz.
Nie “nie robimy retro, bo nie ma czasu.” To: “nie robimy retro w tej formie, bo nie przynosi nam wartości - zamiast tego robimy X.” Różnica jest ogromna. W pierwszym przypadku framework się rozpada bez planu. W drugim - ewoluuje ze zrozumieniem.
Sprawdzian na środę o 14:00
Scrum sam o sobie mówi, że jest “lekkim frameworkiem”. To prawda. Jest lekki. My z niego potrafimy zrobić betonową ścianę.
Nie winię za to nikogo - ja też przez to przechodziłem. Miałem fazę “by the book”, miałem fazę “wyrzućmy wszystko i zacznijmy od nowa”. Dojrzewanie do trzeciej relacji - tej ze zrozumieniem - zajmuje czas i wymaga popełnienia sporych błędów.
Ale jest jeden prosty sprawdzian. Możesz go zrobić w środku tygodnia pełnego spotkań, nawet bez flipcharta.
Weź jedno wydarzenie z najbliższego sprintu - Daily, Review, Retro, Sprint Planning - i zadaj sobie pytanie:
Czy robię to, bo rozumiem po co - czy dlatego, że “tak się robi”?
A jeśli ta odpowiedź jest uczciwa… to wiesz, co robić dalej.
Więc - czy dziś twój framework cię wspiera, czy ty obsługujesz jego?