Jeżeli Twój Project Manager, czy Lider Technologiczny mówi Ci, że zaimplementował Scrum w zespole bo mają stand-upy -> niestety masz skramisz, a to jeszcze gorzej. Ale nie martw się, naucz się to rozpoznawać a następnie wprowadź Scruma!
- Stanowisko Lidera Technologicznego/Zespołu
Niestety ale Lider Technologiczny nigdy nie wie wszsytkiego, nawet ten najmądrzejszy. Zespół dzięki samoorganizacji zawsze znajdzie najlepsze rozwiązanie. Naprawdę, tak to działa. Natomiast mianowany Lider Zespołu to oznaka braku zaufania do pracowników. Tutaj już potrzeba procesu budowania zespołu. - Stanowisko Project Managera
Wszyscy kochają PM, osoba która pracuje za dużo, wymaga jeszcze więcej a na końcu obrywa za spóźniony termin. Ot chociażby z powodu rotacji w zespole. Najczestszym problemem jest brak doświadczenia i poprawnej komunikacji. W Scrum nie ma tego stanowiska, i nawet nie można porównać tej roli do Product Owner. - Brak Scrum Mastera
Jeżeli posiadasz dwa zespoły Scrum a nie zatrudniasz Scrum Mastera – niestety – na 100% masz skramisz. Z moich obserwacji wynika, że SM jest w stanie „obsłużyć” 4 zespoły, natomiast w sytuacji gdy w firmie są tylko dwa zespoły, dochodzi do tego praca jako coach/trener dla PO i Menedżerów. - Oddzielny dział testów
Jeżeli zespół nie jest w stanie stworzyć Przyrostu w odpowiedniej jakości i jest zależny od osób spoza zespołu – to nie jest Scrum. Zależnosci powodują dłuższy czas realizacji. Team Development powinien być na tyle multifunkcjonalny aby w 100% wykonać zobowiązania. - Programiści pracują nad wieloma produktami
Każdy zna tę sytuację, wiele projektów, klientów. Ciągłe poprawki i zmiany. Rozwiązaniem tutaj jest zespół utrzymaniowy pracujący w Kanban. W Scrum, członkowie Development Team w 100% należą do zespołu i nie mogą „dzielić” czasu pomiędzy projektu. Podział może powodować mniejsze skupienie na głównym celu, co może skutkować brakiem porozumienia, problemach w komunikacji itp. - Raporty tygodniowe/miesięczne programistów
Programiści nie mogą raportować swojej wydajności i postępów prac. Czasem mało efektowne zadania zajmują wiele czasu. W Scrumie nie ma miejsca dla raportów. Po zakończonych kilku Sprintach widać czy są problemy w zespole czy też nie -> po wynikach i feedbacku użytkownikach. - Plany kwartalne dla programistów
Tak jak wyżej, jednak jest wyjątek – kompetencje miękkie, natomiast jeżeli chodzi o technologiczne – również powodują mniejsze skupienie na celu. Tylko w skramiszu programiści są rozliczani w ten sposób. - Ingerowanie w konflikty
Znajomości, układy, staż pracy – to nigdy nie może być argument w dyskusji, kłótni. Tylko pełna otwartośc i zaufanie zapewni dobre konflikty. Jeżeli podczas konfliktów ktoś używa nie merytorycznych argumentów, i tak są załatwiane sprawy w zespole – to skramisz. - Słabe ogniwo w zespole
Często doświadczeni programiści zrzucają winę za niepowodzenie projektu na osoby z mniejszą wiedzą. Pracowałem w wielu zespołach Scrum i wiem, że w poprawnej implementacji frameworka – taki argument nigdy nie jest podnoszony. Jeżeli o tym słyszysz – masz skramisz. - Duża rotacja
Każdy kocha Scruma. Jest to miłość trudna na początku ale po kilku miesiącach ludzie nie są sobie w stanie wyobrazić jak można pracować inaczej. I nie potrzebujesz wtedy biletów do kina, czy kuponów na myjnię – pracownicy sami będą chcieli pracować. Jeżeli masz rotacje w dziale programistów wyższą niż 10% w skali rocznej – to nie może być scrum.
Podsumowanie
Ten trochę żartobliwy artykuł powstał w skutek wielu informacji o tym jak Scrum jest implementowany. Niestety ten framework nie ma sensu podczas wdrażania częściowego, rezultat będzie negatywny. Autorzy Scruma podkreślają, że tylko w 100% zastosowanie się do reguł gry, pozwoli osiągnąć korzyści ze Scruma: wyższą jakość, zadowolenie klientów, budżet w ryzach i wiele pozytywnych czynników.