Pułapka 2: Rewolucja

Wdrożenie Scruma w dużej organizacji to zmiana, która powinna być wprowadzana powoli. Wszelkie rewolucje utrudniają ten proces, a czasem go przekreślają. Nie można wywrócić wszystkiego do góry nogami i wdrożyć sobie Scruma. Implementacja w dużej organizacji wymaga poszanowania dotychczasowego dziedzictwa - istniejących procesów, ról projektowych, realizowanych projektów. To zmiana, która powinna być jak wiosenny powiew, a nie przeciąg. Powinna być łagodna i delikatna.

Pułapka 3: Niechęć pracowników do pracy zespołowej

Scrum nie jest lekiem na całe zło. Nie próbujcie go wdrażać na siłę, we wszystkich projektach. Bo Scrum nie do wszystkich pasuje. Podobnie jest z członkami zespołów projektowych. Nie wszyscy się w nim odnajdują. Zawsze będą indywidualiści, którzy nie lubią pracy zespołowej.

Sam miałem kilka takich sytuacji, że ktoś po kilku sprintach, w wyniku szczerej rozmowy, oznajmiał, że nie jest to metoda dla niego. I nie wynikało to z jego niechęci do zmiany. Nie lubił pracy zespołowej. Miał swój świat, który próbował chronić. Świat skądinąd cenny dla organizacji. Takie osoby to często świetni specjaliści i nie można ich lekceważyć. Kiedy zdarzały mi się podobne sytuacje, zawsze wspólnie z menedżerem zastanawialiśmy się, czy nie znajdzie się dla nich miejsce w innych zespołach, niescrumowych. Okazywało się, że można ich było dołączyć np. do projektów badawczych, lub przedsięwzięć, w których pełnili rolę ekspertów dziedzinowych. Poza tym są projekty, w których wdrażanie Scruma nie ma sensu, np. w projektach utrzymaniowych.

Pułapka 4: Brak podejścia holistycznego

Wdrożenie Scruma w dużej organizacji często powoduje efekt kuli śniegowej. Nagle okazuje się, że implementacja wymaga adaptacji, a nawet przebudowy wielu procesów organizacyjnych.

Zanim zaczniecie planować wdrożenie, spróbujcie sobie odpowiedzieć na następujące pytania: Jak będzie wyglądało zarządzanie waszym produktem, który liczy od kilkuset do kilku tysięcy wymagań wtłaczanych do jednego wydania? Kto będzie odpowiadał za ustalanie priorytetów, skoro produkt składa się z kilku obszarów funkcjonalnych i ponad dwustu aplikacji? Czy jeden właściciel produktu wystarczy? Co z planowaniem wydań? Jak to się powinno odbywać? Jak do tego krajobrazu wkomponować sprinty? Powinniśmy je zsynchronizować, czy nie? Kto będzie nad tym wszystkim czuwał? Co z szacowaniem na różnych poziomach ufności? Dotychczas proces popytowo-sprzedażowy miał swoje kamienie milowe, a teraz? Jak powinna wyglądać konfiguracja zespołów scrumowych? Jak zarządzać ich dostępnością na poziomie całych wydziałów i departamentów? Jak włączyć w to klienta?