Luka Ferlež
Autor:
Luka Ferlež

Voditelj razvoja

Više timova na scrum projektu

U prethodnom postu prošao sam po našim iskustvima u radu s timovima na malim projektima, sada je došlo na red naše iskustvo u skaliranju scrum procesa na projektima koji imaju veći broj timova, product ownera, analitičara, pm-ova i svih ostalih.

Povećanjem broja ljudi na projektu dolazi do povećanja overheada komunikacije, koordinacije i općenito smanjenja efikasnosti ljudi zbog čega je onda nužno timove segmentirati kako bi održali vrijednosti iz agile manifesta. Scrum proces se relativno jednostavno skalira ukoliko se držimo nekih osnovnih načela samog scruma gdje topologija procesa kaže da jedan tim može raditi iz jednog backloga kojeg može održavati jedan product owner.

Scrum topology

Skaliranje razvojnih timova

Prilikom širenja razvojnog tima brzo dolazimo do veličine tima, 7+ ljudi, kod kojega je teško efikasno raditi scrum. Intuitivna promjena je razdvajanje razvojnog tima na dva (ili više) manja tima kako bi se poboljšala efikasnost svakodnevnog rada koji rade iz zajedničkog backloga. Rad više timova iz jednog backloga podrazumijeva da product owner održava jedan product backlog za sve timove, a na sprint plannigu se PBI-evi uzimaju iz tog product backloga u sprint backlog. U tako postavljenoj topologiji sprintove možemo organizirati s jednim zajedničkim sprintom za sve timove ili odvojenim sprintom za svaki tim.

Planiranje zajedničkog sprinta se provodi na sprint planningu gdje sudjeluju svi članovi timova. Svaki tim tijekom planiranja daje commitment za svoj komad sprinta i ukupno za cijeli sprint, jednako tako se rade i zajedničke retrospektive sprintova. Ovakav pristup je pun svojih specifičnih izazova poput organizacije, održavanja efikasnosti ceremonija sa svim tim ljudima, nedostatka buy-ina u commitmentu za cijeli sprint i s upitnom autonomijom pojedinih timova.

Planiranjem odvojenih sprintova po timu se neki od tih izazova izbjegavaju, ali se udvostručuje broj potrebnih ceremonija, nužno je uzeti u obzir sinkronizaciju s ostalim timovima, kako bi se uspješno izbjeglo cross-dependency među sprintovima i obratiti pozornost na opterećenje product ownera.

Skaliranje Backloga

Sljedeća opcija koju imamo na raspolaganju kako bi akomodirali više ljudi u implementaciji je skaliranje samih backloga na način da razdvojimo backloge po dijelovima proizvoda te onda svakom backlogu pridružimo jedan ili više timova prema gornjem modelu skaliranja timova.

Multi PB multi team

U ovakvoj organizaciji svaki tim s product ownerom surađuje na izgradnji backloga i implementaciji zahtjeva za svoj dio proizvoda, a scrum ceremonije su jednostavnije za organizirati s obzirom da sudjeluje samo tim koji će direktno raditi na tom backlogu. Opterećenje Product ownera i potreba za sinkronizacijom timova je ovdje izražena te treba osigurati dodatnu podršku product owneru kako bi se to poslovne vrijednosti uspješno realizirale.

Skaliranje Product ownera

Još jedna opcija koju imamo je skaliranje product ownera i obzirom da product owner kao osoba nije rastezljiv niti ga je moguće podijeliti potrebno je uvesti nove product ownere u kombinaciji s više backloga i razvojnih timova kako bi održali pravilnu topologiju scruma. U skladu s principom da može postojati samo jedan product owner, tj. samo jedna osoba odgovorna za cijeli proizvod, obično se uvodi Chief product owner uloga kako bi zadržali zajedničku viziju proizvoda.

Uvođenjem dodatnih product ownera potrebna je koordinacija i na razini tima product ownera u obliku product owner tima i pripadajućih scrum of scrums aktivnosti. Svaki product owner se brine za svoj dio proizvoda, recimo modul, set featurea ili proces u svojem backlogu u dogovoru s ostalim članovima product owner tima te koordinira svoje aktivnosti s Chief product ownerom.

