olav m.j. christiansen bloghoved olav christiansen

Fake agile

I denne tid med fake news, findes der åbenbart også 'fake agile'. Det er i hvert fald et af de ord, folk bruger om forskellige mislykkede eller misforståede måder at blive agile på.

Martin Fowler har for nylig holdt en tale om status på det agile i 2018, og han nævner en del af udfordringerne. Her er en transskription af talen:
https://martinfowler.com/articles/agile-aus-2018.html

Hvad mener læserne? Er det også det vi ser i Danmark? Har I set faux agile, fake agile eller ligefrem Dark Scrum?

Kommentarer (12)
Morten Jensen

Én af de hyppigst nævnte dyder ved Agile er Continuous Delivery, der tilsiger at man kan release et software-produkt hurtigt, og at man kan arbejde i korte sprints af få ugers varighed.

For at ovenstående fungerer, er man typisk nødt til at have Continuous Integration eller noget tilsvarende automatisk kvalitetskontrol på plads.

Det betyder at man investerer tid i at skrive tests og holde dem ved lige mens projektet udvider sig.

En typisk "fake agile" er at man vil release hurtigt, men ikke investere up-front i kvalitetskontrol og test-kode. Det har jeg ihvertfald oplevet mere end én gang professionelt.

Man tager alt det der lyder godt fra "Agile", og ignorerer behændigt de kedelige aspekter af "Agile".

I øvrigt mener jeg at "Agile" som begreb har så lidt autoritativ definition at det i praksis er en floskel som man lægger i hvad man vil....

Poul-Henning Kamp Blogger

Continuous Integration eller noget tilsvarende automatisk kvalitetskontrol på plads.

Og allerede der knækker "agile" religionen nakken: CI er for kvalitetskontrol hvad dæksparkning er for brugtbilskøb.

Hvis CI skal omtales som kvalitetskontrol, skal de automatiske CI-tests dække absolut mindst 80% og helst over 90% af alle kodeliner og funktionsflow.

Hvor mange kan prale af det ?

Carsten Gehling

http://agilemanifesto.org/ AKA "grundloven for Agil" siger i første læresætning:

Individuals and interactions over processes and tools

Jeg tror at rigtig mange virksomheder prøver at indføre Scrum eller lignende uden allerførst at læse ovenstående og tænke godt og grundigt over det.

Eller sagt på en anden måde, som PHK allerede har gjort meget bedre end jeg i https://www.version2.dk/blog/agil-min-bare-16318

En stensikker opskrift på success i software udvikling er en kompetent og inspirerende leder, med op til et dusin motiverede medarbejdere.

En lige så stensikker opskrift på fiasko, er at skalere en sådan success til en gros.

Jeg har været i nogle virksomheder, hvor man har forsøgt sig på at være agile, men hvor det primært er faldet til jorden af én enkelt grund: Ingen med nok pynt på skulderne havde sat sig for bordenden og fået resten af virksomheden med. Og så er det faktisk ligegyldigt, om det er agile eller hvad det er. Vil du indføre forandringer i en virksomheds måde at producere på, så skal alle være med.

Nu nævnte Morten Jensen Continous Delivery som en af de agiler dyder. Hvis man skal have gavn af at være agil, så skal ændringer til softwaren ud og køre hos kunderne så hurtigt og smertefrit som muligt. Og jeg har endnu tilgode at være i en "klassisk moden software virksomhed", hvor det ikke involverer både salg, support og it/drifts-afdelingen.

Det allervigtigste er ikke, om man kalder det sprints, stories og backlogs. Det vigtigste er, at nogen bestemmer sig for: hvad der skal laves og i hvilken rækkefølge man (lige nu) mener det er bedst at få det ud til kunderne. Og så hyrer man et mix af udviklere af typen specialister, all-rounders og et par nyuddannede. Og lader dem få ro til opgaven - og ikke mindst bakker 100% op i resten af biksen, når de har brug for forretningsviden og få ting ud til kunderne.

Carsten Gehling

Hvis CI skal omtales som kvalitetskontrol, skal de automatiske CI-tests dække absolut mindst 80% og helst over 90% af alle kodeliner og funktionsflow.

Hvor mange kan prale af det ?

