Avatus muutustele on „Agiilse ülemineku” eeltingimus (pilt Julia Lingertatilt)

Kuidas saada agiilseks - agentuuri juhend

Ideaalsete tingimuste loomine paindlikele kliendiprojektidele

See artikkel on saadaval ka saksa keeles.

Viimase paari aasta jooksul on “vilgas” agentuurimaastikul muutunud üha populaarsemaks sõnad. Vaevalt on üksainus ettevõte, kes ei tunnusta vildakat tööd. Aga mida see tegelikult tähendab? Kuidas saab öelda, kui paindlik ettevõte tegelikult on? Kui keegi töötab sprintides, kas see tähendab, et inimene on juba vilgas? (Vastus: ei.)

Aperto Move'is oleme viimase kahe ja poole aasta jooksul pidevalt analüüsinud ja täiustanud oma töömeetodeid, lükates oma visiooni töökohal liikuvast paindlikust edasi. Üks vaieldamatuimaid tõdemusi on olnud see, et liikumine agiilsesse nõuab nii aega kui ka kogemusi. Üleminekut lihtsalt ei saa muuta agariks. Ehkki me ei ole veel seal, kus tahaksime olla, on paranemine selgelt märgatav.

Agiilsete meetodite rakendamine agentuuris on kokkuvõttes keerulisem kui näiteks tootearenduses; kuna üks loob tooteid erinevatele klientidele, kus tingimused võivad projektide vahel oluliselt erineda. Seetõttu on raske uskuda, et iga amet näib ühtäkki vilgas. Õnneks on tegureid, mis aitavad hõlpsalt kindlaks teha, kui kaugele on ettevõte jõudnud oma elujõulisuse poole.

Käesolevas artiklis esitatud nõuanded põhinevad stsenaariumidel, mis on enamiku ametite jaoks tavalised, mis on tekkinud meie igapäevases töös ja lahendatud, kui oleme need probleemidena kindlaks teinud. Need pole kõikvõimalikud lahendused, vaid pigem õppetükkide kogum, mis meile kõige paremini sobib.

1. Täpsustage terminoloogiat

Kiire tutvustamisel on ülioluline, et kõik ettevõttes olevad inimesed mõistaksid terminit ühtemoodi, vastasel juhul võib oht sattuda ohtlikku valesti. Olen kohanud inimesi, kes eksivad paindliku lähenemisviisi tõttu, kui nad loobuvad kõigist kontseptsiooni etappidest, planeerimisest ja regulaarsetest kohtumistest projekti kasuks ja näevad, mis juhtub. Pole raske ette kujutada, et selline projekt oli kõike muud kui lihtne.

Teised on lihtsalt Scrumist kuulnud ja tunnevad selle suhtes teatavat vastumeelsust, lükates selle välja kui "midagi arendajatele", mis lämmatab loomeprotsessi. Enamasti pärinevad need avaldused inimestelt, kes pole ise Scrumi ega vilgasid meetodeid uurinud. Lisaks ei oska need, kes seda ei tunne, sageli eristada agiilsuse ja Scrumi vahel ning liigitada need ühte ja samasse kategooriasse.

Scrum ja vilgas pole samad

Scrum on raamistik, mis määratleb konkreetsed reeglid, rollid ja tööprotsessid tarkvara arendamiseks. Üks näide on määratleda ajavahemikud, mille jooksul töötav toode kohale toimetatakse (nn sprintsid). Scrumi juurutamine aitab kaasa paindlikule tarkvaraarendusele, mistõttu peetakse termineid sageli sünonüümideks, kuid need pole seda.

“Agiilne” on seevastu mõtte- või kultuuriviis, mis sisaldab endas palju enamat kui puhtalt seda, mida Scrum teeb. Agiilset kultuuri määratlevad põhimõtted on välja toodud Agile-manifestis ja need on kujutatud järgmises videos:

