Czy Scrum jest przestarzały w erze AI?

Co kilka lat ktoś ogłasza koniec Scruma. Najpierw miał go zabić DevOps, potem praca zdalna, potem skalowanie. Teraz ma go zabić AI. 

Czy Scrum jest przestarzały w erze AI? Warto potraktować to pytanie poważnie, bo po latach pracy jako Scrum Master nauczyłem się, że pod każdym takim nagłówkiem kryje się zwykle jedno realne pytanie. Tym razem też się kryje. Nie brzmi ono jednak: „czy Scrum umarł?”. Brzmi raczej: czy sposób, w jaki wdrożyliśmy Scruma kilka albo kilkanaście lat temu, nadal pasuje do software developmentu, w którym coraz więcej pracy wykonują agenci AI?

Moja odpowiedź nie brzmi ani „tak”, ani proste „nie”. Brzmi: Scrum nie jest przestarzały w erze AI. Przestarzała bywa jego sztywna, rytualna implementacja. To, czy Scrum nadal pomaga zespołowi, zależy od tego, czy traktujemy go jako lekki framework oparty na empiryzmie, czy jako zestaw spotkań, estymacji i dashboardów, których nikt już nie poddaje inspekcji. I to rozróżnienie nigdy nie było tak istotne jak teraz.

W skrócie: co AI naprawdę zmienia w Scrumie?

AI nie sprawia, że zespoły przestają potrzebować Scruma, Sprint Review, Retrospektywy czy Definition of Done. Sprawia natomiast, że stare założenia o tym, gdzie w procesie znajduje się największe ograniczenie, zaczynają się kruszyć. 
Przez lata wiele zespołów organizowało pracę wokół założenia, że najwolniejszą, najdroższą i najbardziej niepewną częścią delivery jest samo wytwarzanie kodu. W erze agentów AI to założenie coraz częściej przestaje być prawdziwe. 
Kod nadal musi być poprawny. Nadal musi pasować do systemu. Nadal wymaga osądu. Ale sam akt generowania kodu, czyli czynność, wokół której wiele zespołów nieświadomie poukładało swoje praktyki, przestaje być jedynym wąskim gardłem. 
Nowe wąskie gardło przesuwa się w dwie strony: w lewo, do specyfikacji, oraz w prawo, do weryfikacji.

Scrum Guide nie opisuje rytuału. Opisuje framework.

Zacznijmy od uczciwego postawienia sprawy. Scrum Guide nakazuje zaskakująco niewiele. Opisuje trzy filary empiryzmu: transparentność, inspekcję i adaptację. Definiuje odpowiedzialności Product Ownera, Developers i Scrum Mastera. Wskazuje wydarzenia, artefakty oraz reguły, które je spinają. 
To wszystko. Reszta, czyli to, co często nazywamy „naszym Scrumem”, jest już warstwą praktyk, które dołożyliśmy sami: sposób estymacji, interpretacja Definition of Done, narzędzia, rytm spotkań, format refinementu, sposób prowadzenia Sprint Review, dashboardy, raporty, zależności, wyjątki i lokalne kompromisy. To właśnie w tej warstwie, a nie w samym Scrum Guide, siedzi ciche założenie, które większość zespołów wniosła do Scruma i nigdy go nie nazwała: 
wytwarzanie oprogramowania jest tą drogą, wolną i niepewną częścią dostarczania, więc nasze praktyki muszą zarządzać głównie przepustowością zespołu deweloperskiego. Przez lata to założenie było użyteczne. Dlatego tak głęboko wrosło w sposób, w jaki implementujemy Scruma, że przestaliśmy je zauważać. 
A właśnie teraz ono zaczyna się kruszyć. 

Co AI naprawdę zmienia w software development?

Bądźmy precyzyjni, bo szum wokół AI w software development jest ogłuszający. Agenci AI nie „budują złożonych aplikacji w kilka godzin” w realnym środowisku enterprise. To slogan sprzedażowy. 
To, co realnie się dzieje, jest mniej spektakularne w nagłówkach, ale znacznie ważniejsze w praktyce: spada koszt wytwarzania kodu dla dużej klasy zadań. Chodzi o szkicowanie rozwiązań, scaffolding, refaktoryzację, spinanie warstw, generowanie testów, uzupełnianie powtarzalnych fragmentów i tłumaczenie intencji na składnię.

Kod nadal musi zostać zrozumiany. Nadal trzeba sprawdzić, czy pasuje do architektury. Nadal trzeba ocenić, czy nie wprowadza długu, regresji albo ryzyka bezpieczeństwa. Nadal potrzebny jest ktoś, kto rozumie domenę, system i konsekwencje decyzji. 
Ale jeśli koszt wygenerowania implementacji spada, to kosztownym pytaniem przestaje być wyłącznie: „kto to napisze?”. Coraz częściej brzmi ono: „co dokładnie mamy zbudować i po czym poznamy, że wynik jest właściwy?” 
A jako Scrum Masterzy znamy tę regułę aż za dobrze: jeśli optymalizujesz proces wokół ograniczenia, które już nie wiąże, optymalizujesz nie to, co trzeba. Zespół czuje się zajęty. Wykresy wyglądają zdrowo. Velocity może nawet rosnąć. A mimo to organizacja przyspiesza w stronę niewłaściwego miejsca.

Nowe wąskie gardło: specyfikacja

Pierwsze przesunięcie dzieje się w lewo, w stronę specyfikacji. Kiedy agent AI potrafi wyprodukować wiarygodnie wyglądającą implementację niemal czegokolwiek w kilka minut, kosztownym pytaniem staje się: implementację czego, dokładnie?

Nieprecyzyjny Product Backlog Item zawsze był problemem. W erze AI problem jest większy, bo nieprecyzyjny PBI może bardzo szybko wyprodukować pewny siebie, elegancki i błędny wynik.

Najrzadszą umiejętnością w zespole przestaje być samo „umie napisać kod”. Coraz większą wartość ma umiejętność zdefiniowania problemu tak precyzyjnie, żeby wygenerowane rozwiązanie było faktycznie tym właściwym. 
To oznacza, że Product Backlog Item w erze AI powinien mocniej odpowiadać na pytania:

• Jaki problem użytkownika lub biznesu rozwiązujemy?
• Jaki efekt chcemy osiągnąć?
• Czego rozwiązanie nie powinno robić
• Jakie są ograniczenia domenowe, techniczne i regulacyjne?
• Po czym poznamy, że wynik agenta AI jest poprawny?.

To nie jest biurokracja. To jest sposób obniżania ryzyka.W erze AI słaby backlog nie spowalnia zespołu. On przyspiesza produkcję błędnych rozwiązań.

Nowe wąskie gardło: weryfikacja

Drugie przesunięcie dzieje się w prawo, w stronę weryfikacji. Wynik pracy agenta AI jest probabilistyczny. Ten sam prompt, podobny kontekst i podobne zadanie mogą raz dać kod poprawny, a innym razem subtelną podatność, niezgodność z intencją albo rozwiązanie, które wygląda sensownie tylko na poziomie składni. Nie ma momentu, w którym można powiedzieć: „temu agentowi już ufamy, można przestać sprawdzać”. 

Dlatego Code Review, testy, security review, walidacja względem architektury i sprawdzenie wyniku wobec rzeczywistej intencji biznesowej przestają być fazą na końcu. Stają się pracą ciągłą, równie wartościową jak samo wytwarzanie. To nie jest argument przeciwko Scrumowi. To jest dokładnie ten rodzaj zmiany kontekstu, dla którego empiryzm został wymyślony. 
Weryfikujesz, bo obserwujesz, a nie dlatego, że ufasz.

Definition of Done w erze AI

Jeżeli zespół używa agentów AI w pętli dostarczania,

Definition of Done nie może pozostać dokumentem sprzed trzech reorganizacji. Definition of Done powinna zacząć obejmować nie tylko to, czy kod działa, ale również to, czy wynik pracy agenta został zweryfikowany w kontekście jakości, intencji biznesowej, bezpieczeństwa i utrzymywalności.

W praktyce Definition of Done dla pracy z AI może uwzględniać: 

• czy kod wygenerowany przez AI został sprawdzony przez człowieka,  
• czy testy pokrywają nie tylko happy path, ale też przypadki brzegowe,  
• czy rozwiązanie jest zgodne z intencją Product Backlog Itemu,  
• czy sprawdzono wpływ na bezpieczeństwo,  
• czy zespół rozumie wygenerowane rozwiązanie na tyle, by je utrzymywać.  

Najważniejsza zmiana nie polega na dopisaniu jednego punktu: „AI code reviewed”. Najważniejsza zmiana polega na uznaniu, że wygenerowanie kodu nie jest dowodem ukończenia pracy.

Story Points i Velocity to nigdy nie był pomiar roboczogodzin

Tu trzeba rozbroić uproszczenie, które samo ciśnie się na usta w takich dyskusjach i które słychać od zarządów częściej, niż byśmy chcieli. Story point nigdy nie był miarą samego ludzkiego wysiłku. Każdy zespół, który estymował dłużej niż kwartał, wie, że w punkcie siedzi znacznie więcej: objętość pracy, złożoność techniczna, niepewność, ryzyko oraz problemy środowiska, w którym pracujemy. Jeśli wiesz, że środowisko testowe wywala się co drugi dzień, masz zależność od zespołu, który odpowiada po tygodniu, a konkretna integracja historycznie zawsze stawiała opór, to wszystko musi znaleźć odbicie w estymacie. Właśnie dlatego story point jest jednostką względną i przypisaną do konkretnego zespołu. Nie jest przeliczeniem na godziny. To jest cała jego siła.

Co więc realnie zmienia AI?

Nie to, że estymacja przestaje działać. Zmienia się skład tego, co składa się na punkt. Komponent „przełożenie intencji na kod” gwałtownie się kurczy. Ale złożoność się nie kurczy. Niepewność się nie kurczy. Można nawet argumentować, że rośnie, bo dochodzi probabilistyczny wynik agenta AI. Wysiłek weryfikacji rośnie. Ryzyko integracji zostaje. Niestabilne środowisko testowe nadal trzeba uwzględnić, bo agent AI nie naprawi go magicznie w sytuacji, w której kilkadziesiąt osób pracuje na nim równolegle. Konsekwencja praktyczna jest prosta i nie jest rewolucyjna: zespoły będą musiały przebazować swoje punkty. Stare historie referencyjne przestają znaczyć to, co znaczyły, ponieważ zmienił się rozkład wysiłku w środku. Robiliśmy to zawsze, gdy zmieniał się stack, skład zespołu, domena albo architektura. 

Sama praktyka się broni. Z Velocity jest podobnie. Velocity zawsze było empirycznym sygnałem pojemności konkretnego zespołu, służącym do prognozowania. Nigdy nie było miarą produktywności. Nigdy nie było podstawą do porównywania zespołów. Nigdy nie powinno być KPI dla zarządu. Zespoły, które używały Velocity poprawnie, po prostu je przebazują i będą prognozować dalej. 

Zespoły, które nadużywały Velocity jako miary „ile wyprodukowaliśmy”, odkryją, że AI obnaża to nadużycie do końca. Objętość wygenerowanego kodu staje się tania i przestaje cokolwiek znaczyć. To nie Velocity tu zawiodło. Zawiodło to, jak było używane. AI tylko zapala czerwoną lampkę nad błędem, który był tam od początku. Sprint Review powinno pokazywać efekty, nie tylko funkcje. Jeżeli agenci AI przyspieszają generowanie kodu, Sprint Review nie powinno stać się dłuższą listą rzeczy, które „udało się dowieźć”. 

To byłaby dokładnie ta pułapka, w którą łatwo wpaść: więcej kodu, więcej funkcji, więcej ruchu, ale niekoniecznie więcej wartości.

Sprint Review powinno pokazywać efekty, nie tylko funkcje

Jeżeli agenci AI przyspieszają generowanie kodu, Sprint Review nie powinno stać się dłuższą listą rzeczy, które „udało się dowieźć”.

To byłaby dokładnie ta pułapka, w którą łatwo wpaść: więcej kodu, więcej funkcji, więcej ruchu, ale niekoniecznie więcej wartości.

Sprint Review w erze AI powinno mocniej odpowiadać na pytania:

• jaki efekt osiągnęliśmy,  
• czego się nauczyliśmy,  
• czy rozwiązaliśmy właściwy problem,  
• co pokazała weryfikacja,  
• gdzie agent AI przyspieszył pracę,  
• gdzie wygenerował ryzyko. 

To nadal jest Scrum. Tylko używany zgodnie z jego intencją: jako mechanizm inspekcji i adaptacji, a nie ceremonia odhaczana w kalendarzu.

Retrospektywa jako miejsce inspekcji pracy ludzi i agentów

Retrospektywa w zespołach używających AI powinna przestać ograniczać się do pytań o komunikację, flow i przeszkody organizacyjne. 

Powinna również obejmować pracę z agentami AI:

• gdzie AI realnie skróciło czas
• gdzie zwiększyło koszt weryfikacji
• jakie typy zadań są dobre dla agenta
• jakie zadania powinny zostać przy człowieku
• gdzie powstały halucynacje lub subtelne błędy
• co trzeba zmienić w Definition of Done albo refinement.

Najtrudniej będą mieli nie ci, którzy używają Scruma. Najtrudniej będą mieli ci, którzy uruchamiają jego zamrożoną konfigurację i bronią rytuału zamiast inspekcji.

Więc czy Scrum jest przestarzały?

Po tym wszystkim moja odpowiedź jako Scrum Mastera brzmi tak: 
Przestarzała bywa nasza implementacja Scruma. Zamrożona konfiguracja sprzed lat, w której wartość waliduje się funkcjami zamiast efektami, Velocity wisi na dashboardzie zarządu, a Definition of Done nie widziało rewizji od trzech reorganizacji. To się starzeje, owszem. Ale to nie jest Scrum. To jest rytuał, który pomyliliśmy z frameworkiem. 

Sam Scrum opisuje siebie jako framework lekki i celowo niekompletny. Jest ramą, w którą zespół wkłada własne techniki, narzędzia i praktyki, a następnie dostraja je do kontekstu. To nie jest słabość, którą trzeba nadrobić w erze AI. To jest dokładnie ta cecha, dzięki której Scrum może tę erę przetrwać.
Rdzeń Scruma adaptuje się bez naciągania. 

Empiryzm, transparentność, inspekcja i adaptacja przy probabilistycznych agentach AI znaczą jeszcze więcej. Mały, interdyscyplinarny zespół wciąż działa, tylko „interdyscyplinarny” obejmuje teraz również ludzi, którzy potrafią precyzyjnie specyfikować, oraz ludzi, którzy rygorystycznie weryfikują wynik pracy AI. 

Definition of Done może wchłonąć weryfikację wyniku agenta. Sprint Review może pokazywać efekty zamiast funkcji. Retrospektywa może stać się miejscem, w którym zespół sprawdza, co w pracy z AI zawiodło, i odpowiednio adaptuje proces. Sprint może skrócić się w stronę rytmu rzeczywistej pętli zwrotnej. Nic z tego nie łamie Scruma. Wszystko to jest Scrumem używanym tak, jak był pomyślany.

Co zespoły powinny przestroić jako pierwsze?

Jeśli dziś pracujesz w Scrumie i wprowadzasz agentów AI do pętli delivery, nie zaczynałbym od zmiany nazw spotkań ani rezygnacji ze Sprintów. 

Zacząłbym od pięciu rzeczy. 

• Product Backlog Item – czy opisuje problem, efekt i ograniczenia wystarczająco precyzyjnie, żeby agent AI nie wygenerował poprawnie wyglądającej pomyłki? 
  Definition of Done – czy obejmuje weryfikację kodu generowanego przez AI, bezpieczeństwo, testy i zgodność z intencją biznesową? 
• Code Review – czy zespół sprawdza nie tylko styl i poprawność, ale też sens rozwiązania, ukryte założenia i ryzyka? 
• Sprint Review – czy pokazujecie efekty i decyzje produktowe, czy tylko listę funkcji? 
• Retrospektywa – czy analizujecie, jak AI zmieniło pracę zespołu, gdzie pomogło, a gdzie zwiększyło koszt kontroli? 

To czyni Scruma zwinnym. Nie sama obecność Sprintów, Planningów i Daily. 

Scrum dał nam pozwolenie, żeby go adaptować, już pierwszego dnia. Era AI to po prostu moment, w którym wreszcie warto z tego pozwolenia skorzystać.