Wstęp: Agile, czyli zwinność.

Słowo, które zdominowało branżę IT. Co tam IT, Elon Musk wyniósł je ponad IT, wprost do biznesu. Obietnica elastyczności, szybkiego reagowania na zmiany i dostarczania wartości. A jednak, po latach w branży, obserwuję czasem coś zupełnie odwrotnego.

Zwinny i elastyczny SCRUM, działający w firmach IT, w tworzeniu i rozwijaniu produktów, staje się biurokratyczną klatką w innych sytuacjach. Szczególnie w wewnętrznych zespołach IT, firm zupełnie nie technologicznych, które nie są software house’ami.

Część 1: Pomyłka Kontekstu: Dlaczego Wewnętrzny Zespół IT to nie Software House

Skąd w ogóle bierze się ten problem? Z fundamentalnej pomyłki kontekstu.

Metodyki zwinne, a w szczególności Scrum, zostały spopularyzowane i udoskonalone w bardzo specyficznym środowisku: w firmach produktowych i software house’ach. To model, w którym jeden zespół pracuje nad rozwojem JEDNEGO, klarownie zdefiniowanego produktu, przeznaczonego zazwyczaj na rynek zewnętrzny.

Skład takiego zespołu to zwykle Product Owner, Scrum Master, Developerzy, zwykle około 6-10 osób.

Tworzenie produktu podzielone jest na części większe, Epiki, i mniejsze, Sprinty.

W tym idealnym świecie „Product Owner” to osoba której zadaniem jest ochrona zespołu przed chaosem, zbieranie wymagań i układanie spójnego backlogu. Praca jest mierzalna, w dużej mierze przewidywalna, a celem jest iteracyjne ulepszanie tego jednego produktu. W takich warunkach rytuały Scruma – sprinty, planowanie, retro – mają sens.

A teraz wyobraźcie sobie sytuację, gdy cały zespół to jedna osoba, albo nawet trzy. Jeśli poza dostarczaniem jednego produktu, zespół ma dostarczać kilka produktów, dodatkowo świadczyć maintenance, usługi poza DEV dla samego biznesu.

Wtedy sytuacja staje się zupełnie inna.

My nie jesteśmy software housem. Jesteśmy wewnętrznym centrum rozwiązań, partnerem dla całego biznesu danej firmy. Nasz kontekst wygląda tak:

• Nie mamy jednego „Product Ownera”. Naszym klientem jest cała firma. W poniedziałek priorytetem jest Zarząd, który dyktuje potrzebę „na już” – „prezes driven development”. We wtorek dzwoni HR z krytyczną potrzebą customizacji systemu albo naprawa jakiegoś błędu, Ale w tym samym czasie przełożony dzwoni i dorzuca jakieś tam cegiełki, a dział X swoje. W środę Finanse potrzebują nowego raportu, a w czwartek Logistyka zgłasza problem z wydajnością bazy danych. Każdy z nich jest równie ważnym „interesariuszem”. Ograniczony zespół, poza tworzeniem rozwiązań, musi także udzielać bieżącego wsparcia.
• Nasz „backlog” to nie tylko nowe funkcje. To ciągła walka na wielu frontach. Równolegle do budowy nowego modułu CRM, musimy gasić pożary, obsługiwać bieżące wsparcie użytkowników, utrzymywać systemy przy życiu i wdrażać krytyczne poprawki. Próba „zamrożenia” priorytetów w dwutygodniowym sprincie jest w takim środowisku z góry skazana na porażkę.

Przeniesienie rytuałów Scruma jeden do jednego w ten chaos jest jak próba wykonania skomplikowanej, formalnej kata w środku ulicznej bójki. Wygląda imponująco na papierze, ale jest całkowicie niepraktyczne.

Część 2: Jak „Zwinne” Rytuały Zabijają Zwinność (Punkty Bólu)

Żeby była jasność, to nie jest atak na ideę Agile. To atak na jej bezmyślne, rytualne stosowanie tam, gdzie logika podpowiada inne rozwiązania. Wewnętrzny zespół IT, wciśnięty w sztywny gorset Scruma, cierpi na trzy podstawowe bolączki.

Punkt 1: Teatr 15-minutowego „Daily”

Według podręcznika, „Daily Scrum” to 15-minutowe spotkanie synchronizacyjne dla Deweloperów. W teorii brzmi świetnie. W praktyce, w 3-osobowym zespole, który siedzi biurko w biurko (czy temas w teams), jest to czysty teatr.

Mój zespół komunikuje się non-stop. Na bieżąco rozwiązujemy problemy, przerzucamy się zadaniami i ustalamy, kto co robi. Wymuszanie formalnego spotkania, by każdy przez 5 minut opowiadał, „co robił wczoraj, co zrobi dzisiaj i jakie ma problemy”, jest stratą czasu. To rytuał pozbawiony treści. Zamiast budować dyscyplinę, buduje jedynie frustrację.

