Nie pamiętam dokładnie skąd, ale skądś wzięło się przekonanie, że Scrum działa tylko przy jednym bądź dwóch zespołach. Co zrobić gdy tych zespołów mamy więcej?
Scrum dla jednego zespołu
Częstą krytyką Scruma jest przekonanie, że działa on dobrze tylko i wyłącznie dla jednego bardzo specyficznego zespołu. O specyfice pisaliśmy wielokrotnie mówiąc że Scrum jest podejściem produktowym i średnio nadaje się do prowadzenia projektów. To znaczy, że nasz Scrum Team musi być produktowy. Ale wcale nie jest powiedziane, że musi być tylko jeden.
W najnowszym Scrum Guide wyraźnie zapisane jest, że w przypadku wielu zespołów pracujących nad jednym produktem, powinny one posiadać jeden Product Backlog i jednego Product Ownera. Nic nie znajdziemy jednak nic na temat tego, w jaki sposób mają one synchronizować swoją pracę bądź też jak konkretnie mają być zorganizowane.
Dawno, dawno temu ubzdurało mi się, że w jakich materiałach źródłowych napisano że Scrum działa dobrze dla dwóch do trzech zespołów. Nie udało mi się jednak potwierdzić istnienia tego zdania w którymkolwiek z guide’ów – scrumowym bądź nexusowym. Nie ma to jednak większego znaczenia w dzisiejszych rozważaniach, bo tak naprawdę możemy mieć do czynienia z jedną z dwóch sytuacji. Albo nasze zespoły tworzą jeden produkt, albo tworzą ich kilka. Ile ich jest to rzecz wtórna.
Jeden Produkt – Wiele Zespołów
Jeżeli mamy kilka zespołów tworzących jeden produkt to sam Scrum przychodzi nam z pomocą. Kluczowe jest stwierdzenie, które już w dzisiejszym tekście padło, czyli fakt, że mamy do czynienia z jednym Produktem i jednym Product Ownerem.
Powyższe informacje sugerują, że przynajmniej Refinement będziemy musieli przeprowadzać w jakimś zakresie wspólnie, aby rozpoznać, podzielić i oszacować Elementy Backlogu Produktu. Ponieważ prace w poszczególnych zespołach planujemy dopiero na Planowaniu Sprintu, to i tu wypadałoby aby przynajmniej na jego pierwszej części obecni byli wszyscy. Mamy w końcu jednego PO, który na początku jasno powinien powiedzieć, jakie ma oczekiwania co do najbliższego Sprintu, udzielić ostatnich wyjaśnień odnośnie planowanych do realizowania prac oraz pomóc w podzieleniu wymagań pomiędzy zespoły.
Skoro już wiemy że na Product Backlogiem pracujemy raczej wspólnie i mamy jeden produkt, to w naturalny sposób sugeruje to, że Sprint Review również powinno być wspólne. Trudno jest bowiem mówić o naszym produkcie w kawałkach. Jeszcze trudniej jest zapraszać interesariuszy i osoby z biznesu na różne, a czasami nawet na równoległe spotkania.
Oczywiście, nigdzie nie jest powiedziane że Sprinty naszych zespołów muszą być synchronizowane. Jednak robienie tego w jakikolwiek inny sposób, jest proszeniem się o kłopoty. Rekomendacja #białko to zawsze ten sam dzień startu Sprintu dla wszystkich zespołów pracujących nad jednym produktem i ta sama długość Sprintu.
Portfolio Produktów, a wiele zespołów
Wszystko jest proste tak długo, jak pracujemy nad jednym produktem i jesteśmy w stanie ogarnąć wszystko osobą jednego Product Ownera. Jeżeli jednak pracujemy nad skomplikowanym systemem, jest nas kilkanaście bądź kilkadziesiąt zespołów albo nasze rozwiązanie to tak naprawdę kilka zakamuflowanych mniejszych produktów, to musimy sięgnąć po inne środki.
Pierwszym i najważniejszym narzędziem do dobrego zorganizowania pracy wielu zespołów w Scrumie jest… właściwy podział zespołów. Większości problemów ze skalowaniem Scruma można uniknąć, właściwie planując produkty i zespoły.
Im mniej zależności, im mniej na chodzenia na siebie pracy, tym mniej konieczności powoływania pośredników, synchronizowania prac i uważania na siebie. Działając niezależnie o wiele łatwiej doprowadzić do sytuacji, w której mamy normalne Zespoły Scrumowe działające według normalnych zasad Scruma.
Budowanie Scrum Teamów wokół usług świadczonych dla kilkunastu bądź kilkudziesięciu różnych klientów albo takich w których realizujemy pracę na rzecz kilku różnych projektów, albo takich które rozwijają kilkanaście systemów bądź aplikacji zawsze kończy się ScrumButem. I to tym najgorszym, który nie ma nic wspólnego z obietnicami Scruma.
Scrum dla kilku(nastu) zespołów
A co w sytuacji w której nie mamy wyjścia i musimy pracować w kilkunastu lub kilkudziesięciu zespołach rozwijając jeden bądź kilka produktów z wykorzystaniem metodyki Scrum?
Przede wszystkim pamiętajmy, że wcale nie musimy tak pracować! Jeżeli ktoś gdzieś podjął taką decyzję, to znajdźmy tą osobę i zapytajmy „Dlaczego akurat Scrum? Co chcemy dzięki niemu osiągnąć?”. Bardzo często okazuje się, że nikomu tak naprawdę nie zależy na korzyściach płynących ze stosowania tej metodyki, a tak naprawdę liczą się zupełnie inne rzeczy. Nie ma co wtedy udawać, że pracujemy w Scrumie. Nie twórzmy więc fikcji, tylko znajdźmy rozwiązanie odpowiednie dla naszych celów.
Jeżeli jednak chcemy wykorzystać siłę naszej ulubionej metodyki, to przede wszystkim wypracujmy taki podział zespołów, który będzie jak najbliższym modelu opisanego wcześniej. Dajmy maksimum autonomii dla PO i twórzmy Backlogi Produktów jak najbardziej niezależne i odseparowane od siebie. Niech każde kilka zespołów faktycznie „pracuje nad jednym produktem z jednym Product Ownerem”.
Idąc dalej i skalując się zarówno wzwyż jak i wszerz, będziemy potrzebować pewnych mechanizmów synchronizujących i pewnych ról które zapewnią nam spójność. Tutaj pojawi ci się mogą Area Product Ownerzy bądź Proxy Product Ownerzy, Scrum of Scrums, wspólne planowania, zarządzanie przez wydania i tym podobne mechanizmy.
Skalowanie takie proste?
Uważnie czytelnicy zeszłotygodniowego tekstu Artura pewnie zauważyli, że opisywane w dzisiejszym artykule sugestie, porady i narzędzia są całkiem standardowe i znaleźć je można w niejednej metodyce. Wspólne Planowanie, wspólne Review, osobne Daily i tak dalej to pewien standard, który znajdziemy w prawie każdej metodyce skalującej Scruma.
Jeżeli masz do czynienia z dwoma bądź trzema zespołami, to takie „lekkie skalowanie” to wszystko, czego potrzebujesz. Jeżeli mierzysz się z jeszcze większymi przedsięwzięciami, to pamiętaj że każdy przypadek jest inny. Warto zapoznać się z popularnymi modelami i na ich podstawie wybrać to, co może zadziałać.
Nie ma co błądzić po omacku – jeżeli chcesz poradzić się kogoś, kto wielokrotnie miał okazję budować skalowane Zespoły Scrumowe, to gorąco się polecamy! Zarówno w kwestii konsultacji i doradztwa, jak i szkoleń. W ramach „Skalowania Scrum” opowiadamy o tym, jak wyglądają popularne i niszowe modele oraz staramy się dobrać odpowiedni dla Twojej sytuacji. A gdyby tego było mało, na zimę planujemy narzędziowe szkolenie dla Scrum Masterów, które między innymi porusza tematykę budowania właściwych Zespołów Scrumowych w dużej skali. Zapisz się na naszą listę mailingową, aby nie umknęła Ci premiera naszej nowej propozycji!
