Zagrożenia Scrum – wyższy koszt projektu

O wdrażaniu nowych zasad do organizacji decyduje złota zasada. Jest ona krótka, prosta i jasna – każdy ją rozumie. Wszystkie decyzje jakie podejmują osoby zarządzające muszą dążyć do zwiększania wartości firmy poprzez mierzalne efekty.

Złota zasada

Złota zasada. Kto ma złoto to rządzi.

To bardzo proste – chcesz coś wdrożyć, polepszyć – pokaż korzyści biznesowe, ale to nie wszystko – zawsze istnieje ryzyko. W przypadku Scrum’a to proste – złe wdrożenie zasad – spowoduje wyższy koszt realizacji projektu. Poniżej opisuje częste niepożądane efekty nieumiejętnego wprowadzenia Scrum’a.

Projekt pilotażowy

Zanim zaczniesz wprowadzać Scrum na poziomie organizacji sprawdź czy Twoja firma jest w stanie tak pracować. Stosowanie zasad może wpływać na wiele działów powiązanych z programistami, również na kadrę zarządzającą. Dlatego zaleca się wdrożenie Scrum’a od projektu pilotażowego, poprzedzonego edukacją w zakresie Agile.  

Na początku należy wybrać projekt oraz zespół, który zechce pracować w nowych zasadach. Bardzo ważne jest to, aby Scrum Master posiadał doświadczenie i wiedzę – nie może to być osoba mianowana – najlepiej skorzystać z konsultanta, lub wyszkolić taką osobę. Pamiętaj, że szkolenie to za mało, certyfikat też za mało – jest to stanowisko zarządzające i są wymagane umiejętności zarządzania osobami/projektami/problemami. 

W sytuacji, gdy projekt pilotażowy jest prowadzony z elementami Scrum’a – oznacza to że jest to projekt tworzony iteracyjnie. Ale nie możemy nazywać tego Scrum’em. Zgodnie z wytycznymi i doświadczeniem, aby mówić o pełnej implementacji należy w pełni zastosować się do zasad i reguł. 

Długie spotkania

Początkowo każde spotkanie będzie trwać za długo – należy pracować nad tym, aby optymalizować ten czas poprzez sprawną organizację. Scrum Master powinien mieć gotowe rozwiązania jak przyspieszyć planowanie, tłumaczyć zespołowi, że nie może omijać spotkań „Przeglądu Sprintu”, a daily musi być codziennie. 

Zachowanie odpowiednich ram czasowych jest niezbędne, aby firma nie ponosiła zbędnych kosztów, np.: Retrospektywa jest to spotkanie po którym zespół poprawią minimum jedną kwestię odnoszącą się do przepływu pracy w następnym Sprincie. Rzadko zdarza się aby to było więcej kwestii. Rolą Scrum Mastera jest pomoc zespołowi, aby on jak najszybciej zdiagnozował najpilniejszy problem. 

Przedłużając się spotkania powodują zwiększenie kosztów tworzenia oprogramowania oraz marnotrawstwo czasu. Dlatego powinny być prowadzone skutecznie a dyskusja konstruktywna. Spotkanie owszem może zająć wiele godzin – ale efekty powinny być proporcjonalne do poświęconego czasu. 

Brak wsparcia osób zarządzających

Tworzenie projektu pilotażowego musi być jasno zakomunikowane i wspierane. Im więcej się o tym mówi i im częściej się wspiera zespół tym lepiej – nie można ignorować oddolnych inicjatyw. W bardzo wielu firmach Scrum działa w ukryciu, przez co nie widać pozytywnych efektów.

Kadra zarządzająca powinna zaufać Scrum Masterowi w jego pracy i pozwolić na wprowadzanie zasad frameworka. Efekty na 100% będą pozytywne.

Jak kadra zarządzająca może wpierać projekt pilotażowy

Źle dobrany zespół

Aby projekt pilotażowy odniósł sukces Zespół Deweloperski powinien być odpowiednio dobrany to znaczy że:

Charakterystyka Zespołów Deweloperskich jest następująca:
• Są samoorganizujące się. Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty gotowej do potencjalnego wydania funkcjonalności.
• Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie
umiejętności niezbędne do wytworzenia Przyrostu produktu.
• Scrum nie wyróżnia nazw ról członków Zespołu Deweloperskiego, bez względu na charakter wykonywanej przez nich pracy.
• Scrum nie wyróżnia podzespołów w Zespole Deweloperskim, niezależnie od rodzaju wykonywanych zadań — na przykład testowania, tworzenia architektury, operacji czy analizy biznesowej.
• Mimo, iż pojedynczy członkowie Zespołu Deweloperskiego mogą posiadać wyspecjalizowane umiejętności i mogą skupiać się na konkretnych dzie

Scrum Guide, 2017

Wszystkie powyższe warunki muszą być spełnione, w przypadku zależności zespołu od innych działów nie pracujących w Scrumie, albo nawet Agile -> efektywność całego zespołu może być równa pozostałym z uwagi na oczekiwanie na odpowiedź, testy, brakujące grafiki.

Często jest tak, że grafik, ux designer, PO, Scrum Master jest również testerem w zespole Developerskim. Role można łączyć, lecz doświadczenie wskazuje, że osoby zaangażowanie w budowanie „Przyrostu”, w tym przypadku programiści nie powinni pełnić ról PO, i SM – z uwagi na brak możliwości rzetelnego spojrzenia na własną pracę.

Product Owner

PO to nie jest PM, spójrz na grafikę poniżej, przedstawiam tam różnice.

PO jest to nowa specjalna rola w zakresie wdrożenia Scrum’a. Taką osobą może być PM, nie ma ku temu przeciwności, ale do swojego zakresu obowiązków musi dołożyć dodatkowe elementy pracy z zespołem. W przypadku braku Właściciela Produktu, Zespół Deweloperski może nie wiedzieć co powinien robić, a to może wpłynąć na źle realizowaną pracę.

Podsumowanie

Wdrażanie Scrum’a boli. Nowe zasady mogą wprowadzić dodatkowe koszty, niechęć i problemy. Dlatego tak ważne jest, aby robić to zgodnie ze sztuką. Odpowiednio doświadczona osoba na stanowisku Scrum Master to podstawa -> taka osoba nie rozpocznie projektu Scrum bez upewnienia się, że jest zapewnione wsparcie osób zarządzających, jest odpowiedni zespół i przeszkolony PO. W sytuacji, gdy zespół programistów zaczyna sam wprowadzać Scrum – efekty mogą być opłakane i może się to skończyć tylko dodatkowym kosztem organizacji. 

Otagowano