Scrum on ainult üks võimalik lähenemisviis vilgaste põhimõtete järgimiseks. Scrumi kasutamata võib olla ka vilgas. Teisest küljest ei tähenda see, et Scrumi reeglitest kinni peetakse, seda, et keegi tegelikult vilgas töötaks.

2. Hüvasti jätmine projektijuhi rolli eest (öelge tere vilgastele rollidele)

Scrumis on määratletud järgmised rollid:

  • Toote omanik
  • Scrum Master
  • Arendusmeeskond
  • Muud sidusrühmad, näiteks lõpptarbija või kliendi poolel osalejad

Muid rolle pole ega ole ka vajalik. Selles seadistuses pole enam vaja klassikalist projektijuhti. Ta ainult takistaks seda protsessi, kuna kõik projektijuhi varem läbi viidud ülesanded on nüüd hõlmatud ülaltoodud ametikohtadega. Projekti õnnestumise eest ei vastuta enam üks inimene, vaid kogu meeskond.

Iga projektis eksisteeriv täiendav roll, mis seisab Scrumi meeskonna ja kliendi vahel, on takistuseks meeskonna ja kliendi vahelisele otsesele ja efektiivsele suhtlusele.

Võtke rolle ja vastutust tõsiselt

Kui kellelgi pole vaja projektijuhti, kas poleks mõtet tööle võtta varasemaid projektijuhte Scrum Masteri ja tooteomaniku kombineeritud rollis?

Ei. Ühest küljest kaasnevad nii Scrumi kapteni kui ka tooteomaniku rollidega piisavalt ülesandeid, mille täitmine tooks kaasa ühe rolli unarusse jätmise. Lõppkokkuvõttes on kahel rollil vastandlikud huvid. Tooteomanik on pidevas kontaktis kõigi sidusrühmadega ja tagab, et õige toode tarnitakse parima kvaliteediga. Muu hulgas peab Scrum Master hoolitsema selle eest, et meeskond ei oleks üle töötatud ega segatud. Seega pole Scrum Masteril mingit pistmist toote endaga.

Veel hullem idee oleks Scrum Master täielikult välja jätta. Ilma tegutseva Scrum Master'ita pole mingit rolli tagada, et meeskond töötaks tulemuslikult, täidaks tähtaegu või õpiks tagasiulatuvalt ning muutuks efektiivsemaks. Lühidalt, need on need, mis tagavad projekti sujuva läbiviimise. Meie kogemuste kohaselt on see eriti oluline roll muutuvate klientide, sidusrühmade ja tingimustega agentuurikeskkonnas, kuna Scrum Master võtab ka kliendi juhendamise rolli.

See artikkel selgitab Scrum Masteri ja klassikalise projektijuhi erinevaid funktsioone hõlpsasti mõistetava liikluse analoogia osas:

3. Enam ressursside kavandamist ei toimu (kehtestage selle asemel tõmbepõhimõte)

Agentuurides töötatakse sageli üheaegselt läbi mitu projekti erinevatele klientidele, mis muudab töö tõhusa jaotamise kõigi töötajate vahel väljakutseks.

Klassikaline agentuuriline lähenemisviis on ressursside kavandamine: projektijuht loob plaane mitmeks päevaks või nädalaks ette ja määrab töötajad vastavalt projektidele või ülesannetele. See nõuab palju aega kavandamiseks ja koordineerimiseks ning tulemuseks on paindumatus, kuna see toimib eeldusel, et kõik eraldatud ajaprognoosid ja plaanid on täidetud.

Kogemus õpetab meile, et tegelikult ei tule sellised plaanid kunagi teoks: oluline kohaletoimetamine viibib, töötajad haigestuvad või tekivad muud ettenägematud asjaolud, mille tõttu võtavad üksikud tööülesanded oodatust kauem. Tagajärjed on ebaühtlane tööjaotus kolleegide vahel, suurem stress ja ületunnitöö.

See niinimetatud tõukepõhimõte (kuna töötajatel on üksikud ülesanded neile peale surutud) pole seetõttu optimaalne. Niisiis, kuidas jaotatakse tööd ilma projektijuhita agiilses tähtkujus? See küsimus nõuab teistsugust lähenemist:

Tõmbepõhimõte

Agiilne töö põhineb nn tõmbe mentaliteedil. See tähendab, et töötajad otsustavad ennetavalt, milliseid ülesandeid nad soovivad võtta. Selleks, et see toimiks, tuleb eelseisvatest ülesannetest ja nende edenemisest läbipaistvalt teada anda.

Ideaalses olukorras ei toimu see ainult projekti tasandil, vaid kõigi tulevaste ettevõttesiseste ülesannete puhul. See hõlmab ulatuse hindamist, esitluste loomist, töötubade ettevalmistamist, intervjuudes osalemist või isegi selle artikli kirjutamist. Seda saab teha näiteks Kanbani tahvli abil:

Tõmbamispõhimõte aitab tagada töötajate ühtlase jaotuse töötajate vahel, kus kõigil on vabadus otsustada iseseisvalt, kui nad on võimelised oma ülesannetega hakkama saama. See aitab välistada teatud töötajate ületöötamise võimaluse.

Tõmbepõhimõtte toimimiseks peavad olema täidetud järgmised tingimused:

  • Pidev suhtlemine on ülioluline. Aperto Move'is arutatakse projekti staatust kolm korda nädalas juhatuses
  • See eeldab initsiatiivi omavatelt inimestelt, selle asemel, et oodata, kuni teised ütlevad neile, mida teha
  • See soosib tasaseid hierarhiaid ja nõuab valmidust neid rakendada
  • Ettevõtte juhtkonnal peab olema usaldus oma töötajate vastu, et nad saaksid suurema vastutuse võtta
  • Individuaalsed ülesanded ja projektid peavad olema selgelt eristatud. Projekte ei vea ükski inimene, vaid meeskond. Seda uuritakse lähemalt järgmises jaotises.

4. Moodustage stabiilsed meeskonnad

Agentuurides on tüüpiline töötada samaaegselt erinevate klientidega ja kiireloomulised ülesanded (nt ulatuse hindamine, kohad või veaparandused) tekivad sageli lühikese etteteatamisega. Seetõttu luuakse projektimeeskonnad sageli vastavalt olemasolevale kättesaadavusele. Seda tüüpi ressursside kavandamine hoiab tõhusalt ära paindlikke projekte.

Agiilsed meeskonnad peaksid olema stabiilsed ja ideaalis end leidma. Ainult lähedased meeskonnad saavad optimaalselt areneda ja oma tempot säilitada või isegi kiirendada, õppides üksteiselt, koordineerides oma protsesse ja suhtlemist ning tuvastades ja lahendades probleeme tagasiulatuva analüüsi abil.

Võistkonnad saavad probleeme tuvastada ja lahendada regulaarse tagasivaatamise kaudu (pilt Andreas Plathilt)

Vältimaks tõhusate koos töötavate kolleegide meeskondade häirimist ja välistades seeläbi kõik õppimis- ja rutiinsed mõjud, ei tohiks eelseisvaid projekte kavandada, pidades silmas üksikisikuid, vaid pigem stabiilseid meeskondi.

Ebareaalne on aga arvata, et terve distsipliinidega agentuuri muutmine stabiilseteks ja tasakaalustatud meeskondadeks võib toimuda üleöö. On mõeldav, et mitte kõik ei taha alaliselt töötada samas meeskonnas. Seega on ülioluline leida tasakaal, mis toimiks kõigile hästi.

5. Koostage paindlikke ettepanekuid

Klassikaline, klientide ja agentuuri vahel lihtsustatud pakkumisfaas toimub tavaliselt järgmisel kujul: Kliendil on toote jaoks konkreetne idee ja ajakava selle valmimiseks.

Seejärel tutvustab klient agentuurile nõudeid (võib-olla koos pigiga) ja küsib ettepanekut, milles täpsustatakse selle toote arenduse kindel hind. Enda kaitsmiseks kulutavad mõlemad pooled ettepaneku väljatöötamiseks märkimisväärset tööd, et vältida võimalikku valesti suhtlemist.

Kliendi vaatevinklist näib see tavaliselt mõistlik lahendus: nad teavad, mida ja millal saavad, mida saavad.

Nõuded muutuvad

Enamik kliente ei tea praegu seda, et nad tahavad projekti lõpuks sageli midagi väga erinevat, nagu nad alguses tegid.

Kuna ettepanekus on kõik täpselt määratletud, on peaaegu võimatu midagi hiljem projektis muuta ilma läbirääkimisteta, näiteks:

  • muud omadused muutusid vahepeal olulisemaks
  • soovitud projekt pole enam tehniliselt teostatav
  • kasutajatestid näitasid, et tootest on valesti aru saadud või et sellel pole mõtet
  • konkurent on loonud sarnase toote, mis nõuab strateegilist pöördepunkti

Sel juhul pole prioriteetide ümberhindamine lihtne, kui ettepanekus täpsustatakse vana, muudetud reguleerimisala.

Seda tüüpi ettepanek õõnestab ka teisi liikuvuse olulisi aspekte. Toote pidev ja koostööpõhine täiustamine on palju raskem, kuna ettepaneku vormistamiseks tuleb toode alguses selgelt määratleda. See toob kaasa tüüpilise juga töövoo. Sprindi planeerimine, sealhulgas pokkeri kavandamine, muutub sama mõttetuks, kuna lõplik tähtaeg ja edastatav on juba määratletud.

Kui ulatus, tähtaeg ja hind on juba alguses paika pandud, pole enam mõtet proovida ja rakendada sellist paindlikku raamistikku nagu Scrum.

Sel juhul ei saa enam kasutada paindliku kohaletoimetamise peamisi eeliseid, kuid sellegipoolest on Scrumi koosolekute lisakulud, mis ei anna tegelikku väärtust. Seda protsessi nimetatakse ka “pseudo Scrum”.

Vaja on teist tüüpi ettepanekuid

On mõistlikum maksta tehtud töö eest (nn ajalised ja materiaalsed lepingud), selle asemel et määratleda ettepanekus täpsed tulemused. Ainult sel juhul on võimalik projekti teostada paindlikult.

Kui palju ja mida klient oma raha eest saab, otsustab ta projekti käigus ise, hoides nõuete loetelu ajakohasena ja seades koos meeskonnaga tähtsuse järjekorda.

Agiilsete ettepanekute koostamine nõuab harjutamist (Allikas: https://unsplash.com/?photo=OQMZwNd3ThU)

Selleks, et klient saaks aimu, mida ta võib oodata, võib anda umbkaudse hinnangu, kui palju on antud aja jooksul saavutatav või kui kaua võtab aega, kuni teatud nõue on täidetud. Mida kauem meeskond on koos töötanud, seda täpsemaks see hinnang muutub, kuna meeskonna üldist tempot või kiirust on lihtsam mõõta. See on veel üks põhjus, miks eelistatakse töötada stabiilsete meeskondadega.

Sellegipoolest on ettepaneku koostamine endiselt paindliku ülemineku kõige raskem element. Vaevalt soovib üksik klient, kes pole veel omandanud kogemusi tundlikus keskkonnas, sõlmida tähtajatu lepingu. Et veenda neid selle teenetes, on esmatähtis demonstreerida oskusi ja luua esmalt usaldus kliendi vastu.

Meie kogemusest saab selle väljakutse hõlpsalt ületada niipea, kui üks on koos vilgas projekti lõpetanud. Siis räägib projekti protsess iseenda eest; kiirete ja käegakatsutavate tulemuste saavutamine iteratiivse töö, tiheda koostöö ja lühemate tagasisidetsüklite kaudu, mis on kliendi kavandatule palju lähedasemad kui tüüpilistes jugaprojektides.

Agiilsete ettepanekute, näiteks selle raamatu kohta, on saadaval palju kasulikku kirjandust:

6. Kaasake projektimeeskond nii vara kui võimalik omandamisfaasi

Agentuurides on hanke- ja pakkumisfaas sageli projekti elluviimisest eraldatud. Uute projektide eest vastutab uus ärimeeskond ja projektimeeskond puutub üksikasjadega kokku alles rakendusetapis, suurendades konfliktide tõenäosust.

Ettepanekute etapp võib juba olla ülioluline projekti õnnestumise kindlakstegemisel. Seetõttu on oluline, et vilgas meeskond kaasataks kommunikatsiooni võimalikult varakult.

Selle tulemusel saab suhteliselt varakult hinnata, kas paindlik rakendamine on elujõuline ja kui palju selleks aega võib oodata. Ajakulu, nt Scump-projektis nõutavate sprintide arvu saab meeskond ise hinnata ainult siis, kui ta teab projektist nii palju kui võimalik.

Vahel tuleb projektitaotlusi rohkem, kui on võimalusi nende kallal töötada. Tõmbepõhimõtte rakendamiseks ja sobivaima projekti valimiseks peab meeskond võimalikult palju teadma kõigi pooleliolevate projektide kohta. Alles siis saavad nad teha teadliku otsuse ja integreerida uued projektid mõtestatult praeguste projektidesse.

Uue projekti alustamisel peaks meeskond võimalikult kiiresti tundma kõiki sidusrühmi ja nende nõudeid, et pakkuda parimat kvaliteeti pakkuvat õiget toodet. Üks tõhus meede selle saavutamiseks on seminari korraldamine meeskonna ja kliendi sidusrühmadega.

Lisaks on oluline edastada kliendile vilgasid väärtusi, tuvastada esmane kontaktisik ja selgitada üksikasjalikult koostööprotseduuri.

7. Unustage teenusepakkuja roll (ja tehke koos oma kliendiga meeskond)

Kliendi ja teenusepakkuja suhe on kahjulik, kuna see põhineb alati eeldusel, et klient on sõlminud lepingu ja ootab konkreetset tulemust. Projekti edukas tulemus, mis rahuldab kõiki osapooli, nõuab tavaliselt kõigi osapoolte tööd, eriti regulaarset üksteisega suhtlemist.

Eduka vilgas projekti oluline eeltingimus on samal tasemel suhtlemine. See tähendab, et klient ja agentuur käsitlevad üksteist ühtse meeskonnana, töötades koos projekti kallal ning tehes kindlaks ja hinnates üksteise tugevusi. Agentuur on tavaliselt strateegia, kasutajakogemuse, disaini ja tehnilise teostuse ekspert; klient aga seevastu tunneb nii enda sisemisi protsesse ja nõudeid kui ka oma sihtrühma. Ainult siis, kui seda teavet jagatakse, saab luua tõeliselt kasutajale suunatud toote, mis rahuldaks kõiki sidusrühmi.

Selleks on vaja, et kliendi poolel oleks määratud kontaktisik, kes on vastutav projektiga seotud küsimustele või saab agentuurile pakkuda kogu puuduvat materjali. Mitte iga klient ei saa ega taha investeerida nii palju aega ühte projekti, kuna nende enda sisemised tööprotsessid seda ei võimalda.

Meie kogemused näitavad, et kliendid märkavad juba varakult, kui palju kiiremini saavad nad vilgas koostöö kaudu kvaliteetseid tulemusi. See vastab nende ootustele ja nad on valmis aega investeerima.

8. Andke ruumi meeskonnatööks

Agile olemine tähendab tööd interdistsiplinaarselt ja pideva suhtlemisega. See toimib kõige paremini, kui vilgas meeskond istub koos, mis aitab nende tööd hõlpsalt koordineerida. Ideaalis peaks igal meeskonnal olema oma ruum, kus nad saaksid häirimatult töötada, minimeerides samas teiste häirimist, nt kui arutatakse kujunduse või funktsioonide üle.

Agiilsed meeskonnad peaksid saama töötada segamatult (Allikas: https://unsplash.com/photos/5T6lSk2uI1A)

Agentuurid maalivad sageli erinevat pilti: töötajate rühmitamine vastavalt nende erialadele. See tähendab, et kõik disainerid istuvad ühes kontorinurgas, arendajad teises nurgas ning testijad ja kontohaldurid sageli erinevates ruumides. Ehkki see võib distsipliiniga seotud vahetuse osas mõttekas olla, raskendab see projekti meeskonnas suhtlemist. Üksteise kirjutamine on võimalus, kuid see võtab palju kauem aega kui otse üksteisega rääkimine.

See muutub veelgi raskemaks, kui kõik meeskonna liikmed ei asu samas asukohas. Kõik teavad, kui halvad on telefoni- või videokonverentsid, ja kui te pole varem pidanud neid kannatama, on soovitatav see video:

9. Kaaluge iga distsipliini ja kogu projekti protsessi

Kuna Scrum sündis tarkvaraarendusest, võib tunduda otstarbekas projekti tehnilist aspekti teostada ainult araalselt, jättes loomingulise etapi puutumata. Sellega saavutatakse siiski suhteliselt vähe, sest juga struktuur lahendatakse alles projekti lõpus.

Klassikaline jugaprotsess põhineb konkreetsete tulemuste kinnitamisel

Oletame, et vilgas meeskond koosneb üksnes arendajatest; kliendi veebisaidi kontseptsioon ja kujundus on juba valmis, kuid arenduse keskel selgub, et olulisi riike pole veel määratletud ega kujundatud ning loominguline meeskond tegeleb juba oma järgmise projektiga. Mis nüüd? Kas tuleks inimesi teistelt projektidelt ära võtta? Kas jätkata mittetäieliku toote väljatöötamist? Ei ole muud lihtsat vastust kui kõigi asjakohaste erialade kaasamine agiilsesse tööprotsessi algusest peale.

Regulaarne vahetus projektimeeskonnas parandab toote kvaliteeti (Allikas: https://unsplash.com/photos/gN_nIUnjYJI)

Tagasiside, tagasiside, tagasiside

Tohutu tugevus ja oluline põhjus, miks agiilselt väljatöötatud tarkvara kvaliteet on parem kui klassikalise projektihalduse korral jugaprojektidel, on interdistsiplinaarne koostöö ja toodete korduv täiustamine, mis põhineb varajasel ja regulaarsel tagasisidel kõigi sidusrühmade vahel.

Lihtsamalt öeldes tähendab see: kõik vaatavad projekti igas etapis kõik üle.

  • Klient ja kogu meeskond annavad tooteomanikule tagasisidet kasutaja lugude kohta
  • KÜ disainerid annavad tagasisidet kaadritele ja tehnilisele teostusele
  • UX-disainerid annavad tagasisidet kasutajaliidese kujunduse ja tehnilise teostuse kohta
  • Esiosa arendajad annavad tagasisidet kaadritele, kasutajaliidese kujundusele, taustaprogrammi liidestele ja vajaduse korral taustprogrammi rakendamisele
  • Taustrakenduste arendajad annavad tagasisidet kaadritele, kasutajaliidese kujundusele ja kasutajaliidese rakendamisele
  • Kvaliteedi tagamine (QA) annab tagasisidet kaadritele, kasutajaliidese kujundusele ja tehnilisele teostamisele
  • Kasutajad annavad tagasisidet kasutatavuse testide kaudu kogu projekti faasis (juhtraamid, kujundusprototüübid, klõpsutekked, juurutamine)
  • Klient annab sprintide ülevaatekoosolekutel tagasisidet toote juurdekasvu kohta
Agiilses koosseisus töötab meeskond pigem koos kui järjestikku

Regulaarne tagasiside on agiilses arenduses kõige olulisem vara ja see tagab, et toodet arendatakse tasemel, mis rahuldaks kõiki sidusrühmi. Loomulikult toimib see ainult siis, kui kõik on igas projektifaasis kaasatud.

10. Ärge oodake, et kõik toimiks kohe (tehke vigu ja õppige neist)

Loodetavasti andsid eelmised lõigud edusamme, et mitmel tasandil on vaja läheneda erinevale lähenemisele neile, mis on ilmselt aastate jooksul välja töötatud ja välja kujunenud. See teeb veelgi olulisemaks mõistmise, et liikumine muutlikuks muutumisele on protsess, mitte tingimata kerge, ega ka kindla lõpuga protsess.

Eespool käsitletud meetmete rakendamine ei taga automaatselt üleminekut paindlikkusele. Samamoodi ei piisa ainult tehniliste aspektide, näiteks Scrumi vastuvõtmise rakendamisest. Palju olulisem on muuta ettevõtte kultuuri ja luua ühine, paindlik väärtussüsteem kõigil hierarhilistel tasanditel.

Oleks naiivne eeldada, et sellised põhimõttelised muudatused saab tehtud viivitamatult ja segamatult. Ettevõtte protsessides toimuvaid muutusi võib käsitleda ka kui agiilset projekti ja neid saab korrata.

Lõppkokkuvõttes tähendab see, et ei tohiks proovida kõike korraga muuta, vaid tuleks rakendada üks meede korraga. Sel viisil õpitakse, mis töötab, mis mitte ja mida saab parendada. Vale oleks pidada ühte mõõtu, mis ei tundu õige, lihtsalt sellepärast, et raamat või ajaveeb on seda soovitanud.

Väline juhendamine võib olla abiks ka õigete mõtteprotsesside käivitamisel, kuid siiski ei saa loota kiirparanduse leidmisele, mis muudab selle ootamatult paindlikuks.

Sama oluline on luua sisemine teadmiste ja kogemuste vahetamine ning leppida kokku ühises lähenemisviisis. Selle saavutamiseks on kasulik korrapäraselt tutvuda Agiilse manifesti kaheteistkümne põhimõttega ja vaadata üle, mil määral on üks ettevõte need juba vastu võtnud:

Meie meeskonnas on parimaks lahenduseks osutunud Scrumi raamistiku juhiste range järgimine. Iga kord, kui nendest protsessidest kõrvale kalduti, tõi see kaasa tüsistusi ja rohkem pingutusi. See ei pea aga nii olema kõigi puhul. Iga ettevõte peab ise leidma, mis kõige paremini töötab.

Järeldus

Juba enne kliendiprojekti algust võivad teatud standardsed agentuuritingimused ohustada või muuta vilgaste projektide edu isegi võimatuks. See on koht, kus kõigil tasemetel ja kõigil erialadel on vaja uut mõtteviisi, mis eeldab muudatusi, mida ei saa üleöö rakendada.

Selles artiklis esitatud märkused võivad olla juhiseks, kuidas tundlike projektide kavandamisel tekkinud olukordi ja probleeme enne nende algust ära tunda ja arutada.

Millised on teie kogemused sellel teemal? Kas teate muid asjaolusid, mis muudavad agiilsed protsessid keeruliseks? Andke meile sellest teada selle artikli kommentaaride osas.

Lisalugemist

Aperto Move - IBM-i ettevõte on Berliinis asuv digitaalsete ja mobiiliteenuste agentuur, kus töötab umbes 30 töötajat. Kuidas sinuga on?

Jälgi meid: apertomove.com / Facebook / Twitter