Luka Ferlež
Autor:
Luka Ferlež

Voditelj razvoja

Skaliranje timova

Uvođenjem Scruma u organizaciju prije ili poslije se suočimo činjenicom da imamo projekte koji se ne mogu održati u okvirima jednog tima, obično nam treba malo više ili malo manje ljudi s određenim skillovima u raznim periodima projekta. Razni su razlozi, moguće je da projekt većim dijelom godine ima samo reaktivno održavanje, a u jednom kratkom periodu ima veliku količinu aktivnosti, moguće je da projekt ima potrebu za 100 ljudi koji moraju surađivati na ostvarenju zajedničkog cilja, tjedne varijacije u opterećenju i uvođenje devops-a, ...

Svi ti zahtjevi koji izlaze iz okvira onoga što Scrum kao metodologija određuje je prepušteno nama da se snađemo najbolje što možemo i vrlo često se radi o metodi pokušaja i promašaja. Mi u Kingu smo imali dosta raznih pokušaja i posljedičnih promašaja u iznalaženju kako se nositi s takvim situacijama i putem smo učili i rasli, ali i dalje pokušavamo i isprobavamo kako se pomaknuti još malo.

Pristup skaliranju samog procesa je jako različit ovisno o zahtjevima samih projekata i svoja iskustva skaliranja različitih veličina timova i koraka prema devops-ima ću proći u nizu od 3 posta, pa počnimo s...

Jedan tim

Follow Scrum guide and carry on, u teoriji nema nikakvih briga i sve ide kao podmazano, u teoriji :)

Manje od jednog tima

Projekti koji imaju ili privremenu ili stalnu potrebu za manje od jednog tima su posebno problematična kategorija za upravljanje. Obzirom da s jedne strane je cilj imati tim, kolaboraciju, zajedničko znanje i sve ono čemu stremimo u Agile svijetu, a s druge strane možda se na projektu ne može iskoristiti puni kapacitet tima. Kad ubacite u mix situaciju da nemate pravi cross-functional tim, tj. da morate imati više ljudi s različitim skillovima, a onda povrh toga i varijabilno opterećenje jedan tjedan svi 100% drugi tjedan svi 20% imamo krasan mix zahtjeva za ispuniti. S čime smo sve eksperimentirali? Razne ideje...

Pokušaj 1. Mali timovi

Pokušali smo s timovima koji će brojem ljudi odgovarati potrebnom broju isporučivih dana u nekom periodu, npr. 40 č/d u jednom mjesecu = 2 čovjeka. Ovo nije toliko pokušaj koliko je zatečeno stanje prije nego što smo krenuli na Scrum, pa smo pokušali timove samo prebaciti na Scrum i vidjeti kako će to ići. Ovaj pristup relativno dobro funkcionira, ali ima 2 velika nedostatka:

  • Zahtjeva cross-functional tim ili malo različitih skillova na projektu. Zašto? Ukoliko projekt zahtjeva 2 osobe te osobe moraju moći raditi posao jedna druge kako bi postojala nekakva mogućnost balansiranja kapaciteta unutar sprinta. Rijetko kada će se dogoditi da je jednaka potreba po raznim skillovima u nizu sprintova.
  • Nedostupnost jedne osobe iz tima drastično utječe na kapacitet isporuke, a mogući odlazak iz tima uzrokuje značajan gubitak znanja o samo rješenju. To ukratko znači da je razvojni tim postao najveći rizik u implementaciji i održavanju tog rješenja.

Oba nedostatka rezultiraju time da postoji značajan overhead u planiranju i upravljanju ljudima na takvima projektima zbog nemogućnosti samih timova da kompenziraju osnovne stvari poput godišnjih, bolovanja i sličnih stvari, a organizacija stvari poput dežurstava je noćna mora.

Pokušaj 2. Preraspodjeljivanje ljudi

Ovaj pokušaj je bio usmjeren na prvi nedostatak iz prethodnog pokušaja, tj. što napraviti u nedostatku cross-functional tima, a potrebno nam je puno različitih skillova. Što smo napravili? Nešto kontra ideje tima, ali svejedno smo probali tako da smo ljude stavljali u sprintove koliko je bilo zadataka za njih taj sprint i rezultat toga je vrlo vjerojatno svima očit.

  • Nema tima. Ovaj pristup u principu znači da nema stalnog tima, već su svi padobranci ovisno o trenutnim potrebama.
  • Bez tima nema zajedničke odgovornosti niti brige o ukupnom rezultatu i cilju.
  • Nitko ne garantira da će odgovarajući ljudi biti raspoloživi u nekom periodu bez prethodne najave, što zahtjeva dosta upfront planiranja.
  • Ogromna disperzija znanja o sustavu.
  • Žongliranje s toliko ljudi je veliki overhead kod organiziranja groominga, planiranja kako bi se izbjeglo pozivanje nepotrebnih ljudi, potrebno je upfront planiranje tema koje će se obrađivati.

