„No dobrze, ten cały Scrum wygląda jak idealne rozwiązanie dla mojego zespołu. Odpowiedz mi tylko na jedno pytanie – jak ja ich będę kontrolował?”
Zaufanie czy kontrola?
Możemy dowolnie długo mówić o zaufaniu, transparentności i samoorganizacji, ale i tak zawsze raczej prędzej niż później pojawia się pytanie o kontrolę. Nigdy nie wynika ono ze złej woli i z chęci przeszkadzania Zespołom Deweloperskim. Jeżeli jesteśmy żywo zainteresowani rezultatami, to chcemy wiedzieć, co się dzieje po drodze.
Nie każdy ma na tyle zimną krew, żeby w spokoju oczekiwać na finalny efekt pracy. A wymaga to tak naprawdę tylko i wyłącznie jednego: zaufania.
„Kontrola najwyższą formą zaufania.”
Jeśli ufam, że osoba bądź zespół odpowiedzialny za realizację czegoś, na czym nam zależy jest profesjonalistą i podejdzie do sprawy tak dobrze, jak tylko potrafi, to dlaczego miałbym mu patrzeć na ręce?
To nie tak, że w metodykach zwinnych totalnie ignorujemy aspekt kontroli. Zarówno sam zespół kontroluje prace w Sprincie, a Product Owner – postęp realizacji Product Backlogu. Nie dzieje się to jednak w żaden odgórny sposób, który służy do wymierzania kar tym, którzy nie spełniają norm.
Product Owner, Project Manager i przełożony
Istnieją trzy główne role, które mogą chcieć kontrolować postęp prac czy to w ramach Sprintu, czy w szerszym zakresie. Zacznijmy więc od Product Ownera i zajrzyjmy do Scrum Guide’a. Dzięki temu od razu wyjaśnimy dwa z trzech wspomnianych aspektów.
„(…) the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review (…), assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.” – Scrum Guide
link-epic,velo,intere
Z jednej strony Product Owner potrafi zsumować pracę pozostałą do osiągnięcia jakiegoś celu (patrz: Epic). Drugą kwestią jest umiejętność oszacowania orientacyjnego terminu zrealizowania tejże funkcjonalności na podstawie np. velocity zespołu. Te informacje nasz PO udostępnia wszystkim interesariuszom. W tym także Project Managerowi.
Co więcej, Product Owner ściśle współpracuje z Project Managerem. O ile oczywiście takiego mamy. PM występuje w większości organizacji, ale nie jest rola scrumowa. Project Manager zajmuje się przeważenie harmonogramowaniem, budżetowaniem, raportowaniem, wskaźnikami, itd. To brzmi strasznie niescrumowo, nic więc dziwnego, że Podręcznik Scrum w ogóle o takiej roli nie mówi.
Jeżeli jednak już mamy do czynienia z PM-em, to pewnie korzysta on z danych pochodzących od PO, a być może nawet w swoich tabelkach przelicza Story Points na złotówki bądź dolary. I nie będzie w tym nic złego, o ile taka informacja nie będzie docierała do zespołów. Nie chcemy, aby Scrum Team zaprzątał sobie głowę rzeczami niescrumowymi.
No dobrze, a co z naszym przełożonym?
Centralne planowanie
U podstaw agile mindsetu leży założenie, że najlepsze rozwiązania pochodzą od samoorganizujących się i krossfunkcjonalnych zespołów. Dodajmy do tego koncepcję „skin in the game„, która mówi, że tylko jeśli rezultaty naszych działań bezpośrednio nas dotykają, to będziemy starali się nad nimi panować. Wszystko to razem powinno dobitnie unaocznić, że jakiekolwiek „centralne planowanie” czy kontrola nie mają sensu.
Nasz przełożony może mieć najlepsze chęci i rewelacyjne pomysły na raportowanie czasu pracy, śledzenie wydajności, harmonogramowanie zadań i tak dalej, ale bez wymiernych korzyści dla zespołu, będą one tylko kolejnymi obowiązkami. I pozostaje łudzić się, że będą one wykonywane sumiennie. Nic bardziej mylnego.
Jeżeli jestem zmotywowany i wykonuję pracę, która mi się podoba, a także pragnę się rozwijać, to sam będę starał wykonywać swoje zadania efektywnie. Jeżeli przychodzę do pracy za karę, to żadne formy kontroli czy centralnego planowania nic tu nie zmienią. Będę szedł na skróty.
Zwinne zespoły tworzymy wokół zmotywowanych ludzi i kropka. A skoro idziemy w kierunku agile, to pozwólmy im się zorganizować tak, jak tego potrzebują. Zapomnijmy o tym, co nam się wydaje, że będzie dla nich najlepsze. Zarówno pod względem procesu, jak i proponowanych przez nich rozwiązań.
Samoorganizujące się zespoły
Opowiadając o zwinnym podejściu bądź o Scrumie nie da się uniknąć takich słów jak transparentność czy samoorganizacja. Co więcej, czasami powtarzane one będą do znudzenia, aż staną się po prostu „buzzwords”, na które słuchacz nie reaguje. Oddajmy więc głos Scrum Guide’owi w temacie „kontroli zespołów zwinnych”:
„The Development Team tracks (…) total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.” – Scrum Guide
To Zespół Deweloperski śledzi ile pracy pozostało mu w Sprincie i nikomu innemu nie powinno to za bardzo spędzać snu z powiek. Na Planowaniu Sprintu utworzona została prognoza, którą cały zespół uznał za realną. W miarę swoich najlepszych chęci i umiejętności będzie starał się tę prognozę zrealizować. I codzienne pytanie „kiedy to będzie zrobione?” nikomu w tym nie pomoże.
Tutaj przed oczami staje mi sytuacja, w której do programisty poprawiającego krytyczny błąd na środowisku produkcyjnym co chwilę przybiegają osoby odpowiedzialne za wdrożenie, kierownictwo projektu i jeszcze jego bezpośredni przełożony. Czy ktokolwiek o zdrowym rozumie zakłada, że nie czuje on powagi sytuacji albo, że obecność czterech dodatkowych osób stojących mu nad głową cokolwiek zmieni? Przecież próbuje on poprawić to tak szybko, jak się da. Dajmy mu w spokoju pracować!
A co w sytuacji, w której zespół już dziś wie, że któregoś zadania nie ma szans zrealizować w ramach Sprintu? Oczywiście jak najszybciej wspomina o tym Product Ownerowi i wspólnie zastanawiają się, co z tym fantem zrobić i czy jest sens wyrzucać je ze Sprint Backlogu. Być może uda nam się w tym czasie zrobić coś bardziej wartościowego.
I tu dochodzimy do sedna sprawy – Product Owner jak najbardziej o takich rzeczach wie. Ale nie dzieje się to dlatego, że kontroluje on zespół, ale dlatego, że z nim współpracuje. A to już chyba temat na osobny tekst.
