Scrum

Si e shpëtoi Scrum Sentinel

Ishte metoda e vjetëruar (kryesisht e bazuar në letër) me të cilën FBI menaxhoi të dhënat e tyre që i pengoi ata të lidhnin pikat që mund të kishin shmangur 11 shtatorin. Në atë kohë, një departament pyeste veten pse kaq shumë të huaj po merrnin mësime fluturimi, një departament tjetër raportoi hyrjen e aktivistëve të ndryshëm të Al Kaedës në vend dhe një i tret ngriti dyshime për një person specifik. 

Fatkeqësisht, ky informacion mbeti i izoluar dhe asnjë analist nuk ishte në gjendje t’i qaset. Sipas Komisionit të 11 shtatorit, sistemi IT i FBI-së ishte i pamjaftueshëm për situatën. Që atëherë, ka pasur përpjekje të ndryshme për të zgjidhur problemin, duke përfshirë Virtual Case File, i cili kushtoi 170 milionë dollarë: asnjë rresht i vetëm kodi nga ai sistem kompjuterik nuk është përdorur ndonjëherë. Më pas, në vitin 2005, ishte radha e Sentinels (me vlerë 541 milion) i cili supozohej të fillonte dhe të funksiononte deri në vitin 2009. Në vitin 2010 Jeff Johnson u thirr për të rregulluar situatën: 405 milionë dollarë ishin shpenzuar tashmë, vetëm gjysma e programit ishte zhvilluar dhe 6-8 vjet punë shtesë plus një 350 milionë dollarë të tjera u vlerësuan si të nevojshme për ta hequr atë.

Nuk ishte fajtor cilësia e punës së deritanishme, por mënyra se si ishte bërë, mënyra e tyre e punës ishte shkaku. Projekti ishte organizuar sipas metodës së ujëvarës, bazuar në grafikët e shkruar nga krijuesi i tij, Gantt, të cilat u hartuan për herë të parë në vitin 1910. Listat e Gantt u përdorën për herë të parë për të furnizuar trupa për gjeneralin Crozier gjatë Luftës së Madhe. Në thelb, ne kaluam nga llogoret e luftës në dronët e luftës, dhe megjithatë prisnim të ndërtonim sistemin e IT të FBI-së me një metodë të shekullit të 20-të.

Kur metoda e ngadalëson projektin

Problemi me Sentinel ishte se gabimet e reja vazhdonin të shfaqeshin përpara se të mund të rregullonin të vjetrat. Projekti nuk ishte në shpejtësinë e duhur.

Jeff Johnson dhe CIO i FBI-së, Chad Fulgham, vendosën të shpëtonin situatën duke e sjellë projektin “in-house” dhe duke e bërë vetë. Ata identifikuan 9 probleme kryesore dhe u fokusuan në to, por më e rëndësishmja, ata vendosën për një ndryshim në menaxhim. Menaxherët donin dy gjëra: kontrollin dhe parashikueshmërinë. Kjo çoi në përpjekje të mëdha planifikimi dhe përpjekje të panevojshme për të shmangur ndryshimin, ata donin të dinin të panjohurën. Muaj kohë dhe burime u harxhuan kot.

Scrum përqafon pasigurinë dhe kreativitetin. Në thelb ai thotë: filloni një projekt dhe kontrolloni atë shpesh dhe në intervale të rregullta, sigurohuni që ai po shkon në drejtimin e duhur dhe shikoni nëse mund të gjeni një mënyrë për t’i bërë gjërat të ecin më shpejt. Ky është i ashtuquajturi cikli “Inspektoni dhe përshtatni. Herë pas here, ndaloni së bërë atë që po bëni, rishikoni atë që keni bërë dhe shikoni nëse është ajo që duhet të bëni dhe si mund ta bëni më mirë. Scrum mund të jetë përdoret me sukses për të ndërtuar një makinë, për të menaxhuar një lavanderi ose për të dërguar një raketë në hapësirë. 

Le të kthehemi në FBI. Dokumentet për specifikimet e kërkuara u grumbulluan lart. Johnson dhe Fulgham i vendosën ato në rregull dhe vendosën për prioritetet që do të ndihmonin të nxirrnin më të mirën në projekt. Në vjeshtën e vitit 2010, FBI tha se ata mund të përfundonin Sentinel brenda një viti duke aplikuar një “metodologji të shkathët, me më pak punonjës dhe duke shpenzuar 20 milionë dollarë.

Scrum është metoda që vë në praktikë vlerat e shkruara në “Manifestin e shkathët”, para së gjithash: përgjigjuni ndryshimeve në vend që të ndiqni një plan të caktuar. 

Është një mënyrë pune që pastron rrugën nga çdo pengesë, një ide që vjen nga Taiichi Sistemi i Prodhimit Toyota i Ohno, koncepti kryesor i të cilit në procesin e zhvillimit është fluksi. Procesi i prodhimit duhet të rrjedhë shpejt dhe një nga detyrat kryesore që ka menaxhmenti është të identifikojë çdo pengesë që mund t’i dalë në rrugën e këtij fluksi.

Për të përfunduar Sentinel, Jeff Johnson e organizoi punën në cikle dy-javore. Në Scrum, këto korniza kohore quhen Sprint; në fillim të çdo Sprint mbahet një mbledhje, gjatë së cilës grupi i punës vendos se çfarë do të bëhet në dy javët në vijim. Këto aktivitete janë nxjerrë nga një listë prioritetesh dhe më pas ato shfaqen në një mur në mënyrë që të gjithë t’i shohin ato. 

Në fund të çdo Sprint, ekipi mblidhet për një të ashtuquajtur takim Demo, gjatë të cilit ata tregojnë punën që është bërë në mënyrë që të mund të kontrollojnë nëse po ecën në drejtimin e duhur. Johnson mendonte se Demo, që do të thotë demonstrimi i përparimit të çdo aktiviteti të caktuar, ishte elementi më i fuqishëm në “shpëtimin” e Sentinel: askush nuk besonte se me vetëm 5% të buxhetit dhe vetëm në 20 muaj, ekipi po arrinte atë që nuk kishin arritur të arrinin me 90% të buxhetit në 10 vjet.

Sapo filloi, ekipi e rriti shpejtësinë e tij trefish: ata kishin kuptuar se çfarë po i ngadalësonte dhe në çdo cikël të ri ata ishin në gjendje të hiqnin më shumë pengesa nga rruga e tyre. Në korrik 2012, Sentinel u lançua. Efekti që pati në të gjithë punën e FBI-së ishte kolosal.

Një menaxhim i përditësuar me botën gjithnjë në ndryshim

Bota po ndryshon dhe po ashtu edhe puna jonë. Nën mbulesën e një Ford të ri ka po aq rreshta kodi sa ka në Facebook dhe Twitter të marra së bashku. Sa herë që njerëzit duhet të marrin përsipër një projekt kompleks krijues, ne shohim se menaxhimi tradicional nuk funksionon.

Në vend të kësaj, këto rregulla të thjeshta funksionojnë:

• planifikimi është i dobishëm, ndjekja verbërisht e një plani nuk është: duhet ta shikoni me kujdes dhe ta përshtatni;





• duke u varur fort pas metodës “komandimi dhe kontrolli” do t’ju çojë në katastrofë;





• të kontrolloni nëse po shkoni në drejtimin e gabuar, është një faktor kyç për sukses;





• çdo punë që nuk prodhon vlerë reale është humbje.

Një strukturë që lejon menaxherët dhe ekipin të jenë të suksesshëm

Ekipet janë sisteme komplekse dhe fleksibël: kur bëhet edhe një ndryshim i vogël, i gjithë sistemi bie në një gjendje kaosi, atëherë kompania ristrukturohet. E vetmja gjë që ka rëndësi është se struktura e re është më e mirë se e vjetra. Scrum është një seri rregullash që i udhëheq ekipet përmes këtyre ndryshimeve; i ndihmon organizatat që të vendosen në mënyrën më të lumtur dhe më produktive.

Në vitin 1986, Harvard Business Review botoi një artikull të nënshkruar nga analistët e biznesit Hirotaka Takeuchi dhe Ikujiro Nonaka. Titulli i artikullit ishte Loja e Zhvillimit të Produktit të Ri të Ri dhe raportonte mbi studimet e kryera në disa nga kompanitë më inovative në botë. Proceset e zhvillimit që përdorën këto kompani ishin fleksibël, dhe ekipet ishin horizontale dhe autonome. Menaxherët ishin udhëheqës shërbëtorë dhe ata vepronin si lehtësues. Dy autorët i krahasojnë këto ekipe me një ekip regbi: topi kalohet brenda një ekipi që lëviz në fushë si një njësi e vetme. Shtatë vjet pas botimit të artikullit, asnjë menaxher amerikan nuk ishte në gjendje ta kuptonte dhe ta zbatonte atë në praktikë. Kjo është kur Scrum u krijua zyrtarisht, dhe u prezantua në 1995 si një proces zhvillimi.

Cikli i prodhimit Planifiko-Bëj-Kontrollo-Përshtat

Deming (një ekspert në menaxhimin e operacioneve në vitet 1950) krijoi ciklin PDCA i cili mund të zbatohet ende sot në ciklin e prodhimit të absolutisht çdo gjëje. Kur u përcaktua për herë të parë, ajo u pa menjëherë si revolucionare dhe u bë pjesë e bazës së Sistemit të Prodhimit Toyota, e njëjta metodë që lejoi prodhuesin e makinave të bëhej numri një në botë.

Një nga mënyrat më të lehta për të mësuar se si të përdorni Scrum është të aplikoni PDCA për të ndërtuar një aeroplan letre. Aspekti më i rëndësishëm i këtij ushtrimi është shfaqja e përmirësimit, domethënë përmirësimi i procesit dhe rezultati përfundimtar. Kjo na tregon në një mënyrë të thjeshtë sesi vetëmenaxhimi, analiza e procesit dhe ndryshimet e vogla mund të çojnë në rezultate befasuese.

Scrum dhe kultura japoneze

Scrum i ka rrënjët në Japoni dhe në kulturën japoneze. Ashtu si arti marcial Aikido, Scrum mund të mësohet vetëm duke e zbatuar atë. Mendja, trupi dhe shpirti harmonizohen përmes praktikës së përmirësimit të vazhdueshëm. Në artet marciale Shu Ha Ri ilustroi llojet e ndryshme të mjeshtërisë. Shu është gjendja e të mësuarit të rregullave dhe formave, nxënësi i përsërit ashtu si hapat e kërcimit, pa bërë asnjë ndryshim në to, derisa trupi i tij t’i përthithë plotësisht.

Kur të arrini gjendjen Ha, ju lejohet të bëni ndryshime. Në gjendjen Ri, ju mund t’i lini  format sepse do t’i keni zotëruar ato: çdo lëvizje që bëni përfshin thelbin e Aikidos.

Karakteristikat e ekipeve të suksesshme

Karakteristikat që e bëjnë një ekip të madh kodohen dhe riprodhohen lehtësisht. Ja si i përshkruajnë Hirotaka Takeuchi dhe Ikujiro Nonaka ekipet që kanë vëzhguar në disa prej kompanive më të mira në botë:

• ato janë transcendente. Ata kanë një ndjenjë qëllimi përtej të zakonshmes. Ata janë të përkushtuar, refuzojnë mediokritetin dhe synojnë madhështinë, vendim që ndryshon idenë që kanë për veten e tyre;





• janë autonome: vetëorganizohen dhe vetëmenaxhohen, marrin vendime dhe i vënë në praktikë;





• ato janë ndërfunksionale: të gjithë në ekip kanë kompetencat e nevojshme për të kryer punën dhe ata mbështesin njëri-tjetrin.

Ekipi i ragbit të Zelandës së Re, All Blacks, është një ekip transcendental. Para se të luajnë ata gjithmonë kërcejnë Haka, vallëzimi i luftës Maori. Le të shohim më nga afër se çfarë shfaq ekipi gjatë këtij kërcimi:

• fokus serioz tek objektivi, i mbështetur dhe i përforcuar nga këndimi;





• bashkëpunimi total: grupi lëviz si një;





• uri për fitore dhe eksitim për sfidën që kanë përpara.

Madhësia e ekipit është shumë e rëndësishme, ku numri optimal është më shumë se 5 dhe më pak se 9. Sipas “Ligjit të Brooks” nëse shtoni një person me vonesë në një ekip, do të rrisni vonesën e projektit. 

Për të kuptuar pse, duhet të shikojmë mënyrën se si funksionon truri i njeriut: kujtesa afatshkurtër ka një kufi strukturor. Dy problemet që lindin nëse ne vendosim shumë njerëz në një projekt janë: duhet kohë për të sjellë të gjithë në të njëjtin nivel efikasiteti dhe rritet numri i kanaleve të informacionit që truri ynë duhet të menaxhojë.

Formula është:

Kanalet e komunikimit = numri i njerëzve x (numri i njerëzve -1)/2

Kjo do të thotë që një ekip prej 5 personash do të ketë 10 kanale, një grup prej 8 personash do të ketë 28 dhe për një grup prej 10 vetash numri i kanaleve shkon deri në 45. Ndërsa kanalet rriten, bëhet më e vështirë për njerëzit të shpërndajnë informacionin e nevojshëm, duke ngadalësuar punën e të gjithëve.

Roli i Scrum Master

Për të siguruar efikasitetin e një procesi të mbështetur nga takime ku bëhen plane, shprehen vlerësime kritike dhe analiza retrospektive, nuk duhet një menaxher, por një drejtues në shërbim të skuadrës, një kryqëzim mes kapitenit dhe trajnerit. Emri i dhënë këtij roli është Scrum Master dhe detyra e tij është të lehtësojë takimet, të garantojë transparencë, të ndihmojë ekipin të identifikojë pengesat e tyre dhe më pas të ndihmojë në gjetjen e mënyrave për t’i kapërcyer ato.

Një nga detyrat kryesore që ka Scrum Master është të menaxhojë takimin në të cilin ekipi analizon se si ata kanë punuar gjatë javëve të mëparshme, në mënyrë që ata të mund të identifikojnë çdo gabim dhe fusha ku mund të përmirësohen; kjo ndodh në fund të Sprintit dhe pas demonstrimit.

Përdorimi i Retrospektivës për të përmirësuar Sprintin

Ekziston një lloj takimi që quhet Retrospektivë dhe është thelbësore që Sprint të vlerësohet në këtë takim pa bërë gabimin klasik që ekspertët e quajnë “Gabimi Themelor i Attribuimit”. 

Psikologët kanë mësuar se kur analizojmë gabimet tona, bëhemi më të vetëdijshëm për faktorët e situatës dhe përfundojmë duke i përdorur ata për të shpjeguar arsyet e vendimeve tona. Megjithatë, ne nuk e bëjmë këtë kur analizojmë sjelljen e njerëzve të tjerë. Ky gabim njihet si gabimi themelor i ndëshkimit; është studiuar më parë në vitet ’70 dhe është një fenomen ku ne priremi të kërkojmë fajtorin, në vend që të shikojmë sistemin dhe të përpiqemi të shohim se çfarë e ka krijuar problemin që ta zgjidhim atë. Retrospektiva supozon se një sistem jofunksional shkakton probleme dhe se njerëzit janë vetëm një pjesë e atij sistemi, i cili duhet të rregullohet.

Sprinti dhe koha

Ideja për Sprint erdhi nga laboratori i IT në MIT, ku në fillim të viteve ’90, ata i vendosën vetes një rregull: çdo 3 javë studiuesit duhej të tregonin gjithçka për të cilën po punonin. Ishin demonstrata të hapura që çdokush mund t’i shikonte. Sprintet janë “kuti kohore me një kohëzgjatje të caktuar dhe ato duhet të jenë të vazhdueshme. Me fjalë të tjera, ju nuk bëni një Sprint njëjavor dhe më pas një Sprint trejavor. Ritmi i punës duhet të vendoset në mënyrë që njerëzit të mund të prodhojnë vlerë, rezultate, përparim të dobishëm për përdoruesin përfundimtar të produktit.

Stand Up ditor 15-minutësh

Çdo mëngjes ekipi mblidhet dhe bëhen tre pyetje kyçe. Të gjithë thonë se çfarë kanë bërë një ditë më parë, çfarë do të bëjnë atë ditë dhe deklarojnë çdo problem të mundshëm që presin të hasin, të njohura si pengesa. Dhe kjo është ajo. 

Nëse ky takim zgjat më shumë se 15 minuta, do të thotë se po e bëni gabim. Qëllimi i takimit Stand Up është të ndihmojë të gjithë ekipin të marrë një pamje të saktë të vendit ku ata qëndrojnë. Ideja është që ekipi të shikojë taktikat e tij në të njëjtën mënyrë si një ekip regbi: një sulmues mund të thotë “Unë kam një problem me atë anësor”, për të cilin një mbrojtës do të përgjigjet më pas: “Unë do ta trajtoj atë. “. Skuadra duhet të dalë nga takimi duke thënë “ta rregullojmë këtë, le të bëjmë atë”.

Menaxhimi i mbetjeve

Japonezët kanë tre fjalë të ndryshme për mbeturinat dhe të treja janë marrë në konsideratë në Sistemin e Prodhimit të Toyota: Muri, mbeturina për shkak të të qenit të paarsyeshëm, Mura, mbeturina përmes mospërputhjes dhe Muda, humbje përmes rezultateve. 

Një mbetje që shpesh nënvlerësohet është ajo mbeturinë që shkaktohet nga mungesa e fokusit. Njerëzit nuk bëjnë shumë punë në të njëjtën kohë sepse u pëlqen të kryejnë shumë detyra, por sepse janë të hutuar. Në fillim të viteve 1990, Harold Pusher demonstroi atë që njihet si “ndërhyrje në detyrë të dyfishtë”: eksperimenti kërkonte shtypjen e një butoni kur ndizte një dritë. Koha që u desh për të shtypur butonin u dyfishua kur njerëzve iu kërkua të zgjidhnin midis dy butonave me ngjyra të ndryshme kur ndizej drita.

Harta e trurit ka treguar se të menduarit nuk është i njëkohshëm, por serial: truri kalon vazhdimisht nga një mendim ose detyrë në tjetrën. Ne duhet t’i kujtojmë vetes se puna në vazhdim është e kotë: mendoni për grumbullimin e gjetheve në një kopsht, shkarkimin e sendeve ushqimore nga makina dhe kryerjen e një transferte bankare. Nëse filloni t’i bëni të gjitha ato gjëra në të njëjtën kohë, duke i kthyer para dhe mbrapa, kur t’i keni përfunduar pjesërisht të gjitha, nuk do të keni krijuar asnjë vlerë.

Në analizën e tij të prodhimit të sektorit të makinave luksoze, James Womack, themeluesi i Institutit Lean Enterprise të MIT, përshkruan mbeturinat që krijohen si rezultat i ripërpunimit: në Japoni, Honda, Nissan dhe Toyota u deshën mesatarisht 16.8 orë për të ndërtuar një luks. makinë me 34 defekte në çdo 100 makina; në Evropë, Mercedes, Audi dhe BMW kishin shifra shumë të ndryshme: 57 orë dhe 78.7 defekte në çdo 100 makina. Sekreti qëndron në fuqinë që ka çdo prodhues në linjën e prodhimit të Toyota: secili prej tyre është i autorizuar të ndalojë linjën dhe kur ta bëjnë këtë, të gjithë do të vijnë në pikën ku linja është ndalur dhe do të punojnë së bashku për të rregulluar problemin. Nëse nuk do të punonin në këtë mënyrë, defekti do të prekte qindra automjete. Metoda Toyota është të zgjidhësh problemin një herë e përgjithmonë.

Në fabrikën e Mercedesit, në fund të linjës së prodhimit, një ekip prodhimi punon me kominoshe të bardha për të zgjidhur problemet, duke gjetur ndoshta të njëjtin gabim në dhjetë automjete. Fabrika gjermane rregullon makinën që sapo është prodhuar, ndërsa japonezët dërgojnë makina të përsosura nga fabrika e saj.

Vlerësimi i aktiviteteve

Në një sistem të bazuar në kohë, është e rëndësishme të vlerësohet se çfarë mund të arrihet dhe deri kur. Scrum përdor vlerësimin dimensional relativ, i cili është krahasimi dimensional midis dy detyrave. Metoda të ndryshme mund të përdoren për të ndihmuar njerëzit të vlerësojnë punën e tyre, por një nga më të njohurat është metoda e madhësisë së qenve. 

Sipas kësaj metode, ju pyesni: a është ky problem një Dachshund apo një Danez i Madh? Çdo race i është caktuar një vlerë numerike. Një Dachshund vlen 1, një Labrador 5. Vlerat caktohen duke përdorur sekuencën Fibonacci, e cila është kudo në natyrë dhe për këtë arsye është instinktive për njerëzit. Është një prirje ku numri i radhës në një sekuencë është shuma e dy që vijnë përpara tij: 1, 3, 5, 8, 13 e kështu me radhë. Vlerat janë mjaft larg njëra-tjetrës për të na lejuar që instinktivisht të kuptojmë ndryshimin. Mendja jonë nuk i interpreton lehtësisht rritjet margjinale dhe ne jemi më të mirë në perceptimin e hapave të qartë. Për të vlerësuar një detyrë, është më e lehtë të përcaktohet nëse është 5 ose 8 sesa 5 ose 6.

Kuptimi i historisë përpara se të zgjidhni një kurs veprimi

Me Scrum nuk është e dobishme të filloni të shikoni se çfarë duhet bërë, pika e fillimit duhet të fillojë duke kuptuar historinë e projektit në fjalë. Pyetjet e para që ekipi duhet t’i bëjë vetes janë: për kë po e bëjmë këtë punë dhe pse? Pasi ta keni kuptuar këtë, është më e lehtë të përcaktohet se çfarë duhet bërë.

Pronari i produktit duhet të përgatisë një listë të specifikave në një listë të quajtur Regjistrimi i mbetur, duke i kthyer ato në tregime të shkurtra: përshkrimi i asaj që duhet bërë bëhet tregim i domosdoshmërisë, i një problemi që duhet zgjidhur, për shembull: ” si përdorues i këtij aplikacioni të lojrave, unë dua të jem në gjendje të aksesoj listën e lojërave të fundit që kam luajtur. Më pas ekipi analizon këtë problem dhe e përkthen atë në një numër detyrash sipas numrit të profesionistëve që do të përfshihen: nga projektuesi në UI (Ndërfaqja e Përdoruesit), nga zhvilluesi i bazës së të dhënave te redaktori. Në fund të Sprint, pronari i produktit do të përcaktojë nëse kërkesa që është bërë në tregimet e tij, e cila më pas është transformuar në një qëllim Sprint, ka përmbushur dhe nëse ka vlerë “të dorëzueshme” për përdoruesin përfundimtar. Pasi të përfundojë ky cikël, ai fillon përsëri.