Przeczytaj wersję webową.

Problemy ze Scrumem

// Uwaga, będzie ostro

Cześć !

Duża część polskiej branża IT żyje aktualnie zwolniem wszystkich Scrum Masterów z InPostu - link do posta na LinkedIn. Co ciekawe, nie ma o tym, żadnego artykułu w internecie. Jednak po Social Media, grupach na Facebooku, czy dedykowanych forach rozmowy nie ustają.

Powiem szczerze, że nie jestem zaskoczony reakcją InPostu (a w zasadzie CTO InPostu, ponieważ podobno to od niej wyszła ta inicjatywa). Osobiście uważam Scrum za rozwiązanie, które posiada wiele wad:

• Scrum jest promowany jako jedyna właściwa metoda na pracę zespołu programistycznego/produktowego. Brak dyskusji na temat innych modeli np. Shape Up, metody Linear, czy pracy opartej na planowaniu.
• Scrum (celowo?) jest frameworkiem niepełnym - brak informacji np. jak przeprowadzać analizę do PBI, jak się komunikować z biznesem, jak priorytetyzować. Ta dziura otwiera drzwi na wszelkiego rodzaju konsultantów, jak zwrócił uwagę Wojtek Ptak w odcinku CTO Morning Coffee.
• Scrum nie promuje nacisku na praktyki techniczne, które w dłuższej perspektywie dają przynoszą systemowi zwinność - CI/CD, testy, refactoring, architektura, automatyzacja. Nie jest wymagane od osób, które działają dookoła Scruma, by znały te techniki i pomagały je aplikować zespołowi.
• Scrum nie promuje wartościowej wiedzy dotyczącej faktycznej optymalizacji pracy - teorii ograniczeń, wizualizacji strumienia wartości, prawa Little’a, kosztów opóźnień czy mierzenia pracy w toku. Optymalizacja pracy odbywa się tutaj przez zarządzanie taskami w Jirze.
• W Scrumie jest duża chęć by unikać silnego accountability. Przez co odpowiedzialność się rozmywa i nikt nie poczuwa się właścicielstwa za to co robi. Jako osobie, która działa zgodnie z praktykami Ekstremalnego Przywództwa trudno jest zrozumieć takie podejście.
• Scrum promuje tworzenie Feature Factory, gdzie wymagania zawsze spływają z góry, a zespół przerzuca zadania z lewej na prawą (stronę tablicy). Marty Cagan (autor książki Empowered o zespołach produktowych) wskazuje, że developerzy są najlepszym źródłem pomysłów co do danego rozwiązania. Nawet jeśli chcielibyśmy ich mocniej wciągnać w pracę biznesową to w Scrumie tego rodzaju idea wydaje się w ogóle nie przebijać.

Najlepsze wdrożenia Scrum w organizacjach widziałem, gdzie nie było osobnych ról Scrum Mastera. Tech Lead / Team Lead pracował jako Scrum Master optymalizując pracę zespołu. Lub ogólnie wyrzucał Scrum i zespół pracował kompletnie inaczej. Jeśli były brane pod uwagę np. aspekty związane z Lean Software Development, to zespół dobierał metodę pracy pod problem, a nie odwrotnie. I dowoził wartościowe oprogramowanie / produkt.

Na Facebooku jeden z komentujących podrzucił nagranie prezentacji “The Land that Scrum Forgot” Uncle Boba:
https://www.youtube.com/watch?v=hG4LH6P8Syk
Świetnie opisuje historię w jaki sposób ze Scruma zrobiono maszynkę pieniędzy. Mniej więcej takie jest również moje postrzeganie tego tematu.

Za niedługo będę opisywać dokładniej odpowiedzialności Tech Leada i Engineering Managera. W mojej ocenie są to role, których praca zawiera w sobie zakres pracy Scrum Mastera. Wobec czego nie potrzebujemy osobnej roli w zespole.

A Ty, co sądzisz o Scrumie? Raczej bronisz, czy raczej atakujesz? 🤔

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)