Men hvis vi ser bort fra mærkater som kvalitetskontrol, så er "lidt CI" vel bedre end "ingen CI"? Altså målt på mængden af test-coverage.

Jeg kan i hvert fald prale af, at jeg retter aldrig(*) en bug, før jeg har skrevet en test-case, der reproducerer den. På den måde bilder jeg mig selv ind, at jeg i hvert fald ikke kommer til at genindføre gamle bugs, når jeg retter nye (den ellers velkendte "whack-a-mole udviklingsmodel").

(*) med mindre, at jeg arbejder med en af vores meget gamle projekter fra før test-frameworks blev opfundet... ;-) Og selv der gør jeg gerne en indsats for at spinne noget test-coverage op, hvis muligt.

Martin Bæk

Og allerede der knækker "agile" religionen nakken: CI er for kvalitetskontrol hvad dæksparkning er for brugtbilskøb.

Ja, bortset fra, at man næsten ikke kan undgå, at CI bidrager til at øge kvaliteten, hvorimod dæksparkningen ingen nævneværdig effekt har for brugtbilskøb.

Hvis CI skal omtales som kvalitetskontrol, skal de automatiske CI-tests dække absolut mindst 80% og helst over 90% af alle kodeliner og funktionsflow.

Der må aldrig sættes lighedstegn mellem CI og kvalitetskontrol. CI er et (nærmest uundværligt) bidrag til kvalitetskontrollen.
Jeg har arbejdet i virksomheder, der gik rigtig meget op i code coverage-procenter, hvilket jeg nu synes er spild af tid og penge. Jeg er helt sikkert fortaler for automatiske test og særligt integrationstest og unittest af komplekse og kristiske dele. Men hvis man uden videre slynger en procentsats ud som værende den rette, ender man ofte med at jagte de forkerte mål.

For nogle år siden var jeg på et projekt, hvor en moden kunde havde adgang til et miljø, hvortil der automatisk blev deployed ved checkin. Det gjorde, at kunden tidligt kunne tjekke både, at han mente det, han havde specificeret, og at vi havde forstået det korrekt. Det er for mig et effektivt bidrag til kvalitetskontrollen i en agil verden. Men det virker kun med en moden kunde, der forstår, at produktet ikke er færdigt men blot undervejs.

Martin Jünckow

Jeg har været rundt i en del større enterprise-virksomheder grundet mit arbejde som konsulent og jeg har endnu til gode at møde "ægte" scrum i disse store virksomheder.

Jeg startede sidste måned hos en stor IT virksomhed som under interview-delen brystede sig af at være førende indenfor Scrum og SAFe, blot for tørt at måtte konstatere at vores Scrum Master agerer klassisk Projektmanager, at vores team på 15 mand er spredt ud over hele globen, at vores reviews er indstuderede demoer der foregår foran 100 mennesker på en scene - og at vi stadig har vores første retrospektive til gode.

Står det bedre til i SMB segmentet?

Allan Ebdrup Blogger

Problemet med fake agile er det samme som når folk brænder nallerne på microservices eller CQRS eller [indsæt valgfrit IT emne]. Alle disse ting kan forsøges og kan have virkelig dårlige resultater. Og hvorfor er det så svært? Det svære er, at for at have success med X skal det tilpasses den kontekst man er i. Fx agil udvikling skal tilpasses det domæne du er i, de applikationer du bygger inkl. Legacy, de teams og personer du har osv. Osv. Samtidig er det et moving target hvor konteksten ændrer sig. Der er ikke en opskrift du bare kan følge og så virker det.

Det gør det desværre utroligt svært at virkelig lykkes med det og ramme den lige i røven. Og for nogle går det helt sikker så galt, at det ville have været bedre, at lade helt være med at prøve.

Grunden til at der så samtidig er en nærmest religiøs bevægelse for at det er den vej man skal gå, er at når man først har prøvet rent faktisk at lykkes med det i stor stil, er det tæt på umuligt at affinde sig med noget der fungerer dårligere.

Spørgsmålet er hvordan vi sikrer en højere successrate? Der synes jeg at Matrtin Fowlers betragtninger er gode. Men samtidig er det noget fluffy snak der giver tæt på ingen helt konkrete anvisninger til hvad man rent faktisk skal gøre.

