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.
- Menedżer ma tło programistyczne, dużą wiedzę i wie jak dobrze robić soft
- Zespół max 30/40 osób – jest w stanie dotrzeć do każdej osoby i nakierować
- Kieruje ręcznie jeżeli trzeba, utrzymuje proces na właściwym torze
- 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”.
- Krótkie projekty, np. Marketingowe.
- Zachodzące na siebie zadania od różnych klientów
- Dzielenie czasu pracowników – zmiana kontekstów pracy
- 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.