Jak mierzyć wydajność zespołu Scrumowego?

W jedenastym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel i Maciej Malesa rozmawiają o tym, jak mierzyć wydajność zespołów Scrumowych. Jak porównywać ze sobą efektywność pracy równoległych zespołów. I jak odnosić je do celów całej organizacji?

Z tego odcinka dowiesz się między innymi:

• Czy jest wzorcowy sposób mierzenia pracy zespołów Scrumowych?
• Czy w ogóle warto mierzyć pracę takiego zespołu? I czy da się ze sobą porównać prace dwóch niezależnych zespołów Scrumowych?
• Co powinniśmy mierzyć?
• Jakie miary nie działają?
• Czym są i czy warto stosować Story Pointy? I czy jest to miara wydajności zespołu?
• Czy zespołom zdarza się „kreatywna księgowość” w rozliczaniu efektw swojej pracy i jak jej uniknąć?
• Jak zmierzyć wartość, jaką dostarczają zespoły? Co powinno się składać na tę miarę?
• Jak oceniać zespoły zarządzające już istniejącym produktem, a jak te, które go dopiero tworzą?
• Czym różnią się OKR od KPI?
• Czy warto dać zespołom możliwość samodzielnego określenia celów i mierników?
• Jak wystandaryzować rozumienie terminów i mierników w całej organizacji?

Transkrypcja podcastu

Paweł: Cześć, z tej strony Paweł Tomkiel.

Maciek: I Maciek Malesa.

Paweł: Jesteśmy konsultantami w Agile Advisory Deloitte Digital. Dzisiaj zajmiemy się tematem, który myślę, że zna wiele firm wprowadzających metodyki zwinne, szczególnie, kiedy pojawiają się już w nich zespoły Scrum’owe. I do tej dyskusji zaprosiłem Maćka Malesę, lidera Agile Advisory w Deloitte.

Maciek: Cześć, dzień dobry. Dzięki, Paweł, za zaproszenie.

Paweł: Maciek, to żeby zacząć, wyobraźmy sobie organizację, która przeszła transformacje zwinną, pojawiły się w niej zespoły Scrum’owe. Organizacja, która do tej pory działała w zespołach funkcjonalnych, były to czasem silosy, czasem nie, teraz próbuje zmierzyć, jak wydajne są zespoły Scrum’owe. Jakie są najlepsze wzorce, jakie są dobre praktyki, co możesz powiedzieć ze swojego doświadczenia?

Maciek: No bardzo, bardzo ciekawe i niełatwe pytanie. Może, żeby sobie wyobrazić kontekst, to właśnie tak, jak powiedziałeś, mamy organizację, która niedawno przeszła transformację, czyli powiedzmy ma trzydzieści zespołów Scrum’owych, czyli trzysta osób pracuje zwinnie. I to nie jest łatwe pytanie. Tak powiem szczerze, że tak jak w Polsce widziałam pięć, sześć różnych dużych organizacji z zespołami zwinnymi, to nie widziałem takiego wzorcowego podejścia do tego wyzwania.

Paweł: Często pojawiają się story pointy, jako jednostka mierzenia takiej wydajności.

Maciek: Tak. I nie wiem, czy dzisiaj w ogóle dojdziemy do jakiegoś wniosku, do jakiejś konkluzji. Więc może, na początku zacznijmy od tego, czy w ogóle warto mierzyć. No bo często pada takie pytanie, szczególnie gdy chodzi o Scrum Masterów. Po co mamy cokolwiek mierzyć? Czy potrzebujemy jakimiś liczbami określać, co robi zespół? A może po prostu dajmy tym ludziom pracować i nic nie mierzmy.

Paweł: Czy to jest pytanie podchwytliwe?

Maciek: Może spróbujmy tutaj to na początku wyjaśnić, jak uważasz, w ogóle jest sens mierzyć?

Paweł: Jest taki popularny cytat, że „nie możesz kontrolować tego, czego nie mierzysz”.

Maciek: Tak, to chyba Peter Drucker powiedział. Nie możesz zarządzić tym, czego nie potrafisz zmierzyć. Ja też chyba skłaniam się ku temu, że powinniśmy mierzyć i to chyba nawet w duchu Agile’owym. Bo jeżeli mierzymy coś, czy to jest efektywność zespołu, czy cokolwiek innego, to możemy wyciągnąć wnioski z tych wyników, tak? Mierzymy i patrzymy, czy jesteśmy zadowoleni z tego wyniku, czy powinniśmy coś zmienić, żeby osiągnąć lepszy.

Paweł: Ja bym chyba powiedział, że cała zwinność opiera się na danych, opiera się na tym, co wiemy. Nie próbujemy przewidzieć przyszłości, tylko faktycznie próbujemy zmierzyć to, co się wydarzyło i na tej podstawie coś zaplanować w przód. Czyli jakby samo zmierzenie takiej wydajności zespołu pozwala samemu zespołowi określić ile jest w stanie zrobić, czy jest w stanie coś zrobić w następnym sprincie. Chyba ja bym w ogóle nie kwestionował tego, że mierzenie się przydaje w samej zwinności. Wydaje mi się, że to leży bardzo, bardzo u podstaw.

Maciek: Też tak myślę. Znaczy to pewnie, co poruszyłeś, to dotyczy mierzenia capacity zespołu, tak? Ile zespół może wziąć na klatę na następny backlog, czy da radę, patrząc, na nie wiem, na wielkość funkcjonalności, wielkość user story, mierząc w story pointach na przykład, więc jak najbardziej. Czyli chyba dochodzimy do wniosku, że trzeba mierzyć. Ja jeszcze tak powiem, że raz uczestniczyłem w takiej rozmowie właśnie, gdzie Scrum Masterzy raczej uważali, że nie powinniśmy mierzyć. No i wtedy zadałem takie pytanie właśnie, a czy ty patrzysz i mierzysz, jaką dostajesz pensję co miesiąc. No i wyszło, że tak, że jednak każdy pracownik patrzy, jaką dostaję co miesiąc pensję, więc te liczby są istotne w naszym życiu. Więc z perspektywy teraz właściciela firmy albo właściciela zespołów Scrum’owych, on też ma prawo coś mierzyć. No i to, jak teraz doszliśmy do tego wniosku, okej, to już jest jedna rzecz, jakaś konkluzja, fajnie, mam nadzieję, że już nie będziemy do tego wracać.

Paweł: W ogóle bardzo łatwo jest dojść do takiej konkluzji, jeżeli przy stole usiądzie, tak jak tutaj, dwóch Agile coachów i zapyta się ich, czy warto mierzyć. To bardzo szybko nam to poszło.

Maciek: No tak, w szczególności z Deloitte’a, w sensie z firmy, która ma we krwi bycie data driven. Chciałem, wiesz co, to poruszyć, bo nieraz się jednak łapię na tym, że wychodząc z jakiegoś środowiska, zamykamy pewne perspektywy i może nieraz warto otworzyć się na inne spojrzenie, więc chciałem sprawdzić, że może mierzenie dalej jest adekwatne czy nie, ale wyszło, że tak. Chociaż jesteśmy w dość homogenicznym gronie, więc zdziwiłbym się jakby wyszło nam inaczej. Może kiedyś warto do studio zaprosić kogoś z innej organizacji.

