Zwinny harmonogram

Dzisiaj tekst o dwóch rzeczach związanych z planami i harmonogramami. Z jednej strony chcemy opowiedzieć o tym, jak budować plany, a z drugiej przestrzec przed ich zbytnią ich szczegółowością.

 

Zwinny plan

Zwinne podejście wcale nie oznacza pójścia na żywioł i pracy bez planu. O harmonogramach mówiliśmy wielokrotnie – czy to przy okazji Planowania Sprintu, czy to przy okazji omawiania wydań, zwanych popularnie releasami. Zarówno jedne, jak i drugie “harmonogramy” są tworzone ad hoc i wynikają z potrzeby chwili. Innymi słowy, są tymczasowe, o krótkim horyzoncie i dostosowane do bieżącej sytuacji w organizacji.

Odwołując się do jednej z 12 zasad zwinnego tworzenia oprogramowania, możemy powiedzieć że harmonogramy Sprintów (tworzone regularnie co dwa tygodnie) czy plany na wydania są realizacją zarówno empiryzmu jak i gotowości na zmianę. Po pierwsze – powstają w odpowiedzi na bieżącą sytuację. Po drugie – dają szansę zmienić kierunek w którym podążamy i dostosować nasza działanie do aktualnych potrzeb.

Chciałbym od razu uspokoić tych, którzy obawiają się, że wiąże się to z nieustanną zmianą podjętych decyzji. Chodzi tu bowiem o nic innego, jak o wybranie z backlogu najbardziej wartościowych elementów w danym momencie. Nie zmieniamy fundamentalnych decyzji, a jedynie wybieramy te elementy, które w danej chwili przyniosą najwięcej korzyści. One już istnieją na naszej liście wymagań. Jeżeli ktoś chciałby poznać więcej szczegółów na ten temat, polecam komentarz w postaci filmu wideo.

A jeżeli już o filmach mowa, to zachęcam także do subskrypcji naszego kanału na YouTube oraz do obejrzenia innego filmu pod tytułem “Metodyka YOLO”. Rozprawiamy się w nim z mitem, jakoby w podejściu zwinnym wszystko było robione na żywioł i bez planu.

My po prostu z góry zakładamy, że plany się dezaktualizują. Dlatego robimy je co chwila. A plany o dłuższym horyzoncie to bardziej dokumenty typu wizja czy strategia. Pokazują nam dokąd chcemy dotrzeć, ale nie w jaki sposób będziemy do tego miejsca podążać. Wiemy gdzie chcemy się znaleźć, ale nie wiemy dokładnie w jaki sposób.

Wiemy też że wiele się w trakcie po naszej podróży może zmienić.

 

Nieelastyczna zwinność

Jest też druga strona medalu pod tytułem “układanie planów”. Niektóre organizacje idą w tym wszystkim zbyt daleko i starają się ułożyć nie tylko harmonogram na trzy lata w przód, ale i każdą jedną minutę pracy w przewidywalne i powtarzalne schematy. Inaczej mówiąc – chcą zaplanować zespołom pracę. A gdzie samoorganizacja?

Pamiętajmy że takie spotkania jak refinement czy Daily Scrum służą zespołom i to one czerpią z nich najwięcej korzyści. Co więcej, tylko zespoły w nich uczestniczą i oni wiedzą ile, kiedy i w jaki sposób powinny się odbywać. Ostrzegaliśmy już przed centralnie sterowaną samoorganizacją i te ostrzeżenie chcemy dzisiaj powtórzyć.

Nie możemy z góry zaplanować refinementów na najbliższe pół roku w przód. Głównie dlatego że “grooming” jest robiony w miarę potrzeb. Im mniej znamy nasz backlog, tym więcej czasu spędzamy na jego poznawaniu. Znaczy to też, że refinement na początku naszej pracy będzie bardziej intensywny, a z upływem czasu stanie się on prawie niezauważalny. Oczywiście, do czasu kiedy pojawi nam się duża porcja nowych wymagań.

Z Daily sytuacja ma się inaczej. Ponieważ jest to spotkanie zespołu (i dla zespołu), nie ma na nim Product Ownera ani Scrum Mastera. Nie jest to też żaden status, tylko planowanie, a jedynymi zainteresowanymi Daily są członkowie zespołu. Skoro więc jest to spotkanie dla nich, to dlaczego mielibyśmy z góry narzucać godzinę i miejsce tego wydarzenia? Przy okazji – wydarzenia, a nie żadnej “ceremonii“. Jeden zespół efektywniej będzie pracował z Daily o 9:00 rano, a inny o 12:30. Jeżeli tak im jest lepiej, powinniśmy im na to pozwolić.

W sumie, dlaczego mielibyśmy kontrolować te działania zespołu, które nie mają negatywnego przełożenia na ich pracę? Jeżeli efekty są dobre, to kogo obchodzi sposób w jaki to zostało osiągnięte albo o której odbywa się daily?

 

Strach przed nieznanym

Niestety, wracamy tutaj do podstawowych problemów, jakie mamy z tworzeniem zwinnych zespołów. Są to stare przyzwyczajenia i brak zaufania. Robimy rzeczy nowe, w związku z czym boimy się że nam nie wyjdzie. Mamy problem z zaufaniem, bo znajdujemy się w nowej sytuacji i nie mamy wcześniejszych doświadczeń bądź mamy je złe.

Szczególnie kierownicy liniowi obawiają się, że w sytuacji w której przestaną przydzielać zadania, ludzie przestaną cokolwiek robić. Podobnie boimy się, że jeżeli nie zorganizujemy zespołom czasu, to będą oni go marnować. Nic bardziej mylnego.

Żeby spełniły się nasze najczarniejsze scenariusze, musielibyśmy założyć że jedynym celem, dla którego ludzie przychodzą do pracy jest zdobycie pieniędzy przy jak najmniejszym wysiłku. Dziś wiemy, że nie jest to prawda. Ludzie przychodzą do pracy głównie po to, aby móc się realizować i rozwijać. Liczą na ciekawe zadania i interesujące wyzwania.

Oczywiście, mówimy to o sytuacji w której ludzie przychodzą do pracy takiej, jaką chcą. Wiadomo że jeżeli sytuacja życiowa zmusza nas do podjęcia pracy, której w innym przypadku absolutnie nie chcielibyśmy wykonywać, to pieniądze będą naszym głównym, o ile nie jedynym, motywatorem. Na szczęście w środowisku, w jakim się obracamy, takie sytuacje są skrajnie rzadkie.

Pozwólmy więc ludziom zdecydować o tym, jak najlepiej mogą wykonywać interesującą dla nich pracę. Jeżeli zdarzy się że robią coś dokładnie odwrotnie niż byśmy sobie tego życzyli, zainterweniujmy. Natomiast wychodzenie z punktu braku zaufania spowoduje że nigdy nie rozwiną skrzydeł i nigdy nie staną się w pełni samoorganizujące.

I tak jak musimy znaleźć balans pomiędzy planowaniem długoterminowym, a gotowością na zmiany, tak samo musimy znaleźć złoty środek pomiędzy organizowaniem zespołom każdej minuty czasu ich pracy, a wolną amerykanką. W pierwszym przypadku odpowiedzią zwykle jest ogólna wizja i szczegółowe, ale bardzo krótkie plany operacyjne (Sprint, wydanie). W przypadku zespołów, w razie wątpliwości powinniśmy opowiadać się po stronie samoorganizacji i zostawienia im wolnej ręki.

Szanse na to, że wyjdzie nam to bokiem są naprawdę minimalne.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: