Od ponad roku mam okazję popracować w organizacji, w której dumnie królują zwinne metodyki zarządzania projektami (a konkretnie Scrum).
Dla niewtajemniczonych, Scrum jest jedna ze “zwinnych” (z ang. agile) metodyk prowadzenia projektów, gdzie:
- zespół projektowy dostarcza kolejne, coraz bardziej dopracowane wyniki projektu,
- przyszli użytkownicy są włączeni w proces wytwórczy,
- zespół projektowy sam się organizuje
Tyle teorii. W trakcie tego czasu ja, jako osoba odpowiedzialna za utrzymanie usług IT, miałem wiele okazji, aby skonfrontować obiegowe opinie na temat “zwinnego” podejścia do zarządzania usługami IT.
Oto 5 wniosków, do których doszedłem po tym czasie:
1) Scrum nie nadaje się do działu utrzymaniowego
Niby to oczywista oczywistość, ale były próby 🙂 Nie da się i już. Choćby ze względu na to, że nie ma możliwości, aby oszacować czas rozwiązania jakiegoś problemu na podstawie innych problemów, które zespół napotkał w przeszłości.
2) Scrum wdrożony książkowo nie podnosi wydajności
Scrum wymaga stałego weryfikowania rezultatów i usprawniania procesów i metod pracy. Jeśli ktoś oczekuje, że będzie w stanie od “pierwszego” używać tej metodyki, to jest w dużym błędzie. Prawdopodobnie skutkiem takiego podejścia będzie jedynie frustracja zespołu i niechęć do tego sposobu pracy.
3) Scrum użyty do projektu dla nowego klienta, który nie stosował tej metodyki = katastrofa
Klient, który pierwszy raz używa metodyk zwinnych (tak klient!) powinien być przeszkolony pod kątem tego co i kiedy i za ile może oczekiwać od zespołu projektowego. Bez tego projekt z dużym prawdopodobieństwem może zakończyć się jego zerwaniem w połowie dostarczania. Szczególnie dotyczy to klientów, którzy są przyzwyczajeni do kaskadowego dostarczania projektów.
4) Scrum może być świetną wymówką, aby się czymś nie zająć
Scrum jak każda inna metodyka, może być świetną wymówką, aby odrzucić pilną potrzebę (czyt. nie ugasić pożaru) i wykonać ją później. Może się to zdarzyć mimo pełnego zaangażowania zespołu i dobrej woli jego członków. Ważne jest, aby również do samej metodyki podchodzić zwinnie i pamiętać, że jest ona wdrożona po to, aby wspierać biznes, a nie istnieć sama dla siebie.
5) Zespół scrumowy potrzebuje co najmniej kilku miesięcy wspólnej pracy, aby zacząć pracować z pełną wydajnością
Samo stworzenie zespołu scrumowego nie sprawi, że projekty będą dostarczane szybciej i produkty będą lepiej dopasowane do potrzeb klientów. Zespół potrzebuje czasu, aby się dotrzeć i poznać produkt, który będą rozwijali. Szacuje się, że nowy zespół potrzebuje około 6 miesięcy wspólnej pracy na osiągnięcie pełnej wydajności. Warto o tym pamiętać planując zmiany organizacyjne.
