Agile Is Rigor Mortis bilang Relihiyon ng Estado ng Software

Karaniwan na sa mundo ng software engineering na makarinig ng mga proklamasyon ng pagkamatay ni Agile mula sa mga taong may interes sa pamamaraan, na sinasabing maliban kung magpakita tayo ng higit na paniniwala, ito ay mawawala, at sa mga kaso kung saan ito nabigo, ito hindi pa naipatupad nang maayos - nakapagpapaalaala sa iba pang mga pag-aangkin kasunod ng "walang totoong Scotsman" na kamalian tulad ng "ang tunay na komunismo ay hindi pa nasusubukan."

Sa kabila ng presensya nito sa mga sakuna ng software na nag-iiba mula sa mga miscarriages of justice hanggang sa mga sakuna ng software ng aviation, ang katotohanan ay ang Agile ay may posisyon na medyo isang propesyonal na relihiyon ng software engineering.

Ang sitwasyong ito ay lubos na nagbago sa nakalipas na mga buwan. Dahil nagtrabaho ako sa pananaliksik 6 na buwan na ang nakakaraan na nagpapakita na ang mga proyekto ng Agile software ay may 268% na mas mataas na rate ng pagkabigo , isang kalabisan ng pananaliksik ang lumabas na nagpapatunay sa gawaing ito.

Tulad ng komunismo o pagpapagaling sa pananampalataya, ang mga pantasya ng kadakilaan na sa pangkalahatan ay mabuti, ngunit hindi makatotohanan, ang mga solusyon ay maaaring makalutas sa lahat ng ating mga problema ay palaging mag-aapela sa ilan sa kabila ng mga ebidensya - ngunit ang nagbago ngayon ay ang pagkakaroon ng kaalamang pahintulot kung susundin ang Agile o gumawa ng ibang bagay. '

(Walang duda, ang internasyonal na balita na nauugnay sa CrowdStrike botched software update ay tiyak na nakatulong sa pag-uwi sa mga puntong sinusubukan kong gawin.)

Sa kabila ng kasuklam-suklam na lawak ng ilan sa Agile community na sinubukan akong patahimikin mula sa pakikipag-usap tungkol sa Agile, mahalagang maging mapagbigay sa tagumpay kaya hindi ko hahanapin na ibalik ang mga argumento dito - sa halip, pakiramdam ko ay sulit na talakayin ang mga kamakailang pag-unlad at ang daan sa unahan, 6 na buwan na.

Ang Pananaliksik ng DORA ng Google ay Nag-on sa Agile

Ang JL Partners, na inatasan kong magsagawa ng Agile failure rate research, ay nagkaroon ng kahanga-hanga nitong mga nakaraang buwan. Hindi tulad ng marami pang iba na nagsasagawa ng pananaliksik na may limitadong pananagutan, regular nilang sinusubok ang kanilang mga modelo sa pamamagitan ng paghula ng mga halalan. Pagdating sa mga halalan sa UK, nalaman nilang gumagawa sila sa mga pinakatumpak na hula . Ang mga bagay ay mas kapansin-pansin pagdating sa halalan sa US gaya ng iniulat ni Politico :

… Maaaring ang JL Partners ay maging isa sa mga pinakatumpak sa kanilang huling hula bago ang halalan. Ang panghuling modelo ng kumpanya ay isa lamang sa dalawa upang hulaan ang isang panalo sa Trump at ito rin ay inaasahang nanalo siya sa Electoral College 287-251 — ang pinakamataas na inaasahang panalo sa Trump na margin ng anumang pollster. Isa rin ito sa napakakaunting pollster na mahulaan na mananalo si Trump sa popular na boto.

