Tak zwany „Model Spotify”

W polskim świecie agile’a strasznie głośno ostatnio o, wydawało się już nieco zmurszałym, tak zwanym “modelu Spotify” (zerknij też: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf). A to jakiś złośliwy twitt, a to pouczający materiał, podany w formie jakże popularnego w tych zabieganych czasach modelu “jadę i mówię”, jest i coś w standardowej formie blogowego wpisu. Czy do tych trzech spójnych, słusznych, choć nieco podirytowanych i zniecierpliwionych opinii, można jeszcze cokolwiek dodać? Spróbuję, kierując optykę na dwa zjawiska, które wydają mi się na tyle frapujące, by o nich wspomnieć.

Wspomniałem o pewnym poirytowaniu wyczuwalnym we wspomnianych wypowiedziach, objawiającym się w momentami szyderczej wręcz ironii. Wcale mnie to sardoniczne podejście nie dziwi, kiedy spoglądam ogłoszenia czy filmiki promocyjne firm z naszego ukochanego sektora IT. Oto, niektórzy, chcąc niewątpliwie się wyróżnić w byciu “cool i trendy”, aby ściągnąć rozpieszczonych sytuacją na rynku programistów, wpadli na kolejny świetny pomysł. Dość nudnych zespołów i menedżerów, zmieńmy szyldy. I tak, możemy natrafić na klany i gildię z mistrzami czy plemiona z wodzami. Natknąłem się także w ogłoszeniu na ofertę dołączenia do bractwa (cóż za niepoprawność polityczna!). Czyż te nazwy nie brzmią dziwnie znajomo? I tak rozpoczynając pracę, nie dołączasz już do dynamicznego młodego zespołu, ale do deweloperskiego plemienia. Oczywiście, jeśli przejdziesz rekrutację, którą prowadzi Wielki Manitu.

W tym momencie aż prosi się o zacytowanie tekstu Kate Hobler:

Weźmy grupy ludzi, z których nie potrafimy stworzyć zespołów, które nie potrafią pracować interdyscyplinarnie, i zorganizujmy ich w nowe jednostki, które będą miały tych samych menedżerów i ten sam sposób zarządzania. Jak nazwiemy ich Trajbami i Skłodami, to magicznie wszystko się zmieni na zwinne!

No właśnie. W samych tych nazwach nic złego, choć mnie osobiście drażni postępująca infantylizacja, którego jest to wyraźnym przejawem. Sęk w tym, że kiedy przyjrzeć się bliżej tym ogłoszeniom, obejrzeć te materiały reklamowe w całości, albo chwilę porozmawiać przy okazji różnych branżowych spotkań, to okazuje się, że pod płaszczykiem pięknych nazw kryje się stara dobra utylizacja zasobów, a przywódca Gildii to stary PMowy wyga w owczej skórze, który opracował już harmonogram i zadba o jego odpowiednią realizację.

Zdaje się, że sam w tym momencie stałem się zgorzkniały i sarkastyczny. Tak to właśnie działa. Nie da się na to patrzeć ze spokojem. I nie chodzi tylko o to, że trzeba będzie zmieniać stanowisko ze Scrum Mastera na Mistrza Cechowego…

Druga sprawa. Bodajże bardziej istotna. Na naszych oczach powoli zbliża się koniec okresu, nazwijmy go, Wielkich Transformacji. Agile’owa konkwista w IT powoli dobiega końca. To, co było novum, staje się czymś powszechnym, oczywistym. Mam wrażenie, że całkiem sporo firm doszło już do etapu, gdzie są już całkiem dobrze działające – będę staromodny – zespoły, a w nich całkiem sprawnie ta zwinność się usadowiła. Podstawy zaliczone. I tu następuje etap,w którym zawsze pojawiają się dwa wielkie problemy. Pierwszy – skalowanie, zostawmy sobie na kiedy indziej. Drugi – nieco powiązany – ale związany przede wszystkim z tematem tego tekstu, to komunikacja międzyzespołowa i związane z tym problemy. Co nieco o tym już pisałem. A to dwa zespoły, których pokoje dzieli przecież jedna ściana, od dłuższego czasu wytwarzały tę samą funkcjonalność. A to jedni zapomnieli o zależności w kodzie od drugich i gdzieś tam coś się popsuło. A to okazało się, że w zespole A architekt X powiedział, że fajne będzie DDD, a w zespole B architekt Y, że wg niego ZZZ pasuje tu lepiej. I jak przyszło do połączenia efektów prac tych zespołów, potrzebne były kolejne tygodnie na refaktoryzację wszystkiego. A to w jednym zespole pisano zgodnie z PHPowym PSR-em, podczas gdy w drugim wypracowano własne standardy. I tak dalej, i tak dalej.

Innymi słowy, pojawiają się standardowe problemy: przepływu informacji, utrzymania w ramach firmy spójnej architektury i standardów, współpracy międzyzespołowej. I właśnie tu wkracza Spotify ze swoim znakomitym pomysłem, fajnie opisanym, z chwytliwym słownictwem. Pomysł wydaje się banalnie prosty, oczywisty i gotowy do wprowadzenia. I tu właśnie tkwi cała pułapka. Utworzyć firmowe społeczności: JavaScriptowe, PHPowe, DevOpsowe, Javove, Testerskie itp. itd., i nazwać je gildiami, to żaden problem. Zorganizować ich spotkania – również. Spowodować jednak, żeby to faktycznie zadziałało, żeby pojawiały się tam wartościowe informacje, żeby ludzie wymieniali się wiedzą, dbali o jedną wizję i cel w obrębie całej firmy, a wyniesione lekcje i usłyszane informacje przenosić na forum zespołów – to dopiero wyzwanie. Wyzwanie bardzo trudne, a stoi przed nim praktycznie każda większa firma stosująca agile.

“Model Spotify” wydaje się być bardzo kuszącą wizją. Nic lepszego w tej materii agile’owy świat nie zaoferował, nie dziwmy się zatem, że wszyscy tak ochoczo (i niestety – automatycznie) go stosują. Nasza w tym teraz robota, żeby przekierować to na właściwe tory. Zakasać rękawy i pomóc organizacjom. Pokazać inne drogi, recepty, szersze konteksty, zacząć to wszystko w sensowny sposób porządkować. Nie tylko ograniczyć się do mentorskiego “nie tak”, podkreślać że to snapshot, że marketing, że inna kultura, mentalność, że kontekst… To wszystko cholernie istotne, fakt. Ale wyraźnie na tym polu brakuje w firmach większej wiedzy, pomysłów, jawnych wskazówek. Działajmy zatem. Nie chciałbym bowiem za jakiś czas stanąć gdzieś na polu u boku jednej gildii, naprzeciwko drugiej. A po haśle: You bled for agile, now bleed for me, ruszyć do boju.

#management #ScrumMaster #skalowanie #technikalia