Model Spotify to nasze agile’owe nemezis. I wcale nie chodzi o to, że jest w nim coś z gruntu złego. Ale ta dobra w swoich założeniach idea wyrządziła wiele szkody naszemu zwinnemu środowisku.
Skąd się wziął Model Spotify?
W październiku 2012-ego roku, a więc siedem lat temu, Henrik Kniberg i Anders Ivarsson opublikowali słynny już dokument o nazwie „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”, od którego wszystko się zaczęło.
Podstawową komórką organizacyjną w Spotify był Squad, który zorganizowany został podobnie dobrze nam znanego Scrum Teamu. Squady w założeniach miały działać jak mini-startupy i skupione były na małych fragmentach funkcjonalności (np. „Polecane albumy i utwory w aplikacji webowej”). Były one też samoorganizujące się – niektóre z nich używały Scruma, inne Kanbana, a jeszcze inne – rozwiązań autorskich.
Każdy Squad miał swojego Product Ownera, który zarządzał backlogiem oraz Agile Coacha, który wspierał zespół. Ten ostatni nie mógł się nazywać Scrum Masterem, ponieważ nie każdy zespół pracował w Scrumie. Zasadniczo jednak Agile Coach był odpowiednikiem SM-a.
Kilka Squadów zajmujących się jednym obszarem, np. odtwarzaczem muzyki („plejerem”), zorganizowane było w Tribe’y. Na czele tych ostatnich stali Tribe Leaderzy, którzy dbali o odpowiednie środowisko i mniej lub bardziej nadawali kierunek rozwoju produktu i zajmującego się nim „plemienia”. Można zaryzykować stwierdzenie, że Tribe Leader to Product Owner, a spotify’owy PO to swego rodzaju Proxy Product Owner. Oczywiście, jeśli te backlogi są zupełnie niezależne to wtedy spotify’owy PO to po prostu PO, a Tribe Leader – kierownik, manager, Master/Area Product Owner.
Do tego dołożone zostały jeszcze tajemniczo brzmiące Chaptery. Te z kolei, to nic innego, jak grupy osób o podobnych kompetencjach w ramach jednego Tribe’u, np. developerzy aplikacji na Androida, testerzy automatyczni. Gdyby tego było mało, to czasami pojawiały się też kross-zespołowe inicjatywy obejmujące różnych ludzi z wielu Tribe’ów. Takie konstrukcje nazwane zostały Gildiami i nietrudno nam sobie wyobrazić Gildię Scrum Masterów (Agile Coachów), czy np. zadaniową Gildię RODO.
W tym opisie oczywiście pominąłem wiele niuansów. Np. na czele Chapterów stali kierownicy liniowi (np. przełożony wszystkich analityków w danym Tribie, team leader developerów, itp.). Społeczności gildiowe z kolei miały swoich koordynatorów.
Zainteresowanych szczegółami odsyłamy do źródła.
Model Spotify nie istnieje
Powiedzmy to wprost: nie ma czegoś takiego, jak „Model Spotify”. Wbrew temu, co głoszą niektórzy agile coache i prezesi, nie da się „wdrożyć Modelu Spotify”. A przynajmniej nie wygląda to tak, jak sobie to wyobraża większość osób głośno wypowiadających się na ten temat.
Zresztą, taką nadinterpretację przewidzieli panowie Kniberg i Iversson. Odpowiednie ostrzeżenie umieścili od razu na pierwszej stronie.
„Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working – a journey in progress, not a journey completed. By the time you read this, things have already changed.” – Scaling Agile @ Spotify
Cały „Model Spotify”, na którym niezliczone firmy wzorują swoje transformacje agile, to nic innego jak obraz organizacji jednej konkretnej firmy na pewien określony dzień w roku 2012. A to znaczy, że sytuacja wyglądała tam zupełnie inaczej zarówno kilka lat wcześniej, jak i kilka lat później.
Pamiętajmy też, że liczność zespołów deweloperskich ewoluowała razem z „modelem”. Spotify urosło z około trzydziestu ról deweloperskich w 2009 roku do dwustu pięćdziesięciu w 2012. A to znaczy, że „Model Spotify” z 2012 roku nie zadziałałby w tej samej organizacji w żadnym innym momencie. Jestem też absolutnie przekonany, że gdyby Spotify chciał dziś wdrożyć „Model Spotify”, to skończyłoby się to porażką.
Model Spotify opisany w dokumencie „Scaling Agile @ Spotify” jest tylko obrazem rozwiązania, które zostało zoptymalizowane dla jednej konkretnej firmy, w jednym momencie czasu i przy bardzo specyficznych okolicznościach przyrody. Polecam poczytać o dość ścisłym podziale kompetencji pomiędzy poszczególnymi Tribe’ami i Squadami w Spotify. Jeżeli nie pracujemy w ten sam sposób nad naszym produktem, to trudno się spodziewać, że u nas takie podejście sprawdzi się równie dobrze.
Bo tak naprawdę ten cały „Model Spotify” nie był stworzony. On stworzył się sam.
Ewolucja, a nie rewolucja
Pamiętajmy o tym, jak powstał cytowany w niniejszym tekście dokument. Był to opis ówczesnego stanu organizacji o nazwie Spotify, poczyniony na podstawie obserwacji. To bardzo ważne. Niektórym wydaje się, że panowie Kniberg i Ivarsson sami wymyślili taki, a nie inny model, który dopiero potem wdrożyli go w tej firmie. Tymczasem było dokładnie odwrotnie. To Spotify dał wolną rękę zespołom, które zorganizowały się tak, a nie inaczej.
„This scaling model – with Squads, Tribes, Chapters, and Guilds – is something that was introduced gradually over the past year, so people are still getting used to it.” – Scaling Agile @ Spotify
Zwróćmy uwagę na fragment „gradually over the past year”, który stoi w poprzek marzeniom prezesów i dyrektorów, którzy chcą „Przeszkolić 1500 osób z modelu Spotify.” Po pierwsze, samo dojście do takiego etapu, jaki został opisany w dokumencie, zajęło lata. Tego się nie da zrobić szybką, kilkumiesięczną transformacją. Po drugie, nic tu nie zostało narzucone z góry.
Prawdziwy „Model Spotify” to powiedzenie zespołom, że mogą pracować jak chcą, a następnie zamknięcie oczu i zaciśnięcie kciuków, licząc na to, że uda się stworzyć coś efektywnego. Dlatego tak ważne jest, aby mieć na pokładzie Scrum Masterów i/lub Agile Coachów, którzy tym całym procesem pokierują, a przynajmniej będą nad nim czuwać.
Bo nawet zwinność musi mieć jakieś ramy. Zespoły nie będą decydowały o strategii biznesowej, ta spłynie do nich za pośrednictwem PO. Tak samo nie będą one wymyślać sobie podziału na obszary i zespoły, czy też kombinować z przydziałem samych Product Ownerów do poszczególnych produktów. Część tych ograniczeń i ustaleń musi pochodzić z organizacji. Ktoś musi też nadawać jeden kierunek, posiadać jakąś wizję produktu i do niej dążyć.
Zróbmy własny „Model Spotify”
Jeżeli marzymy o wprowadzeniu „Modelu Spotify” w naszej organizacji, zróbmy to samo, co zrobił Spotify. Po pierwsze – dobrze poznajmy sposób, w jaki działamy. Potem podzielmy się na małe, zadaniowe, „start-upowe” zespoły. Na koniec zaś, zaufajmy naszym zespołom, dajmy im wolną rękę w kwestii samoorganizacji i pozwólmy im wykształcić potrzebne im mechanizmy. Zapewnijmy środowisko, pozwólmy (a nawet zachęcajmy) do spotykania się w grupach roboczych i zadaniowych.
Bo nie jest przecież tak, że jak tylko damy wolną rękę naszym pracownikom, oni zaczną marnować czas na spotkania. Przecież zwykle sytuacja wygląda zupełnie odwrotnie. Raczej słyszymy komentarze w rodzaju „Zostawcie programistów w spokoju!”
Skoro więc np. nasi testerzy automatyczni sami z siebie zdecydowali się spotykać raz w tygodniu i omawiać bieżące problemy oraz wymieniać się doświadczeniami, to raczej odpowiada to na jakieś ich potrzeby.
Jeżeli takie spotkanie nazwiemy „Chapterem testerów automatycznych w obszarze X”, to już możemy się chwalić, że mamy zalążki „Modelu Spotify”. Bo w podobny sposób wykształciły się wszystkie elementy opisany w tym nieszczęsnym dokumencie. To nie było tak, że ktoś krzyknął „Zróbmy tribe’y, chaptery i gildie!”, tylko one powstały, bo Spotify mierzył się z pewnymi określonymi problemami.
Weźmy pod lupę same Tribe’y. To nic innego, jak obszar z jednym wspólnym backlogiem, który realizowany jest przez kilka zespołów i przy wsparciu Proxy Produt Ownerów. Identyczne rozwiązanie znajdziemy w modelu LeSS, gdzie Tribe Leader nazywany jest Area Product Owner. Inne spojrzenie na Tribe’y to w miarę niezależni PO ze swoimi prywatnymi backlogami zebrani w jeden… obszar. To tylko pokazuje, że w wielu różnych zakątkach świata organizacje trafiają na podobne problemy i rozwiązują je w bardzo zbliżony sposób.
Zamiast więc małpować nieistniejący „Model Spotify”, zróbmy nasz własny. Pozwólmy ludziom samodzielnie rozwiązywać swoje problemy organizacyjne i zapewnijmy środowisko, które pozwoli im to robić z łatwością. Na pewno otrzymamy rozwiązanie o wiele bardziej dopasowane do naszych potrzeb, niż przestarzała, siedmioletnia kalka jakiejś szwedzkiej firmy.
Jeżeli jesteście zainteresowani, jak pracować zwinnie w dużych organizacjach, zapraszamy na nasze szkolenie pod tytułem Skalowanie Scrum, gdzie omawiamy różne podejścia do zwinnej pracy w kilka, kilkanaście i kilkadziesiąt zespołów.
