12 przypadków, kiedy Scrum to zły wybór

Abraham Maslow powiedział kiedyś: „Jeżeli masz tylko młotek to wszystko wygląda jak gwóźdź”. Podobnie sprawa ma  się ze Scrumem. Jeżeli ktoś zna tylko  Scruma może się okazać, że chce go za implementować absolutnie w  każdym  przypadku. Prawda jest jednak taka, że w niektórych sytuacjach Scrum pasuje  jak wół do karety.

---

1. Brak produktu 

Scrum to narzędzie do wytwarzania i rozwoju produktu. Jeżeli nie ma produktu, to Scrum  nie ma żadnego sensu. Najważniejsza część  Scruma to “Potentially Releasable Product  Increment that is usefull I  thourly tested…” („Potencjalnie Wydawalny Inkrement Pro duktu, który jest używalny i gruntownie prze testowany…”) i to, co Sprint! Jak tworzyć inkrement produktu bez produktu? Jeżeli nie  masz, czego poddawać inspekcji i adaptacji  na Sprint Review to lepiej nie stosuj Scruma.

2. Wysoka przewidywalność 

Scrum to zwinność, czyli agile, oznacza to  oczywiście empiryzm. Empiryzm jest bardzo przydatny w środowisku z małą przewidywalnością, gdy na bieżąco weryfikujemy  hipotezy biznesowe oraz techniczne, aby  mieć „feedback od rzeczywistości”.  Jeżeli  jednak rzeczywistość, w której się poruszamy  jest przewidywalna i  predykcja w  100%  wystarcza to empiryzm jest niepotrzebny.  Szkoda strzelać z armaty do komara. Zamiast  Scruma lepiej zastosować waterfalla.

3. Za niska przewidywalność

Co ważne, zwinność Scruma ma też swoje  limity. Aby miał sens musimy móc zaplanować prace przynajmniej na jeden Sprint. Jeżeli  priorytety prac oraz zakres zmieniają się zbyt  szybko, Scrum za tym nie nadąży. 

Przykład: Jeżeli praca głównie polega na „łataniu” błędów krytycznych albo po prostu na utrzymaniu – Scrum będzie nas ograniczał, zamiast nam pomóc. Lepiej zastosować podejście beziteracyjne. 

4. Brak kontroli nad procesem 

Kolejnym przypadkiem, kiedy Scrum raczej  nie zadziała pozytywnie, jest brak kontroli  nad procesem wytwarzania produktu.

Przykład: W software house’ach często pracuje się dla  klientów, którzy nie oddają pełnej kontroli  nad procesem. Mogą naciskać na deweloperów, że mają więcej zaciągnąć na Sprint Planningu. Mogą też wpraszać się na Daily Scrum  i  stosować micromanagement. W  czasie  Sprintu mogą zmieniać ustalony zakres prac. Nie pozwalać na organizowanie Sprint Retrospective – „macie pracować a nie usprawniać  proces!”. Mogą nie zgadzać się na wszystkie potrzebne kompetencje np. testerów. Mogą  też nie chcieć płacić za Scrum Mastera albo Product Ownera.  

Oczywiście praca z takimi klientami może  być bardzo owocna, ale na 100% nie w Scrumie.

5. Brak interdyscyplinarnych zespołów

Scrum nie może funkcjonować skutecznie,  gdy nie ma interdyscyplinarnych zespołów  (cross-functional teams). Zespół Deweloperski musi mieć wszystkie kompetencje, aby  móc wydawać kolejne wersje produktu na  koniec Sprintu. Jeżeli nie da się uniknąć zależności z serwisami poza nasza kontrolą to…  klops. Doradzałbym poważnie się zastanowić  czy nie zorganizować pracy inaczej niż Scrum.

Przykład: Tylko deweloperzy z  innego działu mają  uprawnienia do operacji na bazie danych,  natomiast ukończenie inkrementu wymaga  takiej pracy. W takim przypadku planowanie  Sprintu bez udziału tych developerów nie  ma sensu. Oczywiście da się pracować w ta kim środowisku jednak lepiej nie „pchać się  w Scruma” w tym przypadku. Są inne rozwiązania. 

6. Projekt > produkt

Zdarzyło mi się kiedyś szkolić z zarządzania  produktem członków projektu dla jednego  ministerstwa. Podczas moich warsztatów  mieli za zadanie ustalić swoich interesariuszy.  Jeden z nich powiedział, że do interesariuszy  zaliczają się użytkownicy. Reszta wybuchnę ła śmiechem i powiedziała: „Co nas obchodzą userzy? Zamawiający ma nam zaakceptować  zakres i tyle” – to nawet zabawne dopóki sobie nie uświadomimy, że tego typu projekty są finansowane z naszych podatków. Czasami się zdarza tak, że nikogo nie  obchodzi wartość biznesowa produktu na  koniec.  Końcowy produkt nie jest ważny,  natomiast ważny jest tylko projekt, czyli: zakres, czas i budżet. Scrum w takim przypadku  nie jest zbyt dobrym wyborem. 

7. Niezmienialny zakres

