Ludzie często mylą tworzenie produktów w sposób adaptacyjno-iteracyjny z prowadzeniem projektu. My zawsze powtarzamy, że to są różne rzeczy. Scrum został stworzony do tej pierwszej. Czyżbyśmy właśnie mieli sami sobie zaprzeczyć w dzisiejszym tekście, mówiąc o tym jak Scrum ma się do zarządzania projektami? Przekonajcie się o tym sami.
Czym jest zarządzanie projektem?
Wydaje się, że niby wszyscy wiemy czym jest Project Management, ale czy jesteśmy w stanie zdefiniować to zjawisko bez zastanawiania się? Otóż zarządzanie projektem to dyscyplina poświęcona planowaniu, organizowaniu oraz realizacji czynności i środków skierowanych ku osiągnięciu celów projektu. Te procesy wykonujemy licząc się z licznymi ograniczeniami, takimi jak czas, budżet, zakres, warunki rynkowe, przepisy prawne i tak dalej. Osoba, która za tym stoi to z reguły Project Manager.
Definicja zarządzania projektami naprowadza nas na wniosek, że nie możemy bez tego zjawiska się obejść. Nieważne, co tworzymy, w jakiej dziedzinie czy metodyce, każdy projekt biznesowy będzie miał pewne kluczowe potrzeby. Wszędzie będzie potrzeba w tworzeniu pewnych planów i skutecznym zarządzaniem środkami. Absolutnie wszędzie będzimy mieli do czynienia z ograniczeniami oraz ryzykami, którymi któs powinien należnie zarządzać.
Czy znaczy to, że Project Manager w Scrumie jednak musi być? I czy autorzy podręcznika Scrum przegapili tą całą sprawę, nie dodając roli PM-a do swego frameworku?
Scrum, a zarządzanie projektem
Wiele potrzeb związanych z zarządzaniem jest już pokryte poprzez procesy Scumowe – o ile wprowadzimy je jak należy. Planowanie Sprintu pozwala nam zarządzać zakresem, jednocześnie wliczając ograniczenia oraz ryzyka. Refinement Backlogu umożliwia to poprzez ciągłą pracę nad definiowaniem wymagań. Sprint Review daje nam możliwość kontroli naszej pracy oraz ewentualnego usprawnienia. Retrospektywa jest możliwością do Inspekcji oraz Adaptacji w kwestiach efektywności oraz jakości naszych działań. Daily Scrum zabezpieczna organizowanie pracy per dzień roboczy.
Chyba jednak Sutherland i Schwaber wiedzieli, co należy umieścić w Scrumie, a co można pominąć…
Samozarządzanie
Patrząc na sposób zarządzania (projektem?) w Scrumie można zauważyć, że nie ma tam żadnego Kierownika, który by był za to odpowiedzialny. O to właśnie chodzi, że odpowiedzialność ta leży na całym zespole. Metodyki zwinne wprowadziły koncepcję kolektywnej odpowiedzialności. To sprawiło, że zamiast jednej osoby, która kieruje (projektem?), te obowiązki są albo przydzielone do konkretnych odpowiedzialności Scruma, jak Scrum Master czy Product Owner, albo są rozsmarowane po całym Zespole Scrumowym jak masło po kawałku chleba.
O tym właśnie mówimy wspominając o samozarządzających się zespołach w Scrumie. Jeżeli chcielibyście dowiedzieć się więcej na temat tego, czym jest samozarządzanie się oraz samoorganizacja, polecamy artykuł na ten temat.
Scrum z Project Managerem czy bez?
Skoro Zespół Scrumowy funkcjonuje na zasadach samozarządzania się oraz kolektywnej odpowiedzialności, to wydaje się, że nie ma tu miejsca na Managera Projektu. Odpowiedź brzmi i tak, i nie.
Działając w Scrumie, nigdy nie możemy pozwolić na waterfallowy format, gdzie Kierownik przydziela poszczególnym osobom zadania, a następnie ich z tych zadań rozlicza. Nie może mieć miejsca sytuacja, gdzie Developerzy są postrzegani jako zasoby, a nie jako drużyna kompetentnych specjalistów, zdolnych do kreatywnego myślenia oraz podejmowania samodzielnych decyzji. Nie ma miejsca na Command and Control, ani na Micromanagement. Razem z tym, wciąż mamy potrzeby typu zarządzania budżetem, kontraktami oraz innymi kwestiami prawnymi. Podręcznik Scruma nic nie mówi o tym, kto i jak będzie załatwiał te sprawy. A one muszą być załatwiane.
Project Manager może być osobą, która weźmie na siebie sprawy organizacyjno-administracyjne. Ważne przy tym jest, żeby ta osoba została zapoznana z zasadami zwinnego wytwarzania produktów. Równie ważne jest, żeby była świadoma autonomii zespołu oraz granic własnych pełnomocnictw. Tę kwestię możemy zapewnić poprzez klarowne określenie obowiązków oraz ograniczeń każdej roli w kontrakcie zespołu. Więcej o tym, jak PM może wesprzeć Zespół Scrumowy (bądź mu zaszkodzić) możecie znaleźć w artykule o Project Managerze.
Potrzeby zespołu, a potrzeby organizacji
Brak wskazówek co do budżetu bądź umów w Scrum Guide nie znaczy, że jego twórcy nie zdawali sobie sprawy z konieczności ogarniania tych kwestii. O tym więcej powiedzieli w innym swoim frameworku – Professional Agile Leadership. Jeżeli Scrum skupia się na perspektywie zespołu, to PAL już dotyczy kwestii całej organizacji oraz wyzwań z którymi ona się zmaga. Szczególnie jeśli podejmuje się Transformacji Zwinnej.
Tak samo jak Scrum Master wspiera pojedynczy zespół, albo grupę zespołów pracujących nad pewnym produktem, Agile Leader wspiera organizację w zarządzaniu swoimi produktami w sposób zwinny. W skrócie sprowadza się to do umocowania zespołów w ich autonomii, a jednocześnie ustaleniu odpowiednich osób do zarządzania kwestiami biznesowymi tego produktu. Będą tu i budżety, i ryzyka, i zatrudnianie nowych osób i wiele podobnych rzeczy.
Jak widzimy, zarządzanie projektami wcale nie jest rzeczą daleką od Scruma, jedynym problemem jest przekonaniu o konieczności zarządzania w tradycyjny waterfallowy sposób, zamiast lepszego, polegającego na przywództwie zwinnym.
