scrum to chaos i brak planowania blog

“Scrum to chaos i brak prawdziwego planowania”. Serio? 馃檭

Agile

Us艂ysza艂em w 偶yciu kilka razy dziwne opinie dotycz膮ce planowania (rozwoju produktu, projekt贸w) w Scrumie. Mi臋dzy innymi, 偶e to taka sztuka dla sztuki i w zasadzie jest bezcelowe; to “niezwinne”; wbrew 鈥渮asadom Scruma鈥 lub w og贸le si臋 tego po prostu nie robi. Czas ubi膰 jeden z g艂upszych mit贸w. Takie opinie to 艣wietna inspiracja dla moich post贸w聽馃槑

Komentarze brzmi膮 podobnie do: 鈥渨 tych zespo艂ach scrumowych my艣licie tylko o horyzoncie np. dwutygodniowym (d艂ugo艣膰 sprintu), nie patrzycie w og贸le np. na kwarta艂鈥. Tak jakby planowanie w Scrumie oznacza艂o tylko, 偶e raz na sprint Scrum Team si臋 spotyka, co艣 tam sobie ustala (jakie艣 cele, taski) i potem znowu za dwa tygodnie to samo. A ja m贸wi臋, 偶e patrzymy dalej ni偶 sprint. Tylko w nieco inny spos贸b ni偶 w klasycznym, projektowym podej艣ciu z super sztywnym harmonogramem na wiele miesi臋cy do przodu, zakresem i bud偶etem. Klasyczne podej艣cie z pozoru wydaje si臋 bardzo jasne, naturalne i logiczne – ka偶dy uwielbia pi臋kne plany, wykresy, zarz膮dzanie ryzykami, statusy i takie tam. Tylko, 偶e to si臋 nie sprawdza. Co wi臋cej, takie planowanie to marnotrawstwo i zach臋canie do pora偶ki.

Ma艂e jest lepsze

W Scrum wbudowana jest akceptacja zmienno艣ci i my艣lenie o planie na kilku poziomach – od bardzo szczeg贸艂owego (np. daily, sprint) do bardziej rozmytego (np. kwarta艂, roadmapy itp.). 聽W zale偶no艣ci od rozwoju sytuacji i samych cel贸w biznesowych co艣 b臋dzie si臋 zmienia艂o w naszym 艣wiecie – to nieuniknione. Scrum to akceptuje.

Warto ustawi膰 og贸lne (wy偶szego poziomu) cele biznesowe o d艂u偶szym horyzoncie czasowym, mie膰 wizj臋. Mo偶na korzysta膰 z nawigacji w postaci OKR贸w (wi臋cej o tym poj臋ciu m.in. tu w wyst膮pieniu Kuby Uniejewskiego na Agile By Example 2017) lub innych narz臋dzi o podobnym charakterze. To dobre ramy do codziennej pracy, wykraczaj膮ce zdecydowanie poza sprint. Scrum wspiera takie praktyki, bo przez prac臋 w sprintach oraz warto艣ci, kt贸re s膮 w nim zaszyte (m.in transparentno艣膰) pomaga cyklicznie sprawdza膰 post臋py i pokazywa膰 gdzie jeste艣my w realizacji tych cel贸w, jakie mamy problemy, czy trzeba plan dostosowa膰 itd. Trzeba tylko wiedzie膰 jak pouk艂ada膰 te klocki.

Planowanie w Scrum blog post opt

W zwinnym podej艣ciu masz narz臋dzia do tego, aby poradzi膰 sobie z dynamik膮 otoczenia – sprinty, rejestr produktu, retro itd. W podej艣ciu sztywnym pewnie b臋dziesz robi膰 to co tak dok艂adnie zaplanowa艂e艣 i zadeklarowa艂e艣, 偶e zrobisz. No, bo jak inaczej? Przecie偶 oznacza艂oby to, 偶e 藕le zaplanowa艂e艣, prawda? Tylko co zrobi膰 z dobrymi pomys艂ami, kt贸re uczyni膮 produkt lepszym, a s膮 niezgodne z pierwotnym planem? Czemu nie zmienia膰? 鈥淏o przecie偶 plan!鈥 Troch臋 g艂upia motywacja.