Generalnie Scruma stosuje się po to, aby  mieć jak najkrótszą pętlę zwrotną, aby na  bieżąco modyfikować zakres, aby efekt koń cowy realizował potrzeby użytkowników i innych interesariuszy. Jeżeli nie ma możliwości  zmiany zakresu to Scrum jest niepotrzebnym  utrudnieniem. Szkoda się męczyć i denerwować. Lepiej wtedy nie stosować Scruma. 

8. Łamanie wartości scrumowych

 Fundamentem Scruma jest 5 wartości:

• zaangażowanie, 
• otwartość, 
• skupienie, 
• szacunek, 
• odwaga. 

Gdy dodano je do The Scrum Guide to po myślałem: „To takie HRowe gadanie”. Jednak  po latach widzę, że to był bardzo dobry ruch.  Bez choćby jednej z nich Scrum nie ma prawa  się udać. Co najwyżej będzie to Kult Cargo  inaczej zwany Zombie Scrumem. Czyli kolorowe karteczki, scrumowe ceremonie, dużo  agile’owej nowomowy, jednak bezzaimplementowania najważniejszych idei stojących za Scrumem. Takich jak empiryzm i  maksymalizacja wartości biznesowej. 

Przykład: 

Jeżeli nie ma otwartości i  odwagi na praw dziwą informację zwrotną od rzeczywistości,  na przykład, że produkt, który robimy od  2 lat, nie podoba się użytkownikom, że nie  ma w tej postaci szans osiągnąć sukcesu na  rynku, to jak Scrum ma zadziałać? U jednego klienta podczas wdrażania Scruma usłyszałem: „Nie mówmy tak otwarcie  o  wszystkich problemach. Po co stresować  ludzi? Po za tym idziemy zgodnie z planem.”.  Empiryzm w takim przypadku nie zadziała.

Oczywiście nie twierdzę, że w  każdej z  wartości scrumowej mamy mieć poziom  mistrzowski. Jednak, jeżeli kultura firmowa  jest im przeciwna, to dopóki tego nie zmienimy szkoda zachodu. Lepiej nie stosować  Scruma.

9. Brak know-how

Kolejna kwestia niby jest oczywista, jednak  bardzo często ją spotykam u moich klientów.  To brak wiedzy i  umiejętności.  Scrum jest  trudnym podejściem, trzeba umieć w  nim  pracować.  Nie wystarczy przeczytać Scrum  Guide’a (nawet dwa razy). Nie wystarczy też  wysłać kilku pracowników na szkolenie, po  którym zdobędą certyfikat Scrum Mastera. Oczywiście każda organizacja może zdobyć  ten know-how, dopóki jednak to nie nastąpi,  to odradzam stosowanie Scruma. Będzie on  zastosowany z  całą pewnością źle i  narobi  poważnych szkód. Dodatkowo ludzie bardzo  zniechęcą się do Scruma. 

10. Struktura organizacyjna

Nieadekwatna struktura organizacyjna może  skutecznie utrudnić pracę w Scrumie.

Przykład: 

Bardzo często widzę sytuację, że oprócz ról scrumowych w strukturze jest Project Manager. Oczywiście samo to, że jest PM nie jest ni czym złym. Problem pojawia się dopiero, gdy  PM dostaje po głowie, gdy zespół nie dowozi  prognozowanego zakresu na koniec Sprintu.  Jeżeli się tak dzieje, to przecież, aby wywiązać się ze swoich obowiązków, PM włączy  się w działania i będzie próbował zabrać autonomię zespołowi. W praktyce kończy się to  mniejszym lub większym micromanagementem. Samoorganizacja powoli umiera.  

Jeżeli hierarchia i obecna struktura stoi na  drodze Scrumowi i nie ma woli „góry” do zmia ny tej struktury, lepiej nie stosować Scruma. 

11. Uraz do Scruma

Czasami się zdarza tak, że wystarczy w  firmie użyć słowa Scrum, a ludzie od razu dostają ataku szału. Najprawdopodobniej ktoś  wcześniej zastosował u nich Scruma nieudolnie, powodując dużo frustracji i szkód. 

Nie twierdzę, że to zawsze powód, aby ka tegorycznie zrezygnować ze Scruma, jednak  na pewno zastanowiłbym się nad alternaty wą. Może się okazać, że opór przed Scrumem  jest tak silny, że wprowadzenie go będzie  wymagało za dużo wysiłku w  stosunku do  wartości, jaką to przyniesie.

 12. Brak autonomii Scrum Teamu

W Scrumie mamy 3 pozycje managerskie:

• Product Owner – zarządza produktem,
• Scrum Master – zarządza procesem,
• Deweloperzy – zarządzają swoją pracą i tym jak będą wytwarzać inkrement produktu. 

Aby to robić wszyscy muszą mieć odpowiednie umocowanie i decyzyjność w swoich  obszarach, jeżeli jej nie mają Scrum raczej nie  zadziała jak należy. Nie da tej wartości, co  powinien. 

Przykład: Product Owner jest tylko proxy pomiędzy deweloperami, a biznesem albo deweloperzy są  zarządzani za pomocą mikrozarządzania.

Generalnie Scrum jest narzędziem, które  może dać ogromną wartość. Trzeba jednak  pamiętać, że należy jest stosować we właściwy sposób i  we właściwych okolicznościach. Warto też zdać sobie sprawę, że nie  wszyscy muszą pracować w Scrumie.