Vrlo vjerojatno bi mogao nabrojati još loših stvari, prvo je samo po sebi dovoljno da to više nikada ne probamo. Naravno očiti odgovor ovdje je napravite cross-functional tim, ali u današnjem svijetu tisuća različitih tehnologija ukoliko nemamo dugoročni projekt upitna je isplativost takve investicije.

Pokušaj 3. Hive (Košnice)

Ovo nam je bila solidna ideja, ali na kraju ispada da smo greškom u implementaciji samo napravili nered od osnovnog Scrum procesa. Ideja je, sklopimo tim ljudi s određenim skillovima i kapacitetom i dajmo im istovremeno u rad više manjih projekata u nadi da će balansiranjem aktivnosti iskoristiti svoj kapacitet i sposobnosti, da će se izgraditi kao tim što će rezultirati isporukama po svim projektima uz manji overhead nekog upfront planiranja.

U našoj organizaciji to je značilo da imamo jedan tim, ali da imamo više PO-a i backlog-a, što je slijedilo iz projektnog ustroja same organizacije gdje svaki projekt ima svojeg PM-a koji se brine o projektu, a svaki PO ima svoj backlog. Naravno to je završilo kao fail iz jednostavnog razloga što sada kada imamo jedan tim su se svi ti PO i projekti trebali sinkronizirati. Osobno sam kao SM provodio više vremena pregovarajući s PO-ovima nego što sam se bavio timom i procesom.

Obzirom da to nije in-house product development, već je custom razvoj software koji ovisi dobrim dijelom o raspoloženju korisnika takva sinkronizacija nije baš jednostavna i zahtjeva jako dobrog PO s dobrim pregovaračkim skillovima.

Nered od scruma koji sam spomenuo smo napravili time što smo ulogu i artefakt koji je namijenjen da bude jedinstven, jedan PO, jedan backlog po timu razbili na više manjih dijelova koje treba usklađivati i to je proizvelo kaos:

  • Backlog itemi su raspoređeni po više backloga iako u svima njima možda ima za jedan sprint, u svakom pojedinačnom nema dovoljno za sprint.
  • S obzirom na prethodno slažemo krnje sprinteve (više limitacija alata, nego procesa).
  • Krnji sprintevi bacaju sve metrike (burndown chartovi, velocity, itd.) u vodu.
  • Backlog grooming se odrađuje s svakim PO posebno, na njegovom backlogu, pa ih ima puno više.
  • Ne stvara se razumijevanje između PO i tima, jer svaki PO ima svoje načine komunikacije.
  • Retrospektive malo gube smisao, jer ono što vrijedi na projektu ne kojem si završio sprint, možda ne vrijedi na projektu na kojem je sljedeći sprint.

Treba spomenuti i trošak context-switchinga kod ovakvog načina rada, ako se tim switcha između raznih projekata svakih 2 tjedna to je poprilično disruptivno za njihov flow.

Ono što je ovdje pozitivno je to da su u principu riješena oba nedostatka koji proizlaze iz imanja malih timova, ali smo uveli neke nove.

Pokušaj 4. Hive v2.0?

Vrlo vjerojatno neka modifikacija i reboot Pokušaja 3. s promjenom da se vratimo osnovama scruma one PO to rule them all i naravno jedan backlog. Time ne rješavamo problem sinkronizacije svih projekata koji su na tom timu, ali taj 1 PO bi trebao biti i odgovoran za isporuku svih tih projekata pa onda u pravoj maniri PO odlučivati o potrebama svih svojih projekata.

Nisam baš siguran da će se to svima sviđati :)

Što smo naučili?

Pokušavali smo i fulavali, ali u principu smo opet došli natrag na neke osnove scruma, samo smo se pravili pametni u postupku. Naučili smo da ono što piše u Scrum guide nije tamo bezveze 1 Tim = 1 Backlog = 1 PO, svašta možemo mijenjati, ali osnova Scruma ukoliko ga želimo prakticirat se moramo držati. Ovo sigurno izgleda kao da mijenjamo stvari i idemo na glavu bez da smo čitali, proučavali i učili na pokušajima i promašajima drugih, ali volimo kontrolirano eksperminetirati kako da se poboljšamo. 

Next up iskustva iz kategorije "Više od jednog tima", uskoro nadam se :)

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java java lambde benchmark JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban KING ICT Kingovci Knockout kvaliteta leadership Lean M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing paginacija Performance performanse PERT PMI podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg Team team building team development Team Foundation Server terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta