1. Wprowadzenie i ogólna ocena Scruma
- Scrum jest popularną, ale nie zawsze skuteczną metodyką w IT.
- Z raportu Annual State of Agile 2024 wynika, że tylko 44% użytkowników jest zadowolonych z jej działania.
- Najczęstszy problem to brak kompetencji zespołów w prawidłowym stosowaniu Agile/Scruma (84% respondentów).
- Scrum nie jest zły sam w sobie, ale potrzebuje dostosowania do współczesnych realiów projektowych i zespołowych.

2. Kontekst historyczny i zmiany środowiska pracy
- Scrum ma około 30 lat, co jest bardzo długo w kontekście dynamicznego rozwoju IT.
- Współczesne zespoły są interdyscyplinarne i często rozproszone, co komplikuje współpracę.
- Projekty informatyczne stają się coraz bardziej złożone, a ich sukces zależy od wielu czynników, m.in. niezawodności, użyteczności i zgodności z przepisami.
- Tylko 31% projektów IT kończy się sukcesem według raportu Chaos Report.

3. Główne problemy Scruma i propozycje rozwiązań

a) Scrum jest zbyt ogólny:
- Scrum nie dostarcza szczegółowych instrukcji działania, co powoduje improwizację i utrzymanie nieefektywnych praktyk.
- Propozycja: stosować podstawowe filary Scruma (przejrzystość, inspekcję, adaptację), nie bać się dostosowywać procesu – „rób to, co działa, a jak nie działa, zmień to”.

b) Sprinty o stałej długości są ograniczające:
- Planowanie sprintów często jest nierealistyczne; prace są albo niedoszacowane, albo kończą się przed czasem, powodując marnotrawstwo zasobów.
- Propozycja: wyeliminować sprinty na rzecz regularnych wydań (np. co dwa tygodnie deployment) lub używać elastycznych kamieni milowych opartych na konkretnych wartościach.

c) Cele sprintów są często fikcją:
- Często nie udaje się zrealizować planowanych celów sprintu, co obniża skuteczność zespołu.
- Propozycja: zamiast celów sprintu lepiej skupić się na jasnym celu produktu i priorytetach, dostosowując prace do nich elastycznie.

d) Story pointy i estymacje są nieskuteczne:
- Estymacje zespołowe na podstawie story pointów są z reguły niedokładne i mało użyteczne.
- Propozycja: jeżeli nie ma potrzeby, nie rób estymacji; jeśli trzeba, niech szacuje osoba realizująca zadanie, najlepiej indywidualnie.
- Wprowadzić estymację kroczącą – codzienną aktualizację szacowanego czasu realizacji na podstawie postępów, co pozwala na lepsze zarządzanie projektem i kontrolę.

e) Rola Scrum Masterów:
- Scrum Masterzy często nie pełnią roli liderów służebnych, są odczuwani jako osoby kontrolujące biurokrację.
- Propozycja: zadbać, żeby Scrum Master był prawdziwym liderem zespołu, pomagającym, obecnym i aktywnie wspierającym rozwój zespołu, a nie tylko etatowym organizatorem spotkań.

f) Nadużywanie narzędzi i biurokracja:
- Nadmierne poleganie na narzędziach (jak Jira, Miro) oraz formalnościach skutkuje utratą bezpośredniej komunikacji, która jest kluczowa.
- Propozycja: ograniczyć liczbę używanych narzędzi, stawiać na wspieranie komunikacji i interakcji, szczególnie w zespołach rozproszonych.

g) Zbyt dużo spotkań:
- Spotkania często odbywają się bez jasno określonego celu czy agendy, powodując stratę czasu.
- Propozycja: organizować tylko niezbędne spotkania z konkretnym celem, agendą i decyzjami do podjęcia.

4. Podsumowanie
- Scrum wymaga dostosowania i świadomego stosowania jego głównych zasad.
- Nie należy ślepo realizować metodyki, lecz być zwinny („Be Agile, not do Agile”).
- Każdy zespół i organizacja jest inna – trzeba ciągle przyglądać się procesom i je ulepszać dla dobra zespołu, organizacji i klienta.

Zadania do wdrożenia:
- Systematyczna inspekcja i adaptacja procesu pracy.
- Rozważenie usunięcia sprintów na rzecz ciągłych wydań lub elastycznych kamieni milowych.
- Eliminacja lub minimalizacja celów sprintów na rzecz jasnych celów produktu.
- Stosowanie indywidualnej, kodziennej estymacji kroczącej zadań.
- Wzmocnienie roli Scrum Mastera jako lidera służebnego.
- Redukcja narzędzi wspierających pracę, stawianie na bezpośrednią komunikację.
- Redukcja liczby spotkań do tych absolutnie niezbędnych i dobrze przygotowanych