Paweł: Czyli w 2020 nadal mierzymy?

Maciek: Mierzymy, mierzymy, tak. Dobra, no to teraz, żeby dojść do kolejnego wniosku, jeszcze nie co mierzyć, to jeszcze może zastanówmy się, co nie mierzyć. O, może jakby z naszych doświadczeń spróbujmy sięgnąć pamięcią i zastanowić się, jakie miary nie działają. Może to będzie łatwiej niż powiedzenie, co mierzyć.

Paweł: No dobra, a jakie przykłady miar mamy tutaj na celowniku? Mi przychodzą na myśl pierwsze story pointy, najczęściej wykorzystywana miara i najczęściej też kwestionowana przez Scrum Masterów i przez same zespoły.

Maciek: Super, to zacznijmy od story pointów. Czyli uważasz, że warto stosować story pointy czy nie?

Paweł: Żeby ujednolicić tą dyskusję, no to taka krótka definicja, story point to jest jednostka bardzo relatywna, w której zespoły oceniają złożoność tego, co wdrażają, tego, co tworzą.

Maciek: Tak, czyli jak patrzymy na zakres tego, co robi zespół i to, co robi zespół jest opisane w backlogu, jeżeli chodzi o zakres, a ten backlog jest rozbity na user story, na historyjki użytkownika i teraz jest taka technika, i to też nie jest technika, która jest opisana w Scrum Guidzie, absolutnie nie, Scrum Guide tylko mówi, że zespół powinien wyceniać wielkość tego, co robi, ale nie mówi, jak to robić. No i teraz jest taka praktyka, żeby na poziomie tych historyjek przypisać taką miarę abstrakcyjną, relatywną, że na przykład dana historyjka wymaga od nas pracy, zaangażowania albo jest w jakiś tam sposób ryzykowna i powiedzmy na trzynaście punktów, a inna historyjka na pięć. I jedyny wniosek, jaki możemy wyciągnąć z tych dwóch miar, to jest, że ta druga jest łatwiejsza. Ja lubię korzystać ze story pointów właśnie nie po to w sumie też, żeby mierzyć przede wszystkim, ale żeby prowokować rozmowę w zespole. Bo jeżeli zespół ma dojść do wniosku, że ta historyjka jest trzynaście, a ta pięć, to na początku musi się odbyć rozmowa i jest wymiana wiedzy, wymiana spostrzeżeń i ktoś mówi, no słuchajcie, to jest trzynaści, bo to jest dla nas dużo, nigdy tego nie robiliśmy, nie mamy półproduktów, żeby to zrobić, a wtedy ktoś podnosi rękę nie, nie, to nie jest trzynaście, to jest pięć, bo słuchajcie, mamy już tu takie biblioteki albo mamy już tu takie makiety, albo to jest podobne do tego, co robiliśmy ostatnio. I tak naprawdę według mnie najbardziej wartościowa w wycenie, w story pointach, jest ta rozmowa, to uspójnienie wiedzy, rozmowa o oczekiwaniach product ownera w stosunku do tej historyjki. Nagle product owner też, który tak naprawdę nie powinien uczestniczyć w wycenie, ale ja sądzę, że tutaj też jest kilka szkół,, czy ma uczestniczyć. czy nie, raczej nie powinien, bo tak mówi Scrum Guide, że to zespół wycenia, a nie product owner, ale też wtedy product owner, ja widziałem często, mówi, dlaczego dajecie tu trzynaście, przecież to jest takie łatwe, przecież to jest dwa, przecież to jest jeden przycisk. Ale wtedy zespół tłumaczy, no tak, ale wiesz, dla ciebie to jest jeden przycisk, a dla nas to są algorytmy, to są linijki kodu i tak dalej. Więc już wiemy mniej więcej, czym jest story point. To teraz się zastanówmy, czy mierzyć w story pointach efektywność.

Paweł: Dokładnie, czy to jest miara wydajności zespołu. Bo jakby same story pointy zgadzam się, że są potrzebne samemu zespołowi. Zespół dobrze, żeby mierzył, dobrze, żeby wyceniał, żeby nabierał czy to rozmawiał, tak jak Ty powiedziałeś, i żeby nabierał takiej troszeczkę większej pewności co do tego, co są w stanie zrobić. Ale to jest na poziomie zespołu. A teraz gdybyśmy mieli zapytać, czy można tym porównać, czy to jest miara, którą możemy porównać wydajność dwóch zespołów w ramach jednej organizacji, czy management może na podstawie story pointów powiedzieć ten zespół jest wydajniejszy od tego?

Maciek: No właśnie, ale to fajne zdanie powiedziałeś, że to jest miara dla zespołu. To jeżeli uznamy, że to jest prawdziwe zdanie, to czy w ogóle story pointy powinny wyjść poza zespół? Czy jest dobrą praktyką, aby pokazywać story pointy komuś innemu, komuś, kto nie należy do zespołu?

Paweł: No i tutaj w takim razie uderzę do transparentności, która jest podstawą zwinności, że tak, mamy backlog, który jest wyceniony w story pointach i ten backlog jest transparenty, jest widoczny dla kluczowych uczestników całego procesu, więc management widzi story pointy.

Maciek: To też ciekawe spojrzenie, czyli jakby kierujemy się transparentnością, więc nie mamy tajemnic, możemy pokazać, tylko czy story pointy nie zadziałają trochę jak granat i małpa albo małpa z granatem. W sensie, jeżeli ktoś nie rozumie, co to są story pointy, to sobie zrobi krzywdę. Właśnie zacznie porównywać dwa zespoły między sobą. Ale powiem, że ostatnio, jakby bazując na moich doświadczeniach bardzo świeżych, widzę, że faktycznie to może zrobić wiele krzywdy, story pointy w organizacji. Dlaczego? Bo właśnie zespoły, szczególnie młodzi Scrum Masterzy, młodzi w sensie stażowo, mają ogromny nacisk, żeby te story pointy mieć w backlogu i żeby je zarabiać. Bo kiedy się zarabia story pointy, może jeszcze tego nie powiedzieliśmy, czyli na początku sprintu mówimy to jest nasz zakres, ten zakres funkcjonalności chcemy wdrożyć w produkcie, jego wyceniamy na trzynaście story pointów i kończy się sprint, decydujemy, czy ten zakres jest zrobiony, czy nie, zgodnie z naszym definition of dumb.

Paweł: Definition of dumb, tak.

Maciek: No i zarabiamy te story pointy, no i właśnie mi się wydaje też, jeżeli zespołowi brakuje doświadczenia i w organizacji brakuje doświadczenia, to potem się wszystkim chwalimy patrzcie, w tym sprincie zarobiliśmy trzynaście story point. I teraz, jeżeli te story pointy są źle używane, właśnie są tak pokazywane na lewo i prawo, i zespoły się tym chwalą, a jeszcze warstwa zarządzająca w organizacji zaczyna porównywać między sobą zespoły, pojawia się taka niezdrowa presja, żeby zarabiać te story pointy. Że jakby story pointy są oznaką tego, czy jesteśmy dobrym zespołem. Właśnie, że nasz zespół zarabia pięćdziesiąt, a drugi zarabia trzydzieści i to jest od razu też powiedzmy niewłaściwe, bo dla każdego jeden story point oznacza co innego. Ale co się jeszcze pojawia, to właśnie widzę, że taka presja zarabiania tych story pointów. I teraz, jeżeli jednak zespół kończy sprint i mu się nie udaje kończyć tych funkcjonalności, to co robi zespół, jakby jakie ma techniki oszukiwania samego siebie, robienia takiej kreatywnej księgowości?

Paweł: Chyba to widziałem, rozbicie jednego zadania na część skończoną i część nieskończoną, wycenioną osobno.

Maciek: To jest taka kreatywna księgowość. I mi się wydaje, że tutaj też Deloitte byłby też w tym dobry, żeby wyłapywać takie złe praktyki, jako historycznie firma audytorska, która też szybko potrafi zobaczyć, kiedy coś jest zrobione zgodnie ze sztuką, a kiedy ktoś udaje. Ale to jest pierwsze takie oszukiwanie samego siebie, czyli rozbijanie takiej historyjki na coś skończone i tutaj zarabiam, a tu nieskończone, więc nie zarabiam.

Paweł: Ale nic nie wdrożę.

Maciek: Tak, ale i tak nic nie wdrożę. Drugą widziałem taką sytuację, jak zespół siebie oszukiwał, że była historyjka, ale wyceny w story pointach nie były na poziomie historyjki, czyli to nie była wycena, co szła od całego zespołu, czyli cały zespół musiał porozmawiać, żeby powiedzieć, a ta historyjka to jest trzynaście i my, jako cały zespół tak uważamy, tylko zespół mówił, no nie, na poziomie historyjki nie mamy wyceny, tylko potem na poziomie tasków, czyli tak, zrobić makietę pięć, zrobić front osiem, zrobić back trzynaście, no i suma dopiero nam daje jakąś tam kwotę. No i ktoś by się zapytał, jaka jest różnica? No właśnie taka różnica, że tak wyceniając per taski, po pierwsze ugruntowujemy silosy w naszym zespole. Jakby nasz zespół nagle składa się z designerów, z frontów, backów i testerów. Każdy sobie wycenia i każdy zalicza sobie te taski i punkty, jak zrobi swoją część. I na końcu się może okazać, że designerzy, fronci, backowie zrobili swoje, testerzy nie zrobili, no ale zarobiliśmy trzydzieści punktów czy tam ileś, bo tamci zrobili, ale nic nie wydaliśmy na produkcję.

Paweł: A testerom po premii.

Maciek: Na przykład, jakby to oni tutaj nie dają rady, nie podążają za naszym tempem. Widziałem właśnie taki sposób poszukiwania tej miary, to znaczy właśnie, że wyceniamy per taski. Drugi, też dość popularny sposób oszukiwania samego siebie, to jest zmiękczamy definition of done. Znaczy chcemy koniecznie zaliczać te punkty, więc już na przykład z definition of done nam znika, że dana funkcjonalność, na przykład musi przejść testy na jakimś preprodzie albo testy UAT. Bo to już jest za ciężko, bo tak to byśmy musieli tą historyjkę ciągnąć przez tam pięć, dziesięć sprintów. Więc niech to zniknie, to kryterium, z definition of done i dzięki temu będziemy sobie co sprint zaliczać. I ostatnio, no naprawdę aż byłem zdziwiony, widziałem zespół, który już przeżył ze sobą dziesięć sprintów. Z mojego doświadczenia po pięciu sprintach już powinna się ustabilizować ta wydajność zespołu, mierzona może w tych story pointach, takie velocity zespołu po pięciu, a tu po dziesięciu się spodziewałem, że to już będzie naprawdę doświadczony zespół. Spojrzałem właśnie na ten wykres takiego velocity chart, czyli taki wykres, który pokazuje w każdym sprincie ile tych punktów zarobiliśmy. To była taka ustabilizowana liczba, więc się spodziewałem bardzo dobrego zespołu, tak na pierwszy rzut oka. Ale jak wszedłem właśnie w backlog tego zespołu, zacząłem uczestniczyć w refinement’ach, w planing’ach, w review to zrozumiałem, że ten zespół świetnie się nauczył źle wykorzystywać tą miarę. On miał zaliczane te punkty, to velocity było stabilne, jakby kwota tego, co deklarowali, że dowiozą, a tego, co dowozili, była zbliżona, czyli to też jest dobra oznaka, tak? Deklaruję, że dowiozę sto, dowiozłem dziewięćdziesiąt, super. Po prostu tak Scrum Master z całym zespołem się nauczyli. Jak im powiedziałem w pewnym momencie słuchajcie, wy stłukliście termometr i dalej mierzycie temperaturę swojego ciała i się cieszycie, że nie macie gorączki. Ale macie popsuty termometr, więc nie wiecie tak naprawdę, na czym stoicie.

Paweł: Tutaj zapraszam do odcinka, który nagrywaliśmy z Olą Korzunowicz, na temat tego, że pracownicy szybko się uczą dostarczać to, co jest mierzone. Więc jeżeli story pointy wychodzą poza zespół, zespół się, jak widać, szybko uczy, tak?

Maciek: No tak, więc tak jak mówię, to jest troszeczkę małpa z granatem, te story pointy. Ale to jedno, że zespół może sam siebie oszukiwać. Tak, widziałem jak story pointy były źle wykorzystywane i to też mi się wydaje, że dużo zespołów właśnie zaczyna mechanicznie stosować kilka technik, praktyk scrum’owych, właśnie story pointy, backlogi, user story i tak dalej, a traci tego ducha. To znaczy oni mają jakby takie ciśnienie na ten sukces, żeby dowozić, kończyć i się boją na przykład skończyć sprint i nie dowieść żadnego story pointa. Boją się. Ale z tego moim zdaniem jest największa nauka, to znaczy największa wartość. Znaczy kończę sprint, nic nie dowiozłem, bo mam twarde definition of done, nie oszukuję sam siebie, ale wtedy, jak nie dowiozłem, to wyciągam wnioski, dlaczego nie dowiozłem, czego mi brakuje, może kompetencji, może środowisk, może jakichś pomysłów, może warsztatów, ale wtedy realnie rozmawiam o moich wąskich gardłach niż tworzę sytuację, w której pozornie wydaje się, że wszystko hula, okej, no i zatracam też tą wartość płynącą ze story pointów, no i teraz, no trzeba byłoby wymyślić nową miarę. To by były fake story point i real story point może?

Paweł: No dobra, to są story pointy. Myślę, że możemy się zgodzić, co do stwierdzenia, że powinny być mierzone na poziomie zespołu, są wartością dla zespołu i myślę, że możemy się też zgodzić, że nie powinny wychodzić poza zespół. Ale Maciek, to w takim razie, czym można mierzyć wydajność zespołu Scrum’owego? Zarząd, management chcą wiedzieć, czy ich zespoły pracują wydajnie, jak mogą to zmierzyć?

Maciek: No właśnie, sobie tak strzeliliśmy w kolano, bo na początku powiedzieliśmy, że trzeba mierzyć, potem powiedzieliśmy, czym nie mierzyć, no i teraz wypadałoby powiedzieć, jak mierzyć. Znaczy jeszcze jedno ze story pointami, jeszcze powiem, też widziałem bardzo patologiczną sytuację, gdzie story pointy były użyte do rozliczeń z dostawcami. To znaczy, że firma kontraktowała deweloperów, body leasing, powiedzmy mamy jakiś bank i on kontraktuje deweloperów z firmy body leasingowej, i to ile płaci za tych deweloperów zależy od tego ile ci deweloperzy dowiozą story pointów. To jest kolejne wypaczenie w ogóle tego pomysłu na story pointy, więc tylko tak na marginesie o tym wspominam, żeby unikać tej sytuacji, bo zabieramy fajną miarę, jaką są story pointy, ale zabieramy ją zespołowi, a oddajemy ją zakupowcom, prawnikom, wszystkim, którzy są związani z negocjacją techników. No to teraz, jak mierzyć.

Paweł: Chyba odpowiedzią będzie to zależy, tak?

Maciek: Nie lubię tej odpowiedzi, bo ona mało daje drugiej stronie. Też się zastanawiam na ile też jest faktycznie w takim duchu Agile’owym, że może po prostu cokolwiek zaproponujmy, sprawdźmy, czy to działa, a dopiero się zastanawiajmy nad głębszym sensem.

Paweł: To bym chyba w takim razie wrócił do sensu samej zwinności, do jak najszybszego dostarczania, odpowiadania na potrzeby użytkownika, dostarczania wartości użytkownikowi, klientowi końcowemu, czyli odbiorcy naszego produktu. I jeżeli tak na to spojrzymy, to to, co powinniśmy mierzyć, to to, czy zespół dostarcza wartość, czy zespół Scrum’owy dostarcza wartość, czy rozwija produkt, czy ten produkt staje się wartościowy coraz bardziej z czasem.

Maciek: Mi też jest bliskie takie myślenie, to jest fajny punkt widzenia. No bo też nie uciekniemy przed tym, że w pewnym momencie pojawi się jakiś Excel i pojawią się jakieś wyliczenia na temat tej efektywności zespołów. W każdej organizacji zarząd w pewnym momencie poprosi, nie wiem, jakieś PMO albo kogoś z controlingu, kogoś, kto szybko liczy, policzcie mi jakieś wskaźniki dla tych zespołów. Więc te wskaźniki się pojawią. Więc do tej pory chyba, co rozmawialiśmy, to radzimy, żeby unikać, żeby w tych wskaźnikach się znalazły story pointy. Teraz, co się powinno pojawić w tych wskaźnikach. Z mojego doświadczenia wskaźniki zazwyczaj mają licznik i mianownik. Znaczy porównujemy, to, co powiedziałem, jakąś wartość w stosunku do czegoś. I teraz może też podzielmy tą rozmowę. Teraz, jak wartość, czyli ten licznik, co tworzymy dla klienta albo dla organizacji, to jest bardzo ciężki temat, to może też go zostawmy troszeczkę na chwilę na bok. Mianownik jest troszeczkę łatwiejszym tematem, bo w mianowniku zazwyczaj są koszty. Jakby mam zespół, więc to, co powinienem zacząć zbierać i nieraz się dziwię, że niektóre firmy tego nie track’ują, nie monitorują, no to są po prostu koszty zespołów. W tym mianowniku powinniśmy mieć ile płacimy za to, że ten zespół istnieje. I to są takie koszty związane z wynagrodzeniem tych osób, z pensjami albo jeżeli kupujemy na body leasing, to faktury za dane osoby. Mi się wydaje, że tutaj dobrą praktyką w ogóle jest, że jak firma korzysta z takich systemów do zarządzania backlogiem jak Jira, żeby po prostu członkowie zespołów raportowali swoje godziny per user story na przykład. I wtedy kończy się miesiąc i ja wiem dokładnie, że te user story pochłonęły tyle dniówek, a te user story tyle dniówek, a cały zespół mnie kosztował tyle dniówek. Więc te koszty osobowe mi się wydaje, że to jest dość stosunkowo łatwo mierzyć i od tego firmy powinny zacząć. Ja naprawdę się dziwię, jak widzę, że firmy jeszcze tego nie robią. To jest taki quick win. Oczywiście można szukać problemów, że nasza Jira jest taka czy inna albo, że deweloperom się nie chce, albo jeszcze też taki słyszałem argument, no ale przecież ile czasu będzie trwało raportowanie. No i praktyka jest taka, że jeżeli nawet codziennie byśmy mieli raportować per user story, to w sumie pewnie by nam to zajęło dwie minuty, więc to nie jest dużo czasu za to, że mamy te dane. To są te koszty osobowe, no i potem są jeszcze te koszty związane z narzędziami, systemami, środowiskami deweloperskimi i innymi. No to to już też trzeba inaczej pomyśleć, jak to robić, nauczyć się, jak prowadzić proces, który alokuje te koszty na jakieś centrum kosztów danego zespołu. Tutaj pojawia się pytanie, czym jest centrum kosztów per zespół czy per jakieś portfolio projektów.

Paweł: Myślę, że to dobry temat na kolejny odcinek.

Maciek: Tak, to w to nie wchodźmy, ale mi się wydaje, że ten mianownik, czyli te koszty, to to jest coś, od czego powinniśmy zacząć. Mieć koszty mojego zespołu. Co myślisz o tym, Pawle?

Paweł: Myślę, że koszty jak najbardziej, tylko chyba nie powinniśmy się na nich fiksować, to jest dobre słowo, bo to ta wartość jest dużo ważniejsza.

Maciek: Tak, ja może tak te koszty podkreślam, no bo to moim zdaniem jest quick win, to można szybko uzyskać i też moim zdaniem to też fajnie buduje świadomość product ownera. To znaczy, jakiego chcemy mieć product ownera w organizacji? Każda firma tworzy swoją kartę product ownera, taki opis tej roli, jakich ja chcę mieć product ownerów, czy to są osoby na grade trzynastym, dwudziestym czy dwudziestym drugim, nie wiem, takich jeszcze nie widziałem, ale jakby jak są wysoko w hierarchii, jak dobrze są opłacani, ale mi się wydaje, co jest wspólne, to chcemy, żeby product ownerzy byli przedsiębiorcami. Jakby żeby oni mieli też taką świadomość ile wydają codziennie pieniędzy, to znaczy ile każdy dzień kosztuje organizację, każdy dzień mojego zespołu. Więc jeżeli jest ta świadomość dotycząca kosztów, to product owner mam nadzieję, że wtedy rozsądniej decyduje, czym ten zespół ma się zajmować. No bo jeżeli ja wiem, że wstaję rano i dzisiaj na pewno wydam dziesięć tysięcy złotych, jakby tyle będzie mój zespół kosztował, to ja zastanowię się dwa razy, czy ten zespół ma iść na taki warsztat, na inny warsztat, czy ma się zajmować tą funkcjonalnością, czy inną. Więc jeżeli chcemy mieć product ownera przedsiębiorcę, powinien on mieć te dane dotyczące spalania budżetu przez jego zespół. To od razu jeżelibyśmy poszli tym tropem, to troszeczkę wyklucza takie patologiczne sytuacje, gdzie w organizacji jest product owner, a obok niego jest jakiś PM, który się uchował i ten PM zarządza budżetem, a ty, product ownerze, zarządzaj tylko Jirą, tak? To jest troszeczkę ciężko pogodzić. To to są te koszty. No i chyba już się nie da dalej uciekać od tej wartości, tak?

Paweł: Jeżeli chodzi o samą wartość, to ta wartość dla każdego produktu jest zdefiniowana inaczej. To, co chyba chciałbym na samym początku zaznaczyć, to to, że zespół dostarcza wartość produktu, co oznacza, że dosyć trudno jest zmierzyć wydajność poszczególnych członków zespołu. To znaczy w zwinności chyba dobrze byłoby uciec od takich miar typowo output’owych, tylko patrzeć, jaki faktycznie zespoły daje efekt, jaki jest outcome ich pracy. Dlatego taką miarą wartości na przykład chociażby przychód, przychód z konkretnego produktu, przychód dzielony na jednego pracownika, jakiś bardzo relatywny, chociażby przychód do kosztów. To jest jakaś miara, którą myślę, że jesteśmy w stanie określić, czy faktycznie pracujemy wydajnie, czy wydajnie dostarczamy wydajność.

Maciek: No tak, tylko żeby zastosować to podejście, to może warto jakbyśmy rozróżnili dwa typy zespołów. Jeden typ to są te zespoły, które mają aktualnie swoje produkty i te produkty stanowią źródła przychodów, i ich zadaniem jest podnosić rentowność tych produktów albo podnosić te przychody, ale oni już zarabiają na tych produktach. I mi się wydaje, że wtedy jest możliwe i też ma sens właśnie, żeby w tym liczniku wpisać przychody, które wygenerowały produkty tego zespołu, w mianowniku trzymać koszty tego zespołu i patrzeć, jak ten stosunek się zmienia. Nie wiem, czy byłbym skłonny liczyć to per osoba, bo to też by wskazywałoby kusiło, żeby znów patrzeć też przez pryzmat jakichś silosów poszczególnych osób.

Paweł: Podałem ten przykład, jako próba takiej normalizacji na całą organizację, niekoniecznie per osoba w zespole, tylko raczej per jeden pracownik całej organizacji.

Maciek: No tak, ale tutaj mówimy o zespołach. Mi się wydaje, że to mogłoby tak zagrać, że mamy zespół, on ma przypisane produkty, którymi się opiekuje i ten produkt to może być, nie wiem, ubezpieczenie, to może być kredyt bankowy, to może być jakiś tam element naszego e-commerce’a, który ten zespół rozwija. Jeżeli do produktu jesteśmy w stanie przypisać konkretne przychody, no to też te przychody jesteśmy w stanie przypisać do zespołu. Możemy w czasie patrzeć, czy te przychody w stosunku do kosztów, ta relacja jest coraz lepsza czy coraz gorsza. A drugi rodzaj zespołów, które stanowią inny rodzaj wyzwania, to są zespoły, które nie mają swoich aktualnie produktów. Jakby zostały powołane, żeby dopiero je rozwijać. Albo też nie mają takich wprost przychodów, bo są bardziej, nie wiem, back office’owe na przykład. Więc idealna jest okazja, gdzie są te przychody i jest taki rachunek zysku i strat, że tak powiem, na poziomie zespołu są te przychody i koszty i do nich się możemy odnosić, ale jeżeli jej nie ma, to moim zdaniem jest taki pomysł, który jest adekwatny dla tego i tego typu zespołów.

Paweł: I jest to?

Maciek: I jest to chyba, co rozmawiałeś już w poprzednim odcinku z Olą, to właśnie wyznaczanie celów, na przykład takich OKR-ów kwartalnych na przykład. Czyli tą wartość, jaką chcemy, żeby zespół wygenerował określamy poprzez na przykład te OKR-y, czyli w rozwinięciu objective and key results, gdzie wyznaczamy sobie jakąś miarę, na przykład liczymy, że zespół w następnym kwartale stworzy portal, za kwartał powstanie portal, który będzie miał dziesięć tysięcy użytkowników na przykład dziennie. I to jest moim zdaniem taki fajny pomysł, że co kwartał mogę inny wyznaczać ten cel, który musi osiągnąć zespół. Czyli to jest ten licznik, to jest ta wartość, którą on generuje i w zależności tego, czy on osiąga, czy nie albo, w jakim stopniu osiąga i czy OKR-y jeszcze nam pozwalają mieć taką płynną skalę. To znaczy, tak jak w KPI, zazwyczaj jest to tak robione, że wyznaczam sobie KPI, na przykład KPI to masz sprzedać sto, jak sprzedałeś sto, to super, dostajesz bonus, a OKR-y mówią masz sprzedać sto dwadzieścia, a jak sprzedałeś sto, to też jest super, mimo że go niby nie osiągnąłeś, ale to są takie bardziej ambitne i wygórowane troszkę. No i te OKR-y moim zdaniem mogą stanowić ten licznik dla zespołu, czyli co kwartał jest inny cel do osiągnięcia. I na tej podstawie mierzymy tą wartość. W jednym kwartale to może być właśnie w ogóle zbudowanie tej platformy, jeżeli to jest początkujący zespół, jeszcze nie ma produktów, jeżeli już ma produkty, to to mogą być właśnie bardziej rzeczy związane z przychodami na przykład. Co o tym myślisz?

Paweł: No powiem Ci, że zastanawiałem się, czy dopłyniemy dzisiaj do OKR-ów i faktycznie tutaj wylądowaliśmy. Chyba bym tutaj nadmienił jakby o samej różnicy, bo powiedziałeś KPI i powiedziałeś OKR-y. W OKR-ach jest key result. Czym się różni key result od KPI?

Maciek: Znaczy wiesz, no w ogóle temat OKR-ów to możemy jeszcze zrobić osobny podcast, bo teraz też wspieramy jedną z firm we wdrożeniu OKR-ów i tak naprawdę ta część KR, key result, jakby w tej części można umieszczać KPI firmy i to jest w ogóle dobrą praktyką, żeby przy wyznaczaniu tych key results na początku spojrzeć, jakie mamy KPI. Ale równie dobrze zamiast KPI tam mogą być inne miary, których do tej pory stosowaliśmy, jako KPI. Ogólnie ja widzę takie trzy różnice między OKR-ami a KPI. Pierwsza właśnie, że KPI bardziej dotyczyły dłuższego horyzontu, zazwyczaj, jakby, co rok były rozliczane, na przykład szczególnie to jest bolesne dla funkcji IT. Bo tak jak w sprzedaży jesteśmy przyzwyczajeni, że co miesiąc porównujemy nasze wyniki do targetów, tak? Chcieliśmy sprzedać sto, sprzedaliśmy sto dziesięć, super, brawo, mamy sukces. To w IT taki okres rozliczeniowy to był zazwyczaj rok. To znaczy IT ma jakiś budżet na rok, KPI w stylu stabilność systemu na rok i często, to też rozmawiałem z jednym CEO, który mówił, no to była nieraz tak dziwna sytuacja, że kończył się rok w grudniu, a my dopiero w maju robiliśmy podsumowanie tamtego roku i w maju świętowaliśmy osiągnięcie KPI z grudnia, gdzie sprzedaż sobie co roku świętuje, więc to też wpływało na jakaś motywację. Więc KPI od OKR-ów właśnie różnią się tym, że mają krótszy okres rozliczeniowy. Drugie, że są ambitniejsze. To właśnie to, co wcześniej powiedziałem, że KPI, jakby sukces jest wtedy, jak osiągniesz tą wartość. A OKR-y były wyznaczane trochę więcej niż… znaczy wydaje nam się, że jesteśmy w stanie osiągnąć, ale potem, jak już mamy ten wynik, na przykład chcieliśmy osiągnąć sto dwadzieścia, osiągnęliśmy sto i się zastanawiamy, czy to już jest good enough, czy jest, co świętować, czy nie, ale pozwala nas tak popychać powyżej potencjalnie naszych możliwości, co jest takie moim zdaniem motywujące. I trzeci aspekt, że OKR-y są takie bardzo data driven, to znaczy musi być ten aspekt key result, jak ty zmierzysz, że osiągnąłeś dany cel.

Paweł: Dla mnie taką chyba różnicą, którą często też widziałem w samej praktyce, jest to, że KPI właśnie mierzyły out put. Na przykład, bardzo prosty przykład w call center, takim KPI byłaby ilość wykonanych telefonów, średni czas trwania rozmowy, czyli jakiś out put. A key result bardzo często mierzą właśnie ten out come, co my zyskaliśmy, jako organizacja dzięki tym wykonanym telefonom, ile było sprzedaży chociażby. Więc to byłaby taka bardzo różnica, która dla mnie zawsze była widoczna, jeżeli chodzi o KPI versus key result.

Maciek: No tak, jeden temat chyba, czyli te OKR-y mogą nam pomóc, żeby zacząć coś mierzyć. I mi się wydaje, że to też jest o tyle ciekawe, że ta miara, którą chcemy narzucić na zespół, jest możliwa, ale na początku nasi sponsorzy, nasz zarząd czy liderzy w organizacji też muszą wykonać pracę domową, to znaczy wyznaczyć sobie swoje na przykład OKR-y albo swoje miary strategiczne, swoje KPI i powiedzieć wiecie, w moim obszarze najważniejsze właśnie, nie wiem, jest sprzedaż albo liczba procesów na pracownika, albo NPS klienta i ja chciałbym przejść z tego poziomu na ten poziom. I to jest taka sytuacja, bo nieraz widzę, że właśnie jest takie wymuszanie na zespołach, jak chcecie się mierzyć, a zespoły mówią, no ale jakie mamy cele, to wy najpierw powiedzcie, jakie mamy cele, co mamy osiągnąć. No mamy być świetną firmą, wspaniałą, innowacyjną, no to to jest mało mierzalne, tak? Więc na początku liderzy, sponsorzy powinni wykonać swoją pracę domową i powiedzieć to są nasze miary. Co więcej, mi się wydaje, że to nie powinno być takie trudne zadanie, tak? Bo oni odpowiadają za strategię firmy. Powinni mieć takie czucie tych miar, ale też często trzeba wiedzieć, że liderzy organizacji też mają osobiście swoje cele wyznaczane przez właścicieli firmy. Wprost metryki, od których zależy ocena takiego poszczególnego członka zarządu, więc można też transparentnie się podzielić, że słuchajcie, jakby mnie właściciele rozliczają z takich miar, pomóżcie mi zrealizować te miary na przykład. Więc mi się wydaje, że tak jakby OKR-y to jest jeden temat, jak możemy podejść do mierzenie tej wartości albo oceny efektywności zespołu. Jak jeszcze możemy inaczej podejść, to to, co powiedziałem, że nieraz organizacja pyta zespoły, a jak wy byście chcieli się mierzyć, i to też jest ciekawe. Mi się wydaje, że też tak można do tego podejść. Czyli nie narzucać na zespoły, tylko po prostu powiedzieć słuchajcie, chcemy was jakoś zmierzyć, chcemy patrzeć, czy wam idzie dobrze, czy źle, jakie wy macie propozycje.

Paweł: Tak, chyba najciekawszy przykład, o którym słyszeliśmy, to mierzenie liczby uśmiechów w ciągu dnia w samym zespole, nie?

Maciek: Wiesz, pewnie trochę mnie już znasz, ja akurat nie wierzę w takie tematy, bo potem okej, to potem będziemy też pracownikom płacić w uśmiechach. Jakby na swoim koncie zamiast tam jakiejś kwoty, to zobaczą po prostu mail, w którym będzie milion zdjęć uśmiechów.

Paweł: Emotikonek.

Maciek: Jakby i od tej pory zarabiasz milion uśmiechów, okej, jak chcesz, to możesz albo zarabiać milion uśmiechów, albo jakąś kwotę w złotówkach, no to jak wolisz. Nie wiem, nie wiem, czy dużo osób by się na to zgodziło, ale ogólnie zapytanie zespołów. Moim zdaniem tylko też to chodzi o to, że zespoły też czują, co są w stanie zrobić, to też takie ćwiczenie daje takie empowerment dla zespołów, to wy zaproponujcie jakąś miarę. Na końcu i tak organizacja będzie musiała się przyjrzeć tym propozycjom, nie może w ciemno wziąć, no bo faktycznie może się skończyć na liczbie uśmiechów, a to jest krótka droga do bankructwa firmy, znaczy chyba że gospodarka się opiera na uśmiechach, ale to już chyba były o tym książki, nowy, wspaniały świat, różne substancje, co powodowały, że ludzie cały czas mieli uśmiech na twarzy. Soma chyba się nazywała ta substancja. Ale to było coś w okolicach narkotyków, więc chyba nie chcemy iść...

