Članek je mišljen kot referenca pri iskanju najprimernejšega tipa Agilne pogodbe glede na dinamiko med naročnikom in izvajalcem.
Vsebina
Izzivi Agilnih pogodb
Pri razvojnih iniciativah mora izvajalec zaradi nenehnih novih spoznanj (in posledično zahtev), smer razvoja kontinuirano usklajevati z ostalimi deležniki. S stališča tradicionalnih pogodbenih odnosov sta ta dinamika in nedorečenost problematični, saj se ju težko formalizira s pogodbo.
Agilni tipi pogodb so poizkusi enakomerne razporeditve tveganja med naročnikom in izvajalcem v nepredvidljivem razvojnem okolju, kjer se produkt razvija inkrementalno.
Primer: Stranka želi rešitev za poslovni problem. Problem je poznan, najprimernejša rešitev in pot do nje pa nista. Takšna iniciativa bo od izvajalca zahtevala cikličen inkrementalni pristop. Vsak naslednji razvojni cikel bo namreč gradil na spoznanjih prejšnjega. Temu primerno se bo torej prilagajala tudi smer razvoja in identifikacija najprimernejše rešitve.
Če stranka v takšni situaciji insistira na fiksni pogodbeni ceni, bo s tem celotno tveganje prenesla na izvajalca. Zaradi številnih neznank, bo ta namreč težko podal natančno oceno razvojnih stroškov. Da bo omenjeno tveganje kompenziral, bo moral izvajalec znatno povišati ceno (z rezervo za nepredvideno delo) ali pa tvegati izgubo. To ni željeno stanje niti za naročnika, niti za izvajalca.
Poglejmo si nekaj tipov pogodb, ki so v različnih kontekstih primerne za ciklično razvojno delo. Uporabljal bom njihova angleška imena, kar bo tistim, ki jih tema zanima, pomagalo pri iskanju nadaljnjih virov. Poleg tega, pa je v slovenščini težko najti uveljavljene ekvivalente za določene izraze.
Tipi Agilnih pogodb
Time & Material
Se pogosto smatra za “pravi” Agilni tip pogodbe. V tem tipu pogodbe naročnik izvajalcu (iz projektnega proračuna) plačuje po urah potrošenih za razvoj rešitve. Ta je običajno omejen še z datumom zaključka dela.
Pogosta kritika te pogodbe je, da preferira izvajalca in vzpodbuja scope creep. Po mojem to ne drži, saj so iterativni razvojni cikli kratki in naročnik v njih konstantno sodeluje. Razvojni proces je transparenten, tako da izvajalec v bistvu nima možnosti skrivati razvoja nepotrebnih in neodobrenih funkcionalnosti (Product Owner je naročnikov zastopnik).
Poleg tega, ima naročnik po taki pogodbi, možnost prekiniti sodelovanje v trenutku, ko presodi, da output iteracij več ne prinaša dovolj visoke poslovne vrednosti.
Značilnosti:
- Cena temelji na urni postavki izvajalca.
- Pogodba vsebuje le okvirno specifikacijo rešitve.
- Stranka lahko pogodbo prekine kadarkoli.
Za:
- Dobro razumljen tip pogodbe.
- Primerna, če vizija in zamišljena rešitev nista dobro definirani.
Proti:
- Ne omogoča objektivnih mejnikov (milestones) za določanje napredka. Tej težavi se da izogniti s konstantnim sodelovanjem naročnika z razvojnim teamom (Product Owner). Tako mejniki postanejo s strani naročnika potrjene funkcionalnosti na koncu vsake iteracije.
- Izvajalcu nudi skušnjavo za neučinkovito izrabo časa. Agile zahteva določeno stopnjo zaupanja med deležniki. Če je naročnik del razvojnega teama (Product Owner), se zaupanje zgradi hitreje.
"Strašljiv" primer
Opišimo še scenarij, ki bo prestrašil vsakega naročnikovega managerja.
Prestrašeni naročnik: “Ne morem spati. Kaj pa če bo izvajalec “navijal” ure in ne bo razvil rešitev do predvidenega datuma in v okviru budgeta? Oh bogi jaz!”
Z omenjenim managerjem seveda globoko sočustvujemo, a se čutimo obvezane, da mu pojasnimo nekaj dejstev v zvezi z naravo inkrementalnega razvoja in zakaj je ta koristen zanj.
- Glede na to, da kot naročnik poznate probleme s katerimi se spopadate, najboljše rešitve zanje pa ne, ste to nalogo prepustili strokovnemu izvajalcu. Upravičeno se zanašate na to, da bo ta uporabil vse svoje znanje in resurse, da bo poiskal najboljše rešitve za vaše probleme.
- Nekatere izvajalčeve predloge, sprejmete kot so, druge zavrnete, tretji pa obetajo, a jih mora izvajalec še dodelati. To je "iterativnost" v iterativnem razvoju - izvajalec svoje ideje preverja z naročnikom in jih rafinira dokler ta z njimi ni zadovoljen.
- Rezultat tega procesa je množica potencialnih rešitev vaših poslovnih problemov.
- Ker vsi problemi s katerimi se kot organizacija spopadate, niso enako pereči, ste jih prioritizirali po njihovi poslovni vrednosti. Seveda želite, da se problemi katerih rešitev za vas predstavlja najvišjo vrednost rešijo najprej.
- Pravtako se prioritizira zamišljene rešitve omenjenih problemov. To je t.i. Product Backlog. Na vrhu tega spiska so potencialne rešitve vaših najbolj perečih problemov, nižje po spisku ko gremo pa so rešitve vse manj perečih problemov.
- Izvajalec bo najprej razvijal rešitve na vrhu Product Backloga in se počasi po njem pomikal nižje k rešitvam manjših problemov.
- Izvajalec bo zamišljene rešitve razbil v funkcionalnosti, ki jih bo pred razvojem pravtako preveril z vami. Mogoče jih boste potrdili, mogoče pa jih bo potrebno še prilagoditi. Razvite funkcionalnosti vam bo izvajalec predstavil ob zaključku ene od naslednjih iteracij. Na ta način izvajalec razvijano rešitev sproti prilagaja vašim zahtevam. Te zahteve niso statične, ampak se praviloma spreminjajo in dopolnjujejo glede na predlagane in že razvite inovativne rešitve, ki so vam ponudile nove vpoglede v obravnavano problematiko. In tako je prav. V klasičnem pogodbenem odnosu (fiksna pogodba), kot naročnik nimate fleksibilnosti izkoriščanja poslovnih priložnosti, ki jih je razkril dosedanji razvoj. Ali boste za vsako novo identificirano priložnost podpisovali pogodbeni aneks in prilagajali celoten projektni plan?
- Ko boste z razvito rešitvijo zadovoljni, jo boste lahko takoj vključili v svoj delovni proces. Ne bo vam treba čakati na zaključek projekta, ko boste prejeli celoten komplet rešitev (pomembnih in manj pomembnih).
- Posledice takšnega iterativnega razvojnega procesa so:
- Kot naročnik dobite rešitev, ki je prilagojena vašim potrebam in maksimalno učinkovito (ne samo uspešno) rešuje vaš poslovni problem.
- Rešitve dobite hitreje kot v fiksnem pogodbenem odnosu, saj je izvajalčeva pot do rešitve, zaradi neprestanega sodelovanja z vami krajša in bolj linearna. Če se ustreznost rešitev preverja le ob milestonih ali celo samo na koncu projekta, morebitni popravki zahtevajo ogromno napora on izgubljenega časa. V takšnem primeru pogosto moramo celotno kodo, ki temelji na napačni predpostavki, napisati na novo.
- Ker je na začetku iniciative zaradi vseh neznank (ne gradimo hiše, ampak razvijamo unikatno rešitev) nemogoče predvideti čas/stroške razvoja, se s tem niti ne trudimo. Izvajalec bo tako ali tako najprej razvil za nas najbolj vredne rešitve (z vrha Product Backloga). Dejstvo, da bo za vse rešitve zmanjkalo denarja ni problematično, saj so na dnu Product Backloga problemi z manjšim poslovnim vplivom.
- Če si resnično želimo rešitve še preostalih problemov v backlogu, lahko razvijalcu odobrimo dodatna sredstva. V praksi se to ne bo zgodilo skoraj nikoli, saj se bojo v času razvoja pojavile nove poslovne priložnosti z višjo poslovno vrednostjo, ki se jih bo bolj splačalo razvijati kot omenjene "ostanke" z dna Product Backloga.
Pri Agilnih razvojni iniciativah, naročnik za razvoj alocira določeno količino sredstev in postavi okviren rok realizacije. Obseg (scope) še neobstoječe rešitve pa je na tej točki le ugibanje. Do neupravičenega okoriščanja s strani izvajalca ne bo prišlo, saj smo kot naročnik neprestano vključeni v razvojni proces v smislu potrjevanja idej, rešitev, prioritizacije, uporabniškega testiranja, iskanja novih idej, odgovarjanja na vprašanja razvojnikov in spremljanja razvoja na Agilnih ceremonijah. Da, govorim o tem, da za najboljši rezultat iniciative, Product Owner/Produktni Manager mora priti iz naročnikove organizacije. Na prvi pogled se ta zahteva zdi draga, a pomislimo koliko nas bo stala propadla produktna iniciativa.
Prestrašeni naročnik: “Ampak naš direktor ne bo nikoli odobril sredstev, če ne bo vedel kaj bomo za to dobili. Mi tako ne delamo. Naš sektor je preveč reguliran/kompleksen/specifičen.”
Tako je. Vaš direktor ima prav. In to boste verjeli dokler vam največji konkurent ne bo dokazal, da se motite.
Graduated Fixed-Price
Pogodba določa različne urne postavke glede na datum zaključka s strani izvajalca. Zaključek v tem kontekstu pomeni dosego poslovnega cilja naročnika.
Če izvajalec razvije rešitev predčasno, se mu urne postavke obračunajo po višji tarifi. Tako sta zadovoljna tako naročnik, ki je rešitev dobil predčasno, kot izvajalec, ki je ustvaril višjo dodano vrednost.
Če pa izvajalec zamuja, se njegovo (celotno) delo obračuna po nižji urni postavki. Tako se zaščiti naročnika pred pretiranimi stroški, izvajalca pa se vzpodbudi, da se drži rokov. Če je do zamude prišlo zaradi nepredvidenih okoliščin na strani izvajalca, bo ta svoje dodatno delo kljub temu dobil plačano, čeprav po nižji postavki. Tako se zmanjša možnost konflikta med deležnikoma, do katere bi prišlo, če bi od nekega trenutka dalje izvajalec za izpolnitev pogodbe, moral delati zastonj.
Za:
- Izvajalcu nudi vzpodbudo za hitrejše delo.
- Izvajalcu nudi vzpodbudo za kvaliteto, saj so “bug fixes” časovno potratni.
- Rizik je enakomerno razporejen med naročnika in izvajalca.
Proti:
- Standardi kvalitete (Definition of Done) morajo biti dobro definirani, da nebi prišlo do nesoglasij pri potrjevanju razvitih funkcionalnosti (Sprint/Iteration Review).
- V primeru, da je limita samo datumske narave, izvajalcu nudi skušnjavo, da neizkoriščene razvojnike “parkira” v dotični projekt.
Varianta te pogodbe je, da se plačilni razredi določijo po doseženih poslovnih ciljih. Primer:
Dodatni varnostni mehanizem
Med razvojem bo s strani naročnika (zaradi novo razkritih priložnosti), brez dvoma prihajalo do zahtev po spremembah – takšna je narava razvojnega dela. Da zaradi tega nebi prišlo do nesoglasij z izvajalcem, je v graduated fixed price koristno zapisati da:
- Se cenovni razred določi le glede na začetno določen obseg backloga
- Dodatno delo se obračuna po “Time & Material” principu
V takšnem odnosu izvajalec ohrani motivacijo za vključevanje novih zahtev med razvojnim ciklom, naročnik pa ohrani fleksibilnost razvoja, ki mu bo prinesla maksimalni ROI.
Cost Plus
Zloglasni tip pogodbe, ki pa je pod pravimi pogoji obvladljiv. Naročnik Izvajalcu poleg stroškov razvoja plača tudi fiksni mesečni ali kvartalni dodatek, ki je izvajalčev profit (neobvezno), ter dodatno nagrado za uspešno dosego cilja projekta.
Podkategorije te pogodbe so:
- Cost-Plus Fixed Fee: V naprej določena fiksna nagrada.
- Cost-Plus Incentive Fee (CPIF): Izvajalec prejme višjo nagrado, če doseže ali preseže zastavljene cilje.
- Cost-Plus Award Fee: Izvajalec prejme nagrado glede na potencialno subjektivne kriterije kot so kvaliteta, odzivnost, razširljivost, itd..
Za:
- V primeru dobro definiranih pogojev za nagrado, izvajalca motivira v učinkovitejši razvoj, saj se dodana vrednost nagrade na enoto časa običajno niža s časom razvoja.
- Vzpodbuja dobre prakse na strani izvajalca (refactoring, TDD,…), saj je motiviran za doseganje nagrad (če so te objektivno dovolj visoke).
- Primeren za razvojne iniciative z nejasno določenimi cilji in posledično številnimi zahtevami po spremembah.
Proti:
- Izvajalec nima močne motivacije za učinkovitost, saj več dela pomeni več zaslužka. Iz tega razloga se nagrada pogosto veže na določen faktor (čas, kvaliteta, NPS…).
- Če cilji, ki so osnova za nagrado, niso dobro definirani lahko povzroči medsebojno obtoževanje med deležniki.
- Potreben je večji nadzor s strani naročnika, saj pogodba zaradi sprotno pokritih stroškov razvoja, vzpodbuja manjšo transparentnost sodelovanja izvajalca z naročnikom. Temu se izognemo, z definiranjem načina sodelovanja (kolokacija, Product Owner je naročnikov zaposleni, izvajanje Agilnih ceremonij, itd.).
- Če projekt postane kompleksnejši, kot je bilo pričakovano na začetku, se izvajalec pogosto želi pogajati za višjo vrednost nagrade.
- Naročnik v naprej težko presodi okvirne stroške razvoja.
Varnostni mehanizmi
- Nagrade se tako kot pri graduated fixed price lahko vežejo na procent doseženih poslovnih ciljev.
- Koristno je določiti maksimalni obseg sredstev namenjenih za razvoj.
- Če zaradi slabe kvalitete število kritičnih napak preseže določeno mero, se izvajalcu lahko zniža dodatek ali nagrade za naslednje iteracije.
Target Price
Pogodba je podobna Cost Plus z dodatnimi omejitvami. Cilj projekta je določen kot napor, ki ga bo izvajalec vložil v iniciativo do nekega datuma. Za napor se določi minimalno (pogosto) in maksimalno število ur (zato Target Price). Končna nagrada upošteva stopnjo zaupanja in uspešnost sodelovanja med pogodbenima strankama. Če izvajalec doseže cilj predčasno in z manjšimi stroški kot so bili predvideni, se prihranek običajno razdeli na polovico med obe stranki v obliki dodatne nagrade.
V takšni pogodbi cilj iniciative ni nujno določen kvantitativno (20% povečanje prometa), ampak je lahko bolj inspirativen (novi načini kako povečati promet).
V Target Price pogodbi oba deležnika približno enakomerno delita tveganje.
Za:
- Vzpodbuja sodelovanje in aktivni scope management. Še posebej v smislu minimiziranja scopea samo na funkcionalnosti, z resnično pozitivnim ROI. Tako naročnik kot izvajalec sta namreč finančno motivirana za ohranjanje optimalnega scopea.
- Večja transparentnost dela. Posledica prejšnje točke.
- Naročnik in izvajalec si delita tveganje preko deljenega prihranka ali preko deljenega prekoračenja (pain-gain share).
- Target price ni fiksna meja. Omogoča sprejemanje novih zahtev, če imajo poslovno vrednost, ne da bi za to bilo potrebno podpisovati anekse.
Proti:
- Je primernejša za “kvalitativne” iniciative, ki ponudijo nove informacije o subjektu, generirajo nove prodorne ideje ali so študije izvedljivosti (feasibility study).
- Ob spremembi scopea, bo izvajalec pogosto zahteval zvišanje limite ur in zamik datuma zaključka.
- Ker cena za posamezno funkcionalnost ni fiksna, naročniki lahko postanejo preveč sproščeni, kar spodbuja scope creep.
- Takšna pogodba zahteva, da kupec v razvoju aktivno sodeluje. Če sodelovanja ni, izvajalec prevzame večino tveganja in model postane nepravičen.
Varianta Target Price pogodbe ima določena željeni (target price) in maksimalni strošek razvoja (cap). Dodatna nagrada se določa glede na limito željenih stroškov. Pod limito se prihranek med deležnika razdeli na pol, nad limito (do limite maksimalnega stroška), pa izvajalec nadaljuje delo s polovično urno postavko.
Money for Nothing and Change for Free
Tega tipa pogodbe se ni domislil Pink Floyd (vemo ker ni v rimah), ampak Jeff Sutherland, eden od avtorjev Agilnega manifesta. Govorimo o standardni Fixed Price pogodbi, ki vsebuje “Time & Material” za dodatno delo. Pogodba vsebuje tudi klavzulo “Change for Free”, ki naročniku pod pogojem, da aktivno sodeluje v vsaki iteraciji, omogoča reprioritizacijo backloga in zgodnji zaključek projekta. Če naročnik ne sodeluje v vsaki iteraciji, izgubi to možnost in pogodba se izvaja kot Fixed Price.
Zahteva je smiselna, saj Product Owner, ki je predstavnik stranke, edini lahko reprioritizira Product Backlog. Če naročnik v tej aktivnosti ne sodeluje, izvajalec nima dinamične usmeritve, ampak se mora zanesti na pogodbo. Reprioritizacija je brezplačna dokler obseg dela ostaja enak.
Naročnik ima tudi možnost predčasnega zaključka projekta, ko presodi, da ROI več ne opravičuje vložka. To je pri Agilnih projektih standardna praksa, saj so zahtevane funkcionalnosti v Product Backlogu razporejene po poslovni vrednosti. Ko so se gibamo nižje po backlogu, slej ko prej pridemo do točke, ko razvoj funkcionalnosti več ne opravičuje stroškov razvoja. V primeru predčasnega zaključka, naročnik izvajalcu plača 20% preostale vrednosti pogodbe.
Klavzula “Money for Nothing” izvajalca obvaruje pred nenadnim šokom prekinitve pogodbe in odpravi potrebo po cenovnem “bufferju” v predračunu.
Za:
- Primerna za okolja kjer je sodelovanje med naročnikom in izvajalcem dobro in kontinuirano.
- Omogoča sprotne spremembe scopea in predčasno terminacijo.
Proti:
- Možnost konflikta, če se ne definira minimalna angažiranost naročnika v razvojnem ciklu (Product Owner, Sprint Review,…).
Fixed Price Work Packages
Namesto, da bi se količina dela ocenjevala v celoti, se jo razdeli na manjše dele imenovane Work Packages. Izvajalec lahko prevzame v razvoj več paketov. Po realizaciji prvega paketa ima možnost pogajanja glede cene za izvedbo naslednjega. Na morebitno novo ceno vplivajo dotedanja dognanja glede zahtevnosti in identificirani riziki.
Z delitvijo dela na relativno majhne pakete, se zmanjša rizik precenjevanja ali podcenjevanja razvojnega napora. Izvajalčev rizik se omeji na paket, ki je trenutno v razvoju, naročnik, pa dobi bolj realistično oceno stroškov in potrebe po reprioritizaciji. Variacija tega tipa pogodbe se imenuje “Fixed-fee contract per iteration or story” – ime pojasni razliko.
Temelj za pakete je običajno Statement of Work (SOW) ki izvira iz Waterfall metodologije in je v Agilu redek.
Za:
- Naročniku omogoča sprotno reprioritizacijo paketov v skladu z dotedanjimi spoznanji in stroški (Backlog Refinement).
- Izvajalcu omogoča prilagajanje cene v skladu s sprotnimi spoznanji in na novo identificiranimi riziki.
Proti:
- Za kreiranje Work Packages, potrebujemo kar dobro idejo o tem kako bomo dosegli zastavljeni cilj. V Agilu je to redko. Rešitev bi bila, da partner v izvedbo prevzame samo eden ali dva paketa, medtem, ko se bojo nadaljnji paketi postopno formirali glede na dognanja že realiziranih paketov.
DSDM pogodba
Agile Business Consortium, ki je skrbnik DSDM metodologije je leta 2017 izdal trenutno verzijo “Agile Project Framework Agreement” vzorčne pogodbe.
Ta pogodba predvideva fiksno ceno projekta ob variabilnem obsegu (scope) in pogoju, da so vse “must have” funkcionalnosti razvite. Must have sta v tem kontekstu tako imenovani “feasibility” in “foundation” fazi. Nadaljnje faze se financirajo glede na ugotovitve prvih dveh faz.
Za:
- Kljub temu, da je napisana z mislijo na DSDM metodologijo, vsebuje večino elementov, ki jih mora upoštevati dobra Agilna pogodba.
- Celovita pogodba.
Proti:
- Vsebuje izraze “good faith” in “reasonable”, ki nimajo pravne teže. To težavo bi lahko rešila njihova zamenjava s konkretnimi merili (npr. “vsebina vsakokratnega sprint backloga”).
Opomba: DSDM je edini konkretni vzorec pogodbe v tem članku. Obstajajo tudi reference na LexisPSL, GDS DOS, Flexlite 0.1, Danish K03 in Norvegian PS-2000. Zanimivo je, da je dostop do teh vzorcev precej otežen.
Kombinirane pogodbe
To so pogodbe, ki vsebujejo elemente več zgoraj naštetih tipov v smislu odpravljanja njihovih pomanjkljivosti.
Par primerov:
- Graduated Fixed-Price pogodba s klavzulo Cost Plus, ki bi izvajalca vzpodbujala k doseganju višje kvalitete.
- DSDM pogodba prilagojena Kanban življenjskemu ciklu.
- Fixed Price Work Packages s Cost Plus klavzulo, ki bi izvajalca vzpodbujala k doseganju visoke kvalitete.
- Time & Material pogodba s Fixed Price Work Packages klavzulo, ki bi za različno zahtevne večje pakete znotraj iniciative, omogočala spremembo urne postavke izvajalca.
- Target Price pogodba za študijo izvedljivosti s Cost Plus klavzulo, ki bi izvajalca vzpodbujala k realizaciji prototipa rešitve.
- Money for Nothing Change for Free pogodba s Target Price klavzulo, ki bi omejila iniciativo na maksimalno investicijo neglede na ROI še nerazvitih funkcionalnosti.
Trendi in priporočila za Agilne pogodbe
Če povzamemo osnovne razlike med tradicionalno in Agilno pogodbo:
Pravniki v tem kontekstu ločijo dva tipa pogodb:
- Pogodbe, ki so namenjene pogajanju. Taka pogodba zagotovi produktivno sodelovanje tekom projekta.
- Pogodbe ki so namenjene tožbi. Se uporabi za zmanjševanje škode – “When shit hits the fan”.
Mislim, da je potrebno Agilne pogodbe sestavljati predvsem v duhu prvega tipa pogodb. Določbe drugega tipa, pa se zapiše z namenom omejevanja večjih odklonov. Pri tem moramo paziti, da ne ustvarimo “spora glede sporov” z izrazi kot so npr. “v dobri veri”, “maksimalni napor” ali ”dobra industrijska praksa”.
Še nekaj značilnosti, ki naj bi jih upoštevali novi tipi Agilnih pogodb:
- Vsebujejo vizijo.
- Vsebujejo cilj projekta v smislu poslovnega rezultata. Včasih to ni mogoče (preveč neznank).
- Dopuščajo fleksibilnost implementacije (roadmap).
- Opisujejo okvirno strukturo projekta (Scrum, Kanban, LeSS,…), vloge ter odstopanja od standardov (npr. uvedba integracijske skupine v LeSS framework).
- Dopuščajo scope change znotraj enakega obsega dela in z dodatki za nepredvideno delo.
- Določajo kvaliteto (Definition of Done) in dopuščajo njeno evolucijo.
- Vsebujejo stroškovni obseg ali stroškovno limito.
- Opisujejo procese za scope in cost management.
- Opisujejo način sodelovanja naročnika in izvajalca, odločitvene in eskalacijske poti.
- Opisujejo točke preverjanja izvedbe (Sprint Review, sodelovanje Product Ownerja).
- Omogočajo možnost zgodnje prekinitve pogodbe oz. njeno podaljšanje.
V zadnjem času sem zasledil poizkuse izvedb Agilnih iniciativ brez formalne pogodbe med naročnikom in izvajalcem. Tak odnos temelji na visoki stopnji zaupanja, pojavlja pa se predvsem v Scaled Agile okoljih večjih organizacij, kjer na ta način med seboj sodelujejo teami različnih organizacijskih segmentov. Pravtako se pojavljajo med partnerskimi organizacijami, ki so medsebojno že trdno povezane (ali soodvisne) v nekem segmentu.
Prilagajanje naročnikovih procesov
Poudaril bi še naslednje. Če je organizacija, ki se odloči za Agilni outsourcing, v osnovi hierarhična in izvaja svoje projekte po waterfall metodologiji, bo morala nekaj svojih procesov prilagoditi Agilnemu izvajalcu. V mislih imam predvsem funkcije tržnih raziskav in backlog prioritiziranje, ki jih izvaja strankin produktni manager, ter omogočanje feedbacka razvojnikom s strani končnih uporabnikov (iteration review). Dopuščanje neposredne komunikacije razvojnikov s končnimi uporabniki pravtako ni slaba ideja.
Upam, da vam bo članek v pomoč. Zagotovo pa s to temo še nismo končali. Agilne pogodbe
Članek je tudi dopolnilo gradiva za tečaj Product Owner, kjer nam v poglavju Agile Budgeting običajno zmanjka časa za detajlni pregled pogodb.