Og贸lne plany na np. 2-3 miesi膮ce w zespo艂ach zwinnych s膮 czym艣 ca艂kiem normalnym. Taki plan nie oznacza najcz臋艣ciej jednak pe艂nego piel臋gnowania “ca艂ego backlogu”. Dwa, trzy sprinty dobrze przygotowane s膮 do艣膰 optymalne z regu艂y. Reszta “odkrywana” jest z czasem. Zesp贸艂 zna wizj臋 i kierunek, ale nie musi zna膰 ka偶dego szczeg贸艂u na starcie. Cz臋sto wystarcz膮 nieco lu藕niejsze rozmowy co do kierunku, kt贸ry Scrum Team chce obra膰. Nikomu nie jest potrzebny du偶y szczeg贸艂owy plan, godziny spotka艅, tony analiz. W Scrumie plan dotycz膮cy d艂u偶szego horyzontu czasowego b臋dzie elastyczny, z dopuszczalnymi zmianami i mniej precyzyjny ni偶 plan na najbli偶szy sprint. Po prostu. Im dalej si臋ga Tw贸j wzrok tym mniej szczeg贸艂贸w jeste艣 w stanie zobaczy膰. W Scrumie stawia si臋 na empiryzm, zbieranie danych i dostosowywanie. To 艣wietne ramy do rozwijania produkt贸w i planowania. Usztywnianie si臋 na d艂ugie, super-rozplanowane projekty to b艂膮d.

Wygenerowaliby艣my strat臋, zmarnowaliby艣my czas, analizuj膮c, piel臋gnuj膮c wiele do przodu. Cz臋艣膰 z pomys艂贸w zgni艂aby w rejestrze produktu. Spotkania po艣wi臋cone na ich om贸wienie posz艂yby w b艂oto. To zwyk艂e marnotrawstwo. Lepszym rozwi膮zaniem b臋dzie przygotowywanie mniejszych projekt贸w, mniejszych kawa艂k贸w i krok po kroku docieranie do wi臋kszego celu. Je艣li co艣 si臋 w nich nie powiedzie to te偶 straty ponosimy mniejsze. Ile razy widzia艂em “mega-dopracowane wielomiesi臋czne projekty”, w kt贸rych zespo艂y by艂y zmuszane do wielogodzinnych analiz, piel臋gnacji itd., a potem okazywa艂o si臋, 偶e to jednak zbyt du偶y horyzont czasowy, nie wszystko si臋 da艂o przewidzie膰, nie wszystko b臋dziemy chcieli robi膰, a tak w og贸le to “zamiast kodzi膰 tracimy czas na spotkania”.

Scrum planowanie blog post opt

Je艣li z jakiego艣 wzgl臋du musisz mie膰 oszacowane historyjki w du偶ej ilo艣ci do przodu, to mo偶e warto skorzysta膰 z Bucket System? W przysz艂o艣ci spr贸buj臋 to opisa膰, p贸ki co skorzystaj z tego linku, aby dowiedzie膰 si臋 o tym podej艣ciu wi臋cej. Bucket system pozwala oszacowa膰 pewien zakres, ale jest stosunkowo szybki – ca艂kiem sporo warto艣ci przy niskim nak艂adzie czasu. Je艣li masz potrzeby planowania du偶o wi臋kszych ca艂o艣ci mo偶esz te偶 spr贸bowa膰 u偶ywa膰 czego艣 takiego jak planowanie wyda艅, ale to raczej “stara technika” i coraz rzadziej stosowana.聽

 

鈥淎le to musi by膰 na konkretn膮 dat臋!鈥 No dobra, nie ma problemu

W podej艣ciu zwinnym nie ma problemu ze sztywnymi datami je艣li s膮 konieczne. M贸wimy w贸wczas o projektach typu fixed-date. Za艂贸偶my, 偶e u偶ywasz Story Points do szacowania rozmiaru swoich historyjek. Znasz pr臋dko艣膰 spalania punkt贸w przez zesp贸艂. Zatem wiesz ile punkt贸w szacunkowo uda Ci si臋 spali膰 do tej konkretnej daty. To jest Tw贸j 鈥渂ud偶et i mo偶liwo艣ci鈥 – planuj! :) Pami臋taj jednak, 偶e na pewno podczas pracy b臋dziesz musia艂 decydowa膰 o zmianach. Mo偶esz mie膰 nowy pomys艂 – co wtedy? Oszacuj go i wymie艅 za historyjk臋, kt贸ra ma taki sam rozmiar (story points). Mo偶e te偶, zdarzy膰 si臋, 偶e po drodze deweloperzy trafi膮 na problemy, kt贸re ich spowolni膮. W贸wczas trzeba np. dostosowa膰 wymagania, a jeszcze lepiej usun膮膰 przeszkody w pracy zespo艂u. Uwaga: im odleglejsza data tym 艂atwiej o wpadk臋, wi臋c warto szuka膰 takich sposob贸w na rozwijanie produkt贸w czy prowadzenie projekt贸w, kt贸re kroki pozwalaj膮 robi膰 mo偶liwie ma艂ymi.

 

鈥淎le to musi by膰 dok艂adnie to, a nie co艣 innego!鈥 No dobra, nie ma problemu

W tym przypadku Scrum te偶 da rad臋. Chcesz otrzyma膰 do艣膰 sztywny, okre艣lony zakres? W贸wczas data b臋dzie negocjowalna. Ponownie wystarczy policzy膰 mo偶liwo艣ci (tempo spalania story points) i ustalaj膮c wymagania, otrzymasz wynik – czas dostarczenia. Tutaj natomiast data b臋dzie z za艂o偶enia bardziej elastyczna, bo w zale偶no艣ci od rozwoju sytuacji (liczba niewiadomych, problem贸w, tempo ich usuwania) oka偶e si臋, 偶e zesp贸艂 mo偶e pracowa膰 szybciej lub wolniej. Ponadto takie podej艣cie wymaga zdefiniowania stosunkowo sztywno zakresu, a wiesz chyba 偶e w 偶yciu zdarzaj膮 si臋 niespodzianki. No i pomys艂y najlepsze potrafi膮 przyj艣膰 w ostatniej chwili, wcze艣niej nieplanowane :) Tu tak偶e wa偶na uwaga: im mniejszy zakres tym 艂atwiej przewidzie膰 ewentualne po艣lizgi, problemy itd., a tak偶e mniejszy zakres oznacza mniej przygotowa艅. Ponownie warto my艣le膰 ma艂ymi kroczkami.

 

Jak zwykle – z艂oty 艣rodek rz膮dzi. Planowanie w Scrumie to nic trudnego

Nie zaskocz臋 Ci臋 tu chyba niczym nowym, ale jednak pozwol臋 sobie to napisa膰. Popadanie w skrajno艣ci jest najcz臋艣ciej najgorszym rozwi膮zaniem. Planowanie jest wa偶ne, ale nie mo偶na si臋 te偶 da膰 zwariowa膰. Im dalej w przysz艂o艣膰 tym wi臋cej niewiadomych, prawda?聽Czemu tego po prostu nie zaakceptowa膰?

Planowanie w Scrumie post blog opt

Planowanie w Scrumie to ca艂kiem niez艂a odpowied藕 na dynamik臋 otoczenia i zmiany. Zespo艂y scrumowe maj膮 鈥渮aszyte w swoim systemie鈥 podej艣cie 鈥渮r贸b, sprawd藕, dostosuj鈥. Zwinno艣膰 nie oznacza braku planowania, ale prac臋 na empirycznych danych, kt贸re pozwalaj膮 plany dostosowywa膰. Wystarczy z tej mocy 艣wiadomie korzysta膰, a nie gniewa膰 si臋 na 艣wiat, 偶e znowu co艣 藕le zaplanowali艣my na wiele miesi臋cy do przodu. Planowanie w Scrumie to co艣 zupe艂nie normalnego, ale trzeba rozumie膰 jego poziomy (planowanie dnia, sprintu, roadmapy itd.) i relacje mi臋dzy konkretem, a horyzontem czasowym. Je艣li z jakiego艣 wzgl臋du musimy robi膰 du偶e rzeczy to dzielmy je na jak najmniejsze, nie zabijajmy si臋 tonami analiz przygotowywanymi na pocz膮tku, wpadaj膮c w kaskadowe klasyczne podej艣cie i sprawdzajmy regularnie jak nam posz艂o.

Je艣li zainteresowa艂 Ci臋 ten post to mo偶e zechcesz przeczyta膰 tak偶e:

  1. M贸j tekst o nieprawdziwych opiniach na temat Scruma.
  2. Dokumentacja daje z艂udne poczucie kontroli

Wykorzystanie grafiki / zdj臋cia: 1, 2, 3,4.

1 komentarz w ““Scrum to chaos i brak prawdziwego planowania”. Serio? 馃檭

Dodaj komentarz

Tw贸j adres email nie zostanie opublikowany. Pola, kt贸rych wype艂nienie jest wymagane, s膮 oznaczone symbolem *