Paweł: To jest trochę poza tematyką tego podcastu.

Maciek: Tak mi się wydaje. Ale to jest fajne ćwiczenie, żeby zobaczyć, jak świadome są zespoły, co chciałyby mierzyć i to też moim zdaniem jest w duchu Agile’owym, wyjdźmy od tego. Tylko też uważajmy. Pułapkę, którą ja po prostu widzę też wśród mało doświadczonych Scrum Masterów albo raczej coachy, to jest właśnie o wszystko pytamy zespoły. Jakby zespół niech zdecyduje, czy chce mieć backlog, czy nie chce mieć backlogu, czy chce mieć user story, czy nie chce mieć, czy chce mieć takie definition of done, czy nie, czy chce tak wyceniać w story pointach, czy nie, czy historyjka ma być technologiczna, czy z perspektywy użytkownika. Znaczy niektórzy mówią zapytajmy zespołu, a co myśli zespół, to jest decyzja zespołu, to jest taki empowerment, taka samoorganizacja i to ma działać. Moim zdaniem to nie jest tak do końca. To znaczy są osoby, które po prostu dopiero zaczynają pracować w jakimś modelu i jeżeli będziemy im oddawać tą decyzyjność i pozwalać, żeby oni się kierowali swoją intuicją, to mogą po prostu się sparzyć. Jakby okej, można powiedzieć, że z tego sparzenia wyciągną wnioski. Może wyciągną, może nie. A może wymyślą sobie model, system, który będzie nieefektywny i z miesiąca na miesiąc tym bardziej będą go ugruntowywać, i potem będzie ciężko wyjść z takich złych praktyk.

Paweł: Czyli to, co mówisz, to to, żeby dopasować jakby, czy to będzie coaching, mentoring, szkolenie do dojrzałości zespołu, tak?

Maciek: Znaczy wiesz, tak, ale też chodzi o pewną stanowczość Scrum Masterów i Agile Coachy. Troszeczkę jest tak, że jak ja nie przykładałem dużej uwagi do tego, jak moja córka sprząta zabawki w swoim pokoju.

Paweł: Pozwalałeś jej decydować.

Maciek: Po prostu nie przykładałem wagi. Nie wiem, czy nie miałem czasu, czy ignorowałem to i tak odkąd skończyła powiedzmy cztery latka, gdzie już mogła sama po sobie sprzątać, w sumie często było tak, że ja za nią sprzątałem albo moja żona sprzątała. Teraz ma siedem i naprawdę mam wielki problem z tym, żeby jednak pokazać jakby, że powinna sprzątać po sobie, jakby, że to jest dobra praktyka, że to nie jest kwestia wyboru nieraz, to jest kwestia szanowania swoich zabawek, dbania o porządek, niszczenia rzeczy, ale też dbania o taki komfort przebywania w pomieszczeniu. Ciężko mi jest teraz właśnie wprowadzić tą zasadę. Teraz mój synek dopiero ma dwa latka i już zaczynam go uczyć tego, że trzeba składać zabawki po sobie i mu to, póki co, łatwo przychodzi. I mam nadzieję, że jak będzie miał siedem lat, to już będzie miał to we krwi jakby, to będzie wpojone i to będzie z pożytkiem dla całej rodziny. I mi się wydaje, że podobnie jest z zespołami Scrum’owymi. Nieraz trzeba być stanowczym, bo po prostu to wynika z mojego doświadczenia, to wynika z tego, że widziałem wiele zespołów. To też może troszeczkę różni… nie chcę wchodzić, czym się różni Scrum Master od Agile Coacha, według mnie niczym, tylko tak to jest po prostu przyjęte, że może te osoby bardziej doświadczone nazywamy Agile Coachem, ale właśnie taki dobry Scrum Master czy Agile Coach, gdy widział dziesięć różnych zespołów i odniósł kilka porażek jakby w pracy z tymi zespołami, to teraz już wie, kiedy nie może odpuścić albo jeżeli odpuszcza, to trzeba pokazać wszystkie konsekwencje jakichś wyborów tego zespołu. Więc zespół może sam wybrać, jest to jakaś tam propozycja tego. Ale jest jeszcze jedna miara, o której chciałem porozmawiać i Cię zapytać o zdanie, co myślisz, bo firmy zazwyczaj zaczynają transformacje zwinne z trzech powodów, tak jak ja obserwuję. Pierwszy powód to jest na przykład ograniczenie kosztów. Firma po prostu czuje, że nie ma optymalnej struktury w organizacji, na przykład jest przerośnięty middle management albo brakuje jakichś kompetencji, więc chce jeszcze raz zrobić taki size’ing zespołów, kogo potrzebujemy, jakich kompetencji potrzebujemy, żeby tworzyć wartość. Czyli ograniczenie kosztów to jest jeden z powodów. Drugi powód, jaki obserwuję, to jest portfolio management, czyli firma zaczyna już się gubić w tym, jakie robi inicjatywy, które finansuje, które idą dobrze, jak wygląda ten pipeline pomysłów, jak on dorasta.

Paweł: Które faktycznie coś przyniosły.

Maciek: Które coś przyniosły, jakie mamy zwroty, jakie są koszty opóźnień pewne, ten cost of delay i tak dalej, i tak dalej. To jest drugi powód. A trzeci to jest, no już taki wyświechtany time to market, jakby czyli ile nam zajmuje jako organizacji wdrożenie jakiegoś nowego pomysłu, jakiejś koncepcji. Czyli od momentu, jak jakiś pomysł pojawia się w głowie kogoś, do momentu, jak pierwszy raz klient z tego korzysta, ile mija. I firmy chcą to ograniczyć. I tak się zastanawiam, czy nie można by było też mierzyć zespołu w oparciu o tą koncepcję. Czyli chcemy mierzyć, jak szybko zespół jest w stanie wdrażać zmiany. Od momentu pojawienia się w głowie do momentu, jak pierwszy raz klient klika na środowisku tym produkcyjnym.

Paweł: No wtedy w sumie, w kontrze do tego, co mówiliśmy wcześniej co do samej przychodowości danego produktu czy zespołu, to mierzymy to, jak zespół szybko jest w szybko zweryfikować każdy z pomysłów, tak?

Maciek: No jest.

Paweł: Czyli znowu też nawiązujemy do pewnej takiej podwaliny samej zwinności, weryfikacja, nawet jeśli on nie przyniesie przychodu, ale dosyć szybko, w dwa tygodnie, w miesiąc go zweryfikowaliśmy.