Chief product owner ima zadatak brinuti se o velikoj slici, cijelom proizvodu i usmjeravanju product owner tima, a obično preuzima i ostale standardne pm-ovske zadatke te tako oslobađa ostale product ownere tih aktivnosti kako bi imali veći fokus na rad s stakeholderima i timom.

Skaliranje supporting uloga

U kompleksnim projektima nije rijetko da se pojavljuju supporting uloge poput arhitekata, dizajnera, analitičara, domain experata, tehničkih specijalista itd. koje je isto tako potrebno skalirati s povećanjem potreba projekta. Inicijalno kako se uloga pojavljuje onaj koji ju obnaša se uključuje u scrum ceremonije prema potrebi, a s rastom potrebe za tom ulogom može se formirati tim po uzoru na product owner tim te članovi tog tima dodijeliti nekoj grani proizvoda.

Naša primjena?

U svim navedenim primjernima povećava se kompleksnost organizacije, a s time i potreba za usklađivanjem aktivnostima timova, planiranjem high-level podjele posla, jedinstvenim definition of done, a na razini svih timova je potrebno uvesti dnevnu koordinaciju među timovima, tj. scrum of scrums sastanke. Odabir što ćete i kako skalirati ovisi o potrebama i mogućnostima i ne postoji jedan ispravan način, mi smo odlučili da ćemo kreirati product owner timove na kompleksnim projektima, s uvođenjem svega što to podrazumijeva.

Oraganizacija

Chief product owner ulogom smo spojili bivšu funkciju PM-a i high-level razradu proizvoda recimo epic-feature nivo koja uz odgovarajuću podršku od ostatka product owner tima može efikasno usmjeravati smjer proizvoda u suradnji s stakeholderima. Dnevna preokupacija CPO je fokusiranje product owner tima na vrijednosti, rješavanje dilema u redoslijedu implementacije i suradnja s stakeholderima na održavanju ritma isporuka u cilju ispunjenja potreba korisnika.

Arhitekt sustava nam je sljedeća bitna uloga čiji je osnovni zadatak da poveže rad svih timova u jednu smislenu arhitekturnu cjelinu kao i da intenzivno surađuje s product owner timom i stakeholderima na izradi i održavanju efikasne arhitekture sustava pogotovo u odnosu na vanjske ovisnosti sustava i internu komunikaciju raznih komponenti.

Organizirani na taj način omogućavamo product ownerima da rade blisko sa svojim timovima na backlogu i implementaciji i što je iznimno bitno na zajedničkoj viziji poboljšanju svojeg dijela proizvoda i procesa. Timovim takva organizacija omogućava veliku razinu autonomije u donošenju odluka koje smatraju ispravnim i najboljim za svoj tim bez da gube iz vida veliku sliku i ukupni proizvod.

Kako razvojni timovi i product owner tim ne bi izgubili iz vida ukupni proizvod čiji su dio trebali bi provoditi scrum of scrums sastanke. Ti sastanci kod nas nisu formalni s obzirom da timovi na projektu sjede zajedno pa imaju neposrednu face to face komunikaciju, ali sigurno da ćemo s povećanjem broja timova možda morati i to formalizirati.

Prednost ovakve organizacije je da podržava dosta velik broj timova i ljudi bez neke potrebe za promjenom, otprilike do nekih 40-50 osoba u recimo nekih 6 timova na istom projektu. Kada i ako dođemo do granice broja timova koje možemo podržati, ovakvu organizaciju je relativno jednostavno proširiti na sličan način, tako da sky is the limit.

Sada smo posložili male i velike projekte, sljedeći korak koji imamo u vidu je uvođenje devopsa u te projekte, u sljedećem postu.

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone BI Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile continuous deployment Continuous Integration CSR d3js data visualization 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 IoT IPSO izvještavanje java 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 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 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 Testing Club Spring Boot SQL standard sustav videonadzora svg Team team building team development terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica 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