Nie wszędzie da się wdrożyć Scrum. A tam gdzie nie jest to możliwe – czasem pojawiają szydercze komentarze w kierunku Scrum’a. Tu przedstawiam trzy sytuacje kiedy rzeczywście się nie da.

Fighter Manager  

Kiedy menedżer jest “wojownikiem” i wie, jak powinno się tworzyć produkt (lub oprogramowanie) każde usztywnienie pracy – będzie spowalniało efekty prac.  

1. Menedżer ma tło programistyczne, dużą wiedzę i wie jak dobrze robić soft 
2. Zespół max 30/40 osób – jest w stanie dotrzeć do każdej osoby i nakierować 
3. Kieruje ręcznie jeżeli trzeba, utrzymuje proces na właściwym torze 
4. Osiąga super efekty 

Taka sytuacja jest dobra dla firmy, być może też dla pracowników – ale ma jedną wadę. Jest to ciężko skalowalne rozwiązanie – jeżeli wiedza i władza są hierarchiczna, znika pełna odpowiedzialność zespołu. Przy dużej skali – ciężko jest znaleźć tylu “fighterów”. Duża odpowiedzialność jest skupiona wokół jednostki. Samoorganizacja nie zostanie osiągnięta. 

Inne myślenie czasem jest zabronione albo uciszane, ciężko o różnorodność. Wtedy 1+1 = 2. W Scrumie 1+1=3. 

Ciągły pożar 

Firma typy “ciągły pożar”. Cały czas coś się pali, gdzieś się śpieszymy. Zalepiamy i kolorujemy. Bardzo często jest to powiązane z “Fighter Manager”. 

1. Krótkie projekty, np. Marketingowe. 
2. Zachodzące na siebie zadania od różnych klientów 
3. Dzielenie czasu pracowników – zmiana kontekstów pracy 
4. Deadline połączony z listą wymagań – typowy waterfall 

Brałem udział w wielu takich przedsięwzięciach, często jako “Fighter Manager” – z uwagi na pęd tworzenia/zarabiania, nie ma czasu zastanowić się jak można to robić inaczej. Tak działa wiele typów firm, typu “wszystko dla wszystkich” – także wchodząc w niektóre branże – może być ciężko ze Scrum’em.  

Efekt? Brak kultury organizacji, rotacje, niechęć do pracy. 

Raport manager 

Sytuacja, kiedy kultura organizacyjna polega na tworzeniu dokumentów – jest niezwykle ciężko wprowadzić elastyczny model pracy. W metodach Agile efekt mierzy się zadowoleniem klienta. Projekt waterfall zawsze takim pozostanie – jeżeli firma otrzymuje bardzo precyzyjne zadania do realizacji a efekt jest rozliczany wykonaniem zadania a nie zadowoleniem klienta – nie uzyska się korzyści ze Scrum.  

W przypadku pełnej stabilności zastosowanie zasad stworzonych do pracy w niepewności i zmiennym środowisku – nie ma sensu. Lepiej dopracować Waterfall. 

Podsumowanie 

Scrum opisuje zasady pomagające tworzyć produkty (projekty, oprogramowanie) w trybie iteracyjnym, nastawiając się na zadowolenie klienta. Nie oznacza to, że wszędzie Scrum będzie działać.  Powyższe 3 czynniki to przykłady jakie można mnożyć, natomiast według mnie są one najpopularniejsze. 

btw: powyższe przypadki pochodzą z mojego doświadczenia i nie są rozważaniami teoretycznymi. Z takimi opiniami również spotykam się na moich warsztatach.