Zapraszam do nietypowego tekstu, z kt贸rego dowiecie si臋 jak robi膰 dobre Sprint Review. A mo偶e nawet dowiecie si臋 po co Wam ta ca艂a zwinno艣膰 i jak nie popa艣膰 w przesad臋, pr贸buj膮c by膰 agile.
Nadmierne komplikowanie wszystkiego
Jaki艣 czas temu z艂apa艂a mnie ochota na powr贸t do podstaw i uproszczenie tego, co ju偶 wiemy. Z niewiadomego powodu wiele organizacji znacz膮co komplikuje 偶ycie sobie i innym, pr贸buj膮c dorabia膰 ideologi臋 praktycznie do wszystkiego, zamiast zaj膮膰 si臋 najwa偶niejszym – swoim celem.
Bardzo trudno rozmawia si臋 z lud藕mi z organizacji projektowych, kt贸rzy przesi膮kn臋li tym specyficznym trybem my艣lenia i dzia艂ania. „Potrzebujemy zrobi膰 projekt, kt贸ry b臋dzie dotyczy艂 konfigurowania i wysy艂ania powiadomie艅 push na kom贸rki i przez strony www!” No dobrze, ale co jest celem? „Wysy艂anie powiadomie艅!” A po co wysy艂amy te powiadomienia? „呕eby zach臋ci膰 ludzi do kupowania w promocjach.” Czyli nie chcemy projektu zwi膮zanego z powiadomieniami, ale chcemy zwi臋kszy膰 sprzeda偶 promocji. Tego typu my艣lenie zosta艂o pokazane na niezliczonej ilo艣ci agile’owych mem贸w i komiks贸w, nie b臋dziemy si臋 powtarza膰.
Organizacje projektowe ka偶d膮 pierdo艂臋 ubieraj膮 w wielkie projekty, kt贸re s膮 rozliczane z ich „dowiezienia”, a nie z rezultat贸w. Nie zastanawiamy si臋 po co co艣 robimy, tylko staramy si臋 robi膰 mocniej, lepiej, szybciej, silniej. A mo偶e rozwi膮zaniem wcale nie jest kolejny projekt, tylko zmniejszenie naszego zakresu prac i skupienie si臋 na rozwoju tego, co dzia艂a?
Zamiast tworzy膰 nowe i nowsze, czasami warto odwo艂a膰 si臋 do zdrowego rozs膮dku i sprawdzi膰 co ju偶 dzia艂a, co ma najwi臋kszy potencja艂 i co mo偶emy zrobi膰 w pierwszej kolejno艣ci. Tak, wiem. Empiryzm.
To mo偶e agile?
Podej艣cie agile to przecie偶 nic innego jak zdrowy rozs膮dek. A ten powinien walczy膰 z robieniem rzeczy w nieefektywny spos贸b, niezale偶nie od przyczyn. Powinni艣my ignorowa膰 okrzyki pod tytu艂em „Zawsze tak robili艣my!” czy „Specyfika naszej pracy nie pozwala nam pracowa膰 tak, jak robi to ca艂a nasza konkurencja i wszyscy, kt贸rych znamy!”. Skoro co艣 nie dzia艂a, to czasami musimy si臋 sami przed sob膮 przyzna膰, 偶e nie dzia艂a艂o to nigdy i ca艂e lata robili艣my co艣 po prostu 藕le.
Tu trzeba podkre艣li膰, 偶e nikt z #bia艂ko nigdy nie zaproponuje postawienia czego艣 na g艂owie bez zrozumienia problemu i ryzyk, jakie wi膮偶膮 si臋 z rewolucj膮. Co te偶 zawsze powtarzamy na naszych szkoleniach i warsztatach oraz w naszej pracy jako konsultanci wspieraj膮cy zwinne firmy. Ale wr贸膰my do sedna problemu.
Na wst臋pie napisa艂em, 偶e wiele organizacji pr贸buje dorabia膰 ideologi臋 i/lub komplikuje sobie 偶ycie. Poda艂em przyk艂ad z „projektoz膮”, gdzie zamiast na robieniu biznes贸w skupiamy si臋 na robieniu projekt贸w. Niestety, podobnie cz臋sto jest ze zwinno艣ci膮. Zamiast robi膰 biznes, zaczynamy „robi膰 agile”. A to 藕le. Nie taki jest cel zwinno艣ci.
Q „Agile is not the goal, your goal is the goal.”
Pami臋tajmy, 偶e wsz臋dzie i w ka偶dym podej艣ciu liczy si臋 to, do czego nasza firma zosta艂a powo艂ana. Albo m贸wi膮c inaczej – cel, kt贸ry sobie postawili艣my. Od czasu Scrum Guide 2020 jest 艂atwiej, bo mamy przynajmniej Cel Produktu, kt贸ry zmusza nas do tego, 偶eby艣my si臋 nad tym zastanowili. Ale to nie jedyna opcja.
Co zrobili艣my i co zrobimy?
Nie dalej ni偶 tydzie艅 temu zastanawia艂em si臋, od czego zacz膮膰 naprawia膰 Scrum. Spoiler alert: na pewno nie od Wydarze艅, ale od sensu naszej codziennej pracy. Co robimy i po co? Jaki cel mamy zamiar osi膮gn膮膰? Jak pracuj膮 i wsp贸艂pracuj膮 nasze zespo艂y? To wszystko jest o wiele wa偶niejsze, ni偶 jakiekolwiek Wydarzenia i Artefakty Scrum.
I przy tej okazji chcia艂bym wszystkie dzisiejszej tematy zebra膰 w jedno i zaapelowa膰: przesta艅my udziwnia膰 „ten ca艂y Scrum” i „ten ca艂y agile”. Pracujemy iteracyjnie i przyrostowo, bo nie da si臋 z g贸ry okre艣li膰 potrzeb, mo偶liwo艣ci i procesu wytw贸rczego. Pracujemy po to, 偶eby osi膮gn膮膰 jaki艣 cel i przynie艣膰 naszej organizacji (b膮d藕 nam samym) korzy艣ci. Nie robimy „ceremonii Scrum„, bo nie interesuje nas sztuka dla sztuki.
Wr贸膰my wi臋c do podstaw i upraszczajmy. Zacznijmy od znalezienia celu. Potem pracujmy w kr贸tkich okresach, mo偶emy nawet nazwa膰 je iteracjami b膮d藕 Sprintami. W ramach tych偶e kr贸tkich okres贸w najpierw si臋 zaplanujmy, potem spr贸bujmy zrealizowa膰 nasz plan, a na koniec powiedzmy o tym, co z tego planu uda艂o si臋 zrobi膰, co nie i co w zwi膮zku z tym mamy zamiar robi膰 dalej. Dajmy sobie szans臋 na zmiany wymaga艅, zrobienie czego艣 lepszego. I zapomnijmy o tym nieszcz臋snym projekcie.
W tek艣cie pod tytu艂em „Sprint Review to nie demo” porusza艂em ju偶 ten temat, ale dzi艣 chcia艂bym do niego wr贸ci膰 w nieco innym uj臋ciu. Review to bardzo wa偶ne spotkanie, kt贸re dotyczy esencji zwinno艣ci i tego, o czym jest dzisiejszy tekst. Zobaczmy co zrobili艣my, jak nam posz艂o (oraz co nie posz艂o i dlaczego), a nast臋pnie zastan贸wmy si臋 nad tym, co b臋dziemy robi膰 dalej. Nie, jeszcze tego nie planujemy, na razie tylko o tym rozmawiamy.
Robi膮c „poprawne” Sprint Review mo偶emy si臋 przekona膰, 偶e warto rozmawia膰. O tym co w艂a艣nie zrobili艣my i o tym, co b臋dziemy robi膰 zaraz i dalej. I ta rozmowa da nam wi臋cej ni偶 jakie艣 frameworki, procesy czy wydarzenia. Po prostu przesta艅my komplikowa膰.
Bardzo fajnie napisane 馃檪
Ja ostatnio odnosz臋 wra偶enie, 偶e je艣li nie jeste艣my zwinni, to ju偶 mo偶emy pakowa膰 swoje rzeczy i szuka膰 innego zaj臋cia. A w ko艂o wszyscy celebruj膮 swoj膮 zwinno艣膰, tylko nikt nie m贸wi, co dalej.
Zaprezentowan膮 powy偶ej 'zwinno艣膰’, czyli chocia偶by kr贸tkie iteracje stosowali艣my kilka lat temu, bo doszli艣my do wniosku, ze tak jest efektywniej. I nikt wtedy nie wywy偶sza艂 si臋, 偶e jest 'zwinny’ a inni nie 馃檪