Bukod pa rito, natuklasan ng pananaliksik mula sa RAND Corporation na unang isinagawa para sa US Department of Defense na ang AI development at agile ay hindi naghahalo nang maayos . Higit pa rito, iniuulat ng Synodus (isang pandaigdigang provider ng teknolohiyang nagsusuplay (Fortune 500 kumpanya tulad ng BOC Aviation, KPMG, at Unilever) na sa pamamagitan ng paglayo sa Agile , nalaman nilang naghahatid sila ng mga proyekto nang 2-3x na mas mabilis at nag-uulat ng nangungunang airline na nakatipid 63 % ng kanilang mga gastos sa pagpapaunlad.

Ito ay sa kabila ng katotohanan na ang bilis at gastos ay tradisyonal na mga sukatan na nauugnay sa Agile at LEAN, habang ang diskarte sa Impact Engineering ay nakatuon sa Impact bilang pangunahing sukatan.

Sa wakas, tulad ng isinulat ni Colm Campbell sa artikulong " P-Hacking with Dinosaurs ," ang mga paghahabol na iniharap ng "Agile Mafia" bilang tugon sa pag-aaral ng Agile failure rate ay komprehensibong pinabulaanan, na nag-iiwan lamang ng mga kalunus-lunos na personal na pag-atake.

Gayunpaman, marahil ang isa sa mga pinaka nakakagulat na bahagi ng pagsuporta sa pananaliksik ay nagmumula sa DORA team ng Google. Ang DORA mismo ay nahahanap ang mga ugat nito sa kilusang DevOps, na mismong nilalang ng Agile. Ang kanilang taunang State of DevOps Report para sa 2024 ay hindi nakatanggap ng anumang partikular na malawakang saklaw ngayong taon dahil sa airtime na napunta sa Agile research, ngunit nakakatuwang makita na sila ay tumalikod din sa Agile.

Ngayon, dapat kong tandaan na naging kritikal ako sa pamamaraan ng DORA team (mula nang magbago ang isip ko sa Agile, DevOps, atbp.) dahil ang mga pangunahing sukatan na ginagamit nila upang sukatin ang mga bagay ay nakatuon sa bilis ng paghahatid ( na alam nating hindi 't kung ano ang gusto ng mga gumagamit ), ngunit ang katotohanang nakikita nila ito kahit na gamit ang kanilang diskarte ay tumutukoy sa isang bagay na mas malalim na nangyayari dito.

Sa pahina 64 ng State of DevOps Report 2024, inaangkin nila:

'Ang Agile manifesto ay nagtataguyod para sa "gumaganang software sa komprehensibong dokumentasyon". Patuloy naming nalaman, gayunpaman, na ang kalidad ng dokumentasyon ay isang mahalagang bahagi ng gumaganang software.'

Higit pa rito, sa pahina 82, lumilitaw na tumalikod sila sa DevOps mismo:

'Kami ay nakatuon sa mga pangunahing prinsipyo na palaging bahagi ng kilusang DevOps: kultura, pakikipagtulungan, automation, pag-aaral, at paggamit ng teknolohiya upang makamit ang mga layunin sa negosyo. Nakikinabang ang aming komunidad at pananaliksik mula sa mga pananaw ng magkakaibang mga tungkulin, kabilang ang mga taong maaaring hindi nauugnay sa label na "DevOps." Dapat mong asahan na makita ang terminong "DevOps" na umaalis sa spotlight.'

Mayroon pa akong mga isyu sa kanilang pamamaraan ng pananaliksik; ang mga endpoint na ginamit upang sukatin ang tagumpay ay nakatuon sa bilis, at higit pa rito, patuloy silang nagtataguyod para sa transformational na pamumuno sa kabila ng sikolohikal na pananaliksik sa lugar na ito na nagtatanong sa mga ganitong paraan.

Sa antas ng tao, tila napakawalang-bisa na mag-focus nang husto sa pagtatangka na baguhin ang mga organisasyon at mga tao nang wala ang kanilang kaalamang pahintulot habang hindi rin nakikilala kung paano madalas na walang mas mahusay na pinagmumulan ng pag-aaral kaysa sa sarili nating mga pagkakamali (hanggang mayroon tayong kaalaman. pagpayag na gawin ang mga ito), isang pangunahing pagpuna na mayroon ako sa trabaho tulad ng The Pheonix Project at The Unicorn Project .

Gayunpaman, kapansin-pansin gayunpaman na makita ang pagtaas ng corroboration para sa Impact Engineering laban sa tradisyonal na Agile at DevOps metrics.

Scrum, TDD, at Mga Pattern ng Disenyo

Noong kapanayamin ako ng The Register ilang buwan na ang nakararaan sa artikulong “ Study backer: Catastrophic takes on Agile overemphasize new features ” , hindi ko inilihim ang tatlong salik na nagkaroon ako ng mga isyu sa mga modernong diskarte sa Agile, DevOps, at digital transformation:

1. Mga diskarte ng Agile na hindi na ginagamit ang mga kinakailangan, sa kabila ng mga sakuna kabilang ang post Office scandal at Boeing 737 Max 8 crashes .

   
   

2. Mga pagpapatupad ng DevOps na inuuna ang bilis ng paghahatid ng mga bagong feature at pagbawi mula sa mga isyu kumpara sa pagpigil sa mga problema sa simula pa lang - sa kabila ng pagsasaliksik na nagpapakita na ang pampublikong ranggo ay nakakakuha ng mga pinakabagong feature nang mabilis hangga't maaari bilangang hindi gaanong mahalagang bagay para sa kanila kapag gumagamit ng mga computer system, na may seguridad ng data, katumpakan ng data, at walang malubhang bug ang pinakamahalagang salik.

   
   

3. Mga pagtatangka sa bottom-up na pagbabagong organisasyon nang hindi kumukuha ng may-kaalamang pahintulot, napapabayaan ang kahalagahan ng pagpayag sa mga tao na matuto mula sa kanilang sariling mga pagkakamali na mayroon silang may-kaalamang pahintulot na gawin - na may mga naturang programa na ibinebenta bilang siguradong mga tagumpay na labis na nagtatapos sa nakababahalang paghihirap at kabiguan.

   
   

Habang sinimulan kong magsaliksik ng mga sakuna sa software at mga nakamamatay na computer (tulad ng iniulat sa Forbes noong Abril ), ito ang tatlong salik kung saan nagsimula akong magkaroon ng dumaraming mga hamon sa moral. Wala akong tunay na isyu sa iba't ibang diskarte sa pagbuo ng software o mga diskarte sa pamamahala ng proyekto dahil hindi ko nakita ang parehong link sa mga pag-aaral ng kaso ng kalamidad na iniimbestigahan ko. Hindi ko naramdaman ang pangangailangang ipahayag ang aking mga personal na pananaw bilang isang inhinyero tungkol sa iba pang mga bagay na ito.

Gayunpaman, ito ay kagiliw-giliw na makita ang blast radius ay lumawak lampas sa unang tatlong lugar na ito sa iba pang mga diskarte na itinaguyod ng Agile Manifesto co-authors tulad ng Scrum, Test-Driven Development (TDD), Object-Oriented Programming (OOP), at Design Mga Pattern (hal., tingnan ang LinkedIn post ni Soumen Sarkar sa Mga Pattern ng Disenyo ).

Mayroon akong kaunti upang idagdag sa lugar na ito. Gayunpaman, nagtataka ako kung ang Agile co-authors ay hindi nakipaglaban nang husto laban sa pagkamatay nito bilang isang relihiyon kung ang komunidad ng software engineering ay magiging mas mabait sa kanilang iba pang mga ideya. Ang tanong ay pinagtatalunan na ngayon dahil ang katayuan sa relihiyon ni Agile ay rigor mortis at ang lahat ay tila madali: OOP, mga pattern ng disenyo, TDD, atbp.

Tungo sa Loss Aversion Awareness

Dahil gumugol ng medyo malaking proporsyon sa mga nakaraang buwan bilang mga balita sa harap ng iba't ibang mga tech na publikasyon na pinag-uusapan ang Agile at napakalawak na tinatalakay sa gitna ng komunidad sa pangkalahatan, marahil ay hindi nakakagulat na magkaroon ng ilang mga kakaibang engkwentro. Gayunpaman, sa karamihan, sila ay naging napakagandang pagkikita ng mga taong lumalapit sa akin sa publiko at random na nakikipag-usap sa Agile.

Gayunpaman, may isang engkwentro na nag-iwan ng matinding impresyon sa akin. Ilang linggo na ang nakalipas, pupunta ako sa UK Parliament para tugunan ang mga policymakers sa iba't ibang tech na iskandalo na pinagsisikapan kong imbestigahan. Hindi ako kailanman naging tagahanga ng paghawak ng kapangyarihan sa aking sarili, at palagi kong napag-aalinlanganan na sa mga pribadong bar sa Parliament, kailangang may mga palatandaan na nagpapaalala sa mga indibidwal na huwag abusuhin ang kanilang kapangyarihan kapag lasing.

Gayunpaman, sa pagbibigay ng pahayag na ito, hindi lang ako nakadamit at mas presentable kaysa karaniwan, ngunit nasa harap din ako ng nakikiramay na madla, na nasa gilid ng isang Miyembro ng Parliament at isang kaibigan na nagkataong isang King's Counsel (isang senior lawyer granted ang pagkakaiba ng monarch para sa natatanging adbokasiya).

Sa sandaling nagbigay ako ng aking talumpati at sumagot ng maraming tanong, mayroong isang bisita sa madla na nagsimulang magsalita tungkol sa Agile (ang usapan ay hindi tungkol sa Agile). Kabaligtaran sa aking three-piece suit, siya ay nakasuot ng ketchup-stained shirt at (nang hindi naglalarawan ng mga detalye) ay hindi presentable o hindi konektado sa pulitika. Sinimulan niya ang "Maaari ba akong magbigay sa iyo ng ilang puna?"

Nang magsimula siyang magsalita tungkol sa Agile, nakipag-eye contact ako sa kanya nang may pagtatanong, at tumingin siya sa ibaba at tumigil sa pagsasalita, halos natanto niyang hindi na siya online at talagang kaharap ang isang tao sa kanyang mga salita. Bago ako makasagot, sumingit ang isang kaibigang CEO para tugunan ang punto para sa akin.

Sa sandaling iyon, napagtanto ko na hindi ko gusto ang kapangyarihan sa isang lawak na hindi ko napagtanto sa ngayon.

Sa kasamaang palad, para sa indibidwal na ito, tila naging biktima na siya ng mga nagbebenta ng mga siguradong solusyon sa pagbabagong-anyo na tila humahantong sa mga paghihirap sa kanyang sariling buhay. Sa mga sitwasyong ito, bakit itinataguyod pa rin ang mga pamamaraan ng pagbabagong ito?

Mas malawak, bakit hindi gumana ang Agile sa totoong mundo? Sa komunismo, hindi bababa sa maaari nating maiugnay ang kabiguan sa kasakiman, kaya ano ang sikolohiya ng Agile failure? Ang sagot, sa aking mga mata, ay nagmumula sa isang sikolohikal na kadahilanan na kilala bilang pag-ayaw sa pagkawala . Sa pamamagitan ng tanyag na pangangailangan, nagsulat ako kamakailan ng isang pre-print na papel sa gawaing Impact Engineering at nakatutok ito sa papel na maaaring gawin ng kamalayan sa pagkawala ng pag-iwas sa pagpapagaan ng tagumpay ng proyekto.

Ang papel, "So Am I Dr. Frankenstein? O Isa Ka Bang Halimaw sa Buong Panahon?”: Pagbabawas ng Pagkabigo sa Software Project Gamit ang Loss-Aversion-Aware Development Methodologies , ay nagtatapos sa sumusunod:

Ipinakita ng mga pag-aaral ng kaso na ang mga sakuna sa software ay maaaring maging mga sakuna kapag ang mga problema ay hindi natugunan at sa halip ay tinatakpan. Ang mga sikolohikal na salik, isang susi sa pagkawala ng pag-iwas, ay maaaring mag-udyok sa mga organisasyon na pumunta sa landas na ito sa kabila ng mga mapaminsalang kahihinatnan.

Gayunpaman, ang mga pamamaraan ng software ay binalewala sa kasaysayan ang sikolohikal na salik na ito, sa halip ay ipinapalagay na ang mga tao ay nais na matugunan ang mga problema sa pinakamaagang pagkakataon. Natuklasan ng nakaraang pananaliksik ng iba't ibang pamamaraan na ang kaligtasang sikolohikal upang itaas at talakayin ang mga isyu ay susi sa pinahusay na paghahatid ng software. Gayunpaman, walang alinlangan na maasahan na maniwala na ang gayong makabuluhang pagbabago sa kultura at sikolohikal ay maaaring makamit sa lahat ng mga organisasyon. Tulad ng nalaman namin, kahit sa pagitan ng UK at USA, ang kaligtasang sikolohikal ay nananatiling pinakamalaking pagkakaiba sa kasanayan sa engineering sa pagitan ng dalawang bansa.

Sa papel na ito, nakatuon kami sa ibang paraan pasulong. Sa halip na subukang makamit ang isang pagbabago sa kultura na pinakamahirap, sa halip ay tumuon kami sa isang mas pragmatikong diskarte: limitahan ang mga nag-trigger ng pag-iwas sa pagkawala mula sa simula sa pamamagitan ng matatag na mga kinakailangan at pagkatapos ay layunin para sa sikolohikal na kaligtasan kung saan ito kinakailangan. Sa aming pananaliksik, ang nag-iisang salik na nakita namin na magpapataas sa rate ng tagumpay ng isang proyekto nang higit pa kaysa sa sikolohikal na kaligtasan ay ang pagkakaroon ng malinaw na mga kinakailangan mula sa simula.

Laban sa aming hypothesis, ang mga resulta na ang pagkakaroon lamang ng mga malinaw na kinakailangan, kahit na sila ay nagbabago nang huli sa pag-unlad o hindi nakahanay sa totoong mundo, ay tila may malaking papel sa tagumpay ng software project. Iminumungkahi nito na ang pagkakaroon ng gate bago magsimula ang isang proyekto upang talakayin at tugunan ang mga problema, kapag ang pag-iwas sa pagkawala ay nasa pinakamababa, ay nagbibigay-daan para sa pinakamalaking pagpapabuti sa mga rate ng tagumpay.

Ang kantang Dr. Frankenstein ng RedHook ay naglalaman ng refrain: “Ako ba si Dr. Frankenstein? O naging halimaw ka sa buong panahon?" Para sa mga sakuna na proyekto ng software, ipinapalagay ng papel na ito na ang mga proyekto ng software ay nagiging mga sakuna kapag nabigo ang mga tao na tugunan ang mas maliliit na problemang teknikal. Nabigo ang mga umiiral na pamamaraan ng software engineering na tugunan na ang mga tao ay hindi mga makina at ang mga sikolohikal na kadahilanan ay humahadlang sa kakayahang tugunan ang mga problema. Ang pagkakaroon ng pagkilala sa anachronism na ito sa mga umiiral na pamamaraan, ang papel na ito ay nagpapakita kung paano natin ito aaksyunan sa pamamagitan ng paggamit ng mga kinakailangan bago magsimula ang isang proyekto upang magbigay ng pagkakataong matugunan ang mga problema kapag ang pag-iwas sa pagkawala ay nasa pinakamababa.