Det er mega svært, for det handler lige så meget om mennesker og kultur som det handler om teknik. Det er lige så svært at lave en formel for som det er svært at lave en formel for hvordan du er en god chef.

Hvis man skal se lidt lyst på det, kan man jo håbe at jo mere vi prøver de her ting af, og jo flere der får konkrete erfaringer med det. Jo bedre bliver vi til at spotte fake agile og gøre noget bedre i stedet. Ud og eksperimenter.

Martin Olsen

Hvis CI skal omtales som kvalitetskontrol, skal de automatiske CI-tests dække absolut mindst 80% og helst over 90% af alle kodeliner og funktionsflow.

Mine 5 cents:

Automatiske tests og CI kan ikke stå alene, og tests er hverken gratis at skrive eller vedligeholde -- og de har det også med at få både de gode og de dårlige designbeslutninger til at "stivne", så de bliver svære at ændre. Men det kan være en måde at automatisere en del af kvalitetskontrollen, så den manuelle test ikke behøver køre de samme basisscenarier igennem igen og igen.

At man sjældent når 99% test coverage er fordi der sjældent er nogen reel business case for at dække hver eneste branch og hver eneste linje kode. Når man når en vis detaljeringsgrad, er manuelle tests ofte billigere.

Jeg ser det som en måde at automatisere nogle af de kedelige ting. På samme måde som man kan bruge et regnskabsprogram til det kedelige plus og minus, så økonomiafdelingen får bedre tid til at lave skattetænkning eller andet svindel ;)

Jens Arnt

Det er i min optik ikke et spørgsmål om hvad man kalder det (Agil, devops, scrum m.m.) men hvoran man agerer.

At være agil er i min optik et spørgsmål om at lade der være så kort fra ide til implementering uden alt for mange "distraktioner". CI er blot et af de værktøjer der gør det muligt at eksponere implementeringen for idemanden hurtigt. Men den er ikke den eneste.

Hvis ikke der er oganisatorisk opbakning til at fokuserer bliver man alt for let bragt ind i varianter af, "det kan man da ikke bare" , ".. og hvad så med xxx?", eller en af de bedste ".. hvem har så anvaret hvis ikke vi gør x, y, z " (underforstået som vi plejer).

ALLE de implementeringer jeg har set i praksis af SCRUM og "DevOps" har været mere i retning af "små vandfalds projekter" af et par ugers varighed, mere end det har været et helhjertet forsøg på at få værdien af diverse ideer i spil hurtigt og effektivt.

Et andet vigtigt Agilt element er at implementeringerne skal ud til ide-manden så hurtigt som muligt så man kan få erfaring ind så tidligt som muligt. Igen baseret på at det bare er mega svært (=umuligt) at forudse (teoretisk) hvordan en given implementering vil fungere i praksis.

I de fleste organisationer er der en eller flere "babies" i kraft af systemer, afdelinger, processer der er næsten umulige at påvirke med det resultat at det "meste" bliver som det plejer og så sætter vi "Agil" stemplet uden på .. for hvilken organisation vil ikke gerne være Agil ??

Olav M.J. Christiansen Blogger

I øvrigt mener jeg at "Agile" som begreb har så lidt autoritativ definition at det i praksis er en floskel som man lægger i hvad man vil....

Helt enig. Det har jeg også nævnt ved flere lejligheder i mine blog-indlæg.

Man burde finde på et nyt begreb, men det ender jo nok hurtigt med at blive lige så udvandet.

'Flexible', 'Adaptive', 'Responsive'?

Olav M.J. Christiansen Blogger
Martin Jünckow

Altså den erfaring jeg har med SAFe matcher meget godt din beskrivelse af det blog-indlæg du refererer til.

Det er et monstrum skabt ud fra et enterprise mindset og har meget lidt med agile at gøre - det er process sat over individuals og interactions.

Man skal være varsom med de her enterprise scrum frameworks - der er en årsag til at der ingen alignment er imellem de forskellige organisationer indenfor scrum og agile når det kommer til skalering af scrum.

Der er god alignment når vi taler om hvordan man arbejder agile på projekter op til omkring 10 mand - alt derover og vi er stadig ved at prøve at finde ud af det og problemet er nok at der begynder at være alt for mange faktorer der spiller ind til at det er let at generalisere over.

Log ind eller Opret konto for at kommentere