Maciek: No dokładnie. Ale też ta miara mi się wydaje, by pokazywała te możliwości, czyli ten właśnie test and learn, back and adapt, czyli ile u nas trwa ten loop feedbackowania, ten okres właśnie, w jakim coś tworzymy, a potem wyciągamy z tego wnioski i chcemy częściej to robić, takie testowanie, tak powszechnie mówiąc. A jeżeli ten okres jest długi, to też trochę pokazuje, albo nie trochę, albo bardzo, jakie mamy impedimenty, właśnie jakie mamy realne wyzwania w organizacji. I jeżeli na przykład ktoś by powiedział, no u nas taki time to market na przykład jest siedem miesięcy. A dlaczego? No bo na przykład same testy na końcu, takie systemowo-integracyjne, trwają miesiąc. No i w ogóle nagle się pojawia pytanie, jak to testy na końcu, dlaczego nie testujecie w ramach sprintu. No bo nie mamy tych kompetencji, jakby u nas testy synchroniczne są robione gdzieś na zewnątrz. A dlaczego one są wyciągnięte? Bo tak zawsze było. To jest jeden powód. Drugi, bo nie mamy tylu środowisk, bo nie mamy narzędzi. Czyli to jest na końcu jakby tego procesu wytwórczego, a może na początku. Wiesz, z tych siedmiu miesięcy pierwsze trzy miesiące spalamy na robienie business case’ów, peachowanie o budżety, akceptacje i tak dalej, i tak dalej. To czy to faktycznie musi tyle trwać? Więc zaczynamy rozmawiać o realnym przepływie wartości, ile on trwa na poszczególnych etapach i gdzie są te wąskie gardła. Jeżeli my chcemy być zwinną firmą, to my właśnie powinniśmy… dla mnie zwinność to jest ten krótki time to market. To jest moim zdaniem taka najbardziej obiektywna miara. Problem tylko polega na tym, że nieraz idę do jakiegoś zespołu na coaching, to się pytam, jaki macie time to market i dostaję odpowiedź dwa tygodnie. Bo zespół po swojemu to mierzy, ma swoje takie jakby definition of done, znaczy dla nich to trwa dwa tygodnie, bo u nich proces wytwórczy zaczyna się w momencie, jak już biznes przygotuje koncepcję, już jest biznes na początku nie wiadomo ile, nie wiem, pięć miesięcy, zdobył finansowanie, opisał, dał specyfikację.

Paweł: Business case, designy.

Maciek: Tak.

Paweł: Wszystko jest.

Maciek: I potem… dokładnie. Potem dopiero przychodzi z takim wkładem, tym inputem, do zespołu, bo zespół niby jest Scrum’owy, tak się uważa, ale on tak naprawdę robi tylko część procesu wytwórczego, on potem już to ładnie w systemie koduje i oddaje do testów, których też nie robi. Więc dla nich to jest dwa tygodnie nigdy. Ale z perspektywy Kowalskiego to trwało siedem miesięcy. Więc też moim zdaniem jest takim wyzwaniem dla firmy wystandaryzowanie tego, co rozumiemy przez time to market, od kiedy, do kiedy to mierzymy i to trwa, i potem taka miara by była ciekawa. I ja tą miarą byłbym w stanie porównywać zespoły. Bo niektóre zespoły są sprytne i poradziły sobie właśnie ze skracaniem tego okresu, może automatyzacja testów, może tutaj product ownerzy szybciej zdobywają dofinansowanie, może designerzy szybciej robią makiety, może zespół, jako zespół, abstrahując czy jest Agile’owy, czy nie, jest zespołem, który lepiej funkcjonuje, więc jest szybszy i na przykład ich można wtedy doceniać, tak? Jakby bardziej niż zespoły, które po prostu przychodzą do pracy z dnia na dzień i nie mają pomysłu, jak usprawniać swój proces. Jedno, co jeszcze bym podpowiedział, co też mi się wydaje fajnie zdaje egzamin, to jeżeli to track’ujemy, to na początku rozrysujmy sobie w organizacjach, jak to faktycznie dzisiaj wygląda. Jak wiesz, my robimy często to ćwiczenie value-stream mapping.

Paweł: Dokładnie.

Maciek: Co dokładnie to pokazuje, tylko że wystandaryzujmy, że róbmy to na przykład dla zmiany, której budżet był większy niż na przykład milion złotych. Postawmy sobie okej, to my przebadamy ileś tam zespołów, rozrysujemy ten time to market, ale myślmy tylko o projektach, o zmianach powyżej miliona złotych. Żeby nie było takiej sytuacji, że przeanalizujemy to na przykład dla jakiejś małej zmiany, ten przysłowiowy jeden przycisk na froncie, temat mały. A kwota milion złotych nie jest przypadkowa, no bo to już jest taka kwota, która wymaga pracy całego zespołu przez kilka miesięcy, więc już można z tego wyciągać wnioski.

Paweł: Maciek, to jak możemy to wszystko, o czym dzisiaj rozmawialiśmy podsumować, jak mierzyć wydajność zespołów Scrum’owych?

Maciek: No to z tego, co rozmawialiśmy, to po pierwsze mierzyć, to jest pierwszy wniosek, mi się wydaje, do którego doszliśmy. Drugi, że nie mierzyć story pointami, bo to jest miara dla zespołu, a nie dla organizacji. Trzeci, że na pewno mierzyć koszty zespołu, bo to jest bezdyskusyjne. Musimy mieć świadomość tych kosztów. Czwarta rzecz, żeby mierzyć wartość dla organizacji, która jest wyrażona celami organizacji strategicznymi, jak KPI strategiczne albo OKR-y. Czwarty to był, to był czwarty A, to czwarty B to można też liczyć time to market zespołu. To znaczy patrzeć, jak on faktycznie jest długi czy krótki, ale na początku wystandaryzować w firmie, co to znaczy time to market dla nas, odkąd dokąd to mierzymy, jakie są etapy dowożenia wartości.

Paweł: Jeżeli temat samego mierzenia jest dla was interesujący, to z jednej strony zapraszam do odcinka podcastu, który był tu już kilka razy wspomniany, z Olą Korzunowicz, a z drugiej strony możecie się do nas po prostu odezwać, znaleźć nas na naszym blogu „Zwinne organizacje” na stronie deloitte.com. Maciek, bardzo dziękuję Ci za dzisiejszą rozmowę, mnóstwo inspiracji.

Maciek: Dziękuje bardzo za zaproszenie, czekam na kolejne. Do usłyszenia wkrótce.

Paweł: Do usłyszenia.

Podsumowanie

1. Warto mierzyć wydajność zespołów Scrumowych

2. Nie mierz wydajności Story Point’ami, bo to miara dla zespołu, a nie organizacji.

3. Mierz koszty zespołu, to ważne, żebyś wiedział, jakim kosztem dla organizacji jest ich praca.

4. Mierz wartość dla organizacji, która jest wyrażona jej celami w postaci KPI strategicznych lub OKR.

5. Licz time-to-market zespołu – czy jest długi, czy krótki. Po wcześniejszym wystandaryzowaniu tego pojęcia dla całej organizacji i określeniu, jakie są etapy dostarczania wartości.

A jak mierzy się wydajność zespołów w Twojej organizacji? Podziel się z nami swoimi doświadczeniami. Jestem ciekaw Twojej opinii. Napisz do mnie ptomkiel@deloittece.com.