Punkt 2: Tyrania Dwutygodniowego Sprintu

To jest największy wróg wewnętrznego IT. Biznes nie działa w sprintach. Biznes działa w trybie „potrzebuję”.

Gdy Prezes przychodzi i mówi, że potrzebuje krytycznego raportu „na wczoraj”, bo od tego zależy ważna decyzja, odpowiedź „Dobrze, porozmawiajmy o tym na planowaniu następnego sprintu za 10 dni” jest nieakceptowalna. To jest recepta na katastrofę i postawienie IT w roli „hamulcowego”, a nie partnera.

Sztywny sprint zmusza nas do absurdalnego wyboru: albo notorycznie łamiemy „święte zasady” Scruma (przerywając sprinty lub dorzucając zadania „na boku”), albo zawodzimy biznes. Jeśli metodologia zmusza cię do wyboru między byciem „poprawnym metodycznie” a byciem „użytecznym dla firmy”, to ta metodologia jest w tym kontekście bezwartościowa.

Punkt 3: Cała Masa Rzeczy, czyli Narzut Biurokracji

Do tego dochodzi cały ten bagaż ceremonialny: wielogodzinne planowanie sprintu, estymacje w story pointach, spotkania „retro”. W software house, który buduje jeden produkt, ma to sens. Ale w zespole, który musi jednocześnie rozwijać kilka wewnętrznych produktów, jakieś zewnętrzne, pilnie łatać znalezione bugi i jeszcze pomagać użytkownikowi, któremu „drukarka nie działa” – to jest czysty narzut.

Próba estymowania w „story pointach” zadania „Prezes dzwonił, coś się wysypało” jest absurdem. Zamiast skupić się na realnej pracy – rozwiązywaniu problemów i dostarczaniu wartości, marnujemy energię na biurokrację, która nic nie wnosi. Stajemy się niewolnikami procesu, zamiast być mistrzami narzędzia.

Część 3: Pragmatyzm ponad Dogmatem (Model Wewnętrznego Rzemieślnika)

Co zamiast?

Ja osobiście ciągle szukam złotego środka ale po 20 latach w tej branży wiem, że nie ma jednego „złotego środka” w postaci magicznego narzędzia. Jest za to „złota zasada”: pragmatyzm.

To, co nazywam „Modelem Wewnętrznego Rzemieślnika”, opiera się na kilku żelaznych, ale prostych zasadach:

Prostota Narzędzia (zamiast Kombajnów): Zespół rzemieślniczy nie potrzebuje przeładowanego kombajnu typu Jira, którego obsługa zajmuje tyle czasu, co samo zadanie. Narzędzie ma być proste, przejrzyste i pomagać w pracy, a nie generować dodatkową biurokrację.

Ciągła Priorytetyzacja (zamiast Sprintów): Biznes dyktuje priorytety. Naszą rolą jest ich bezbłędna egzekucja. Tablica Kanban, zadania w MS Teams czy Trello – to tylko narzędzia, które mają to ułatwić, a nie skomplikować. Lista „Do zrobienia” jest żywym organizmem, codziennie weryfikowanym z interesariuszami. (Obecnie jestem na etapie zakochania się w Linear)

Dyscyplina Komunikacji (zamiast Rytuałów): Zamiast formalnych, 15-minutowych spotkań – ciągła, bezpośrednia komunikacja. Zespół musi wiedzieć, co robią pozostali. Biznes musi wiedzieć, jaki jest status kluczowych zadań. To wymaga prawdziwej dyscypliny i odpowiedzialności, a nie 15-minutowego rytuału.

Konkluzja:

Zwinne, współczesne firmy, muszą dynamicznie zmieniać swoją strukturę, wewnętrzne procesy i technologie i gdy one same są agile, to IT musi być jeszcze bardziej zwinne niż one same. Musi być hiper-responsywny. Tak to widzę.

Świat IT nie kończy się na firmach IT. Dziś jest on systemem nerwowym każdego przedsiębiorstwa. Wewnętrzny dział IT nie może być już postrzegany jako „informatyk od drukarek”. Musi być strategicznym partnerem w transformacji cyfrowej.

I tu dochodzimy do sedna. Dziś ta transformacja dotyczy przede wszystkim automatyzacji i wdrażania systemów opartych o AI.

Aby skutecznie wspierać biznes w tej rewolucji, aby szybko identyfikować i wdrażać rozwiązania AI poprawiające wewnętrzne procesy, zespół IT musi być wolny od biurokratycznego narzutu. Musi być precyzyjny, pragmatyczny i skupiony na celu.

Inaczej utknie w kolejnym „retro”, podczas gdy konkurencja będzie wdrażać AI