W 2001 roku siedemnastu programistów podpisało Agile Manifesto i nikt wtedy nie przewidział, że dwadzieścia lat później setki tysięcy osób będą miały w tytule służbowym słowo “Agile”, a połowa z nich nie będzie wiedziała, co tak naprawdę robi. Role w projektach zwinnych wyglądają prosto na papierze. Product Owner, Scrum Master, Development Team. Trzy pozycje, jasne odpowiedzialności, wszystko opisane w dziewięciostronicowym Scrum Guide. Problem zaczyna się w momencie, gdy te trzy role trafiają do organizacji, która przez ostatnie piętnaście lat działała w modelu PRINCE2 albo PMI, gdzie było dziesięć ról, cztery komitety i dokładnie określone ścieżki eskalacji.
Product Owner albo ktoś, kto udaje, że wie czego chce klient
Product Owner to osoba odpowiedzialna za wartość biznesową produktu. Zarządza Product Backlogiem, priorytetyzuje funkcjonalności, mówi zespołowi co budować. W teorii ma wiedzę, mandat i czas. W praktyce trafiłem na Product Ownerów, którzy musieli konsultować każdą decyzję z pięcioma ludźmi z marketingu, dwoma z compliance i jednym z zarządu. W takich sytuacjach tytuł jest, ale odpowiedzialności brak. Ktoś inny decyduje, Product Owner przekazuje.
Roman Pichler w “Strategize” opisuje Product Ownera jako mini-CEO produktu. To brzmi dobrze do momentu, w którym okazuje się, że mini-CEO nie ma budżetu, nie może zatrudniać ludzi i każda decyzja wymaga aprobaty prawdziwego CEO. W korporacjach często Product Owner to analyst, który dostał nowy tytuł, ale nie dostał uprawnień. Zespół pyta o priorytet, on pyta kogoś wyżej, tamten pyta jeszcze wyżej, po tygodniu wraca odpowiedź, że “to zależy”.
Scrum Master czyli facylitator bez władzy
Scrum Master dba o proces. Usuwa przeszkody, prowadzi ceremonie, szkoli zespół w Scrumie. Nie zarządza ludźmi, nie rozdaje zadań, nie ocenia wydajności. Ken Schwaber i Jeff Sutherland w Scrum Guide z 2020 roku piszą wprost: Scrum Master jest liderem służebnym. Problem w tym, że w większości firm lider bez władzy formalnej jest traktowany jak osoba od organizacji spotkań.
Widziałem Scrum Masterów, którzy próbowali usunąć przeszkodę w postaci kiepskiego procesu zakupowego i po trzech miesiącach walki z procurement zostali pouczeni, że “tak tu się nie robi”. Widziałem innych, którzy prowadzili Daily Standupy jak raport statusu dla managera, bo manager siedział na Daily i robił notatki. Rola ma sens, gdy organizacja rozumie, że proces jest ważny. Gdy nie rozumie, Scrum Master staje się osobą od kalendarza i karteczek.
Development Team, czyli ludzie, którzy mają wszystko zrobić
Zespół deweloperski w Scrumie to samorganizująca się grupa trzech do dziewięciu osób, która przekształca Product Backlog w przyrost produktu. Bez tytułów, bez podziału na seniorów i juniorów, wszyscy odpowiadają za wszystko. W praktyce jakoś tak wychodzi, że senior robi architekturę, junior poprawia testy, a mid siedzi w Jirze i aktualizuje statusy, bo ktoś musi.
Brooks w “The Mythical Man-Month” z 1975 roku pisał, że dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej. Zespoły Agile miały ten problem rozwiązać przez stabilność składu i brak rotacji. Tyle że w większości firm ludzie są współdzieleni między projektami, jeden developer siedzi w trzech zespołach, ma dwóch managerów funkcyjnych i jednego Scrum Mastera, który próbuje go namówić, żeby przyszedł na Retro. Samorganizacja wymaga czasu i stabilności. Gdy zespół zmienia skład co kwartał, samorganizuje się głównie chaos.
Role, które oficjalnie nie istnieją, ale wszyscy je widzą
Scrum Guide opisuje trzy role. Organizacje dodają swoje. Project Manager, który “koordynuje”, bo ktoś musi raportować do zarządu. Business Analyst, bo Product Owner nie ma czasu na wymagania. Architect, bo zespół nie może decydować o architekturze samodzielnie. QA Manager, bo ktoś musi pilnować jakości. Po roku wdrażania Agile masz trzy role ze Scrum Guide i osiem ról dodanych, bo “u nas jest inaczej”.
Prawo Conwaya z 1968 roku mówi, że struktura systemów odzwierciedla strukturę komunikacji w organizacji, która je tworzy. Jeśli masz dziesięć ról, dostaniesz dziesięć interfejsów. Scrum zakładał trzy role, żeby uprościć komunikację. Dodawanie kolejnych to przywracanie problemu, który Agile miał rozwiązać.
Źródła
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Pichler R., “Strategize: Product Strategy and Product Roadmap Practices for the Digital Age”, Pichler Consulting, 2016.
- Brooks F.P., “The Mythical Man-Month: Essays on Software Engineering”, Addison-Wesley, 1975.
- Conway M.E., “How Do Committees Invent?”, Datamation, 1968.
- Beck K. et al., “Manifesto for Agile Software Development”, agilemanifesto.org, 2001.
Zdjęcie: Ketut Subiyanto / Pexels
