Mange ambitioner om agilt ender med interessante bastarder

Jeg sidder i øjeblikket i et projekt der kører "agilt", men mængden af leverancer på dette projekt er den samme som på andre projekter jeg har været med på, hvadenten projektet kører agilt eller ej.

Forskellen er, nu har brugernes set hvad vi forestiller os projektet skal munde ud i - en prototype uden fejlhåndtering og uden database - og nu forstår brugerne så ikke at der stadig er lang vej for at strukturere data, hærde systemet, få styr på processer og dokumentere systemet til drift, fremtidige ændringer og opdateringer.

Jeg kan godt lide tanken i det agile univers, fordi der er basis for meget robuste systemer og løsninger brugerne forstår. Men det vil kun skære i udviklingstiden, hvis der bliver skåret i leverancerne.

Pointen er vel ikke at det skal være hurtigere.
Pointen er at brugerene og udviklerne har en forståelse for det ønskede produkt, før det meste af arbejdes er udført.
På den måde undgår man at levere noget som brugerene slet ikke vil have.

host host Sundhedsplatformen.

btw.. være opmærksom på at at kunden og brugerene ikke nødvændigvis er de samme.

Man kan nogle gange få den tanke at fortalerne for metode <x> er det fordi de kan tjene penge på at udstede certificeringer. Modtagerne er for det meste også glade for at være Certified <x>. Det pynter på CVet, og nogle tror at det betyder noget. Alle metoder er ramt af dette.

Nogle underområder er specielt hårdt ramt. Jeg stiftede bekendtskab med SAFe, og fik en kraftig mistanke om at det var ren pengemaskine, og certificeringerne ikke var meget værd. Jeg endte med at løbe bort.

Hvad blev der af det der med at vi værdsætter 'Individer og interaktioner frem for processer og værktøjer'?

Det var det problem, som jeg stødte ind i på mit tidligere arbejde. Jeg skrev en kort svada her på version2. Man kan ikke både prioritere individer/interaktioner over processer/værktøjer, og så samtidig insistere på at følge en bog slavisk. Medmindre man er certified SAFe <x> 😉

Jeg tror at den fejl skyldes at folk forveksler midlet med målet; eller at de tror at agile-værktøj/proces Y er det bedste uanset scenariet.

Som autodidakt projektleder med +30 års hands on erfaring, er det rigtig rart, at se andre vende spanden på hovedet og stille spørgsmål ved åhhr agile, scrum, P1 og P2 samt alle de firkantede regelsæt der pr. definition kun forsinker og dræber den innovative proces.
Om så investorerne tør slippe seler og livrem, er en anden sag.
Før årtusindskiftet krævede investorerne altid at vi havde en PhD med i højteknologiske projekter, selvom de fleste af dem, ikke anede hvad vi lavede - måske vi engang når frem til færre firkantede regelsæt hvor kontrollen er for kontrollens skyld

Nogle gange kan lidt mundtlig kommunikation og et par streger være nok til at starte en opgave med og så løbende kontakt til slutbruger.

Andre gange er det de store nagler med diverse arkitekter (som jeg selv), forretningsfolk og skarp finansiel opfølgning.

Og konstant leverance af halvfærdig software der fejler, med data slutbrugeren ikke kan forstå, i test miljøer med dårlig performance og tilgængelighed, det kræver et abstraktionsniveau som ikke alle er med på. 'Min kode er færdig' betyder nogen gange at den kører ca som den skal på den lokale pc...

Agilt kan være godt og skidt, det samme kan vandfald og alt andet der er prøvet i tidens løb, blot skal man huske at de mennesker der skal aftage produktet har andet at lave end at lege med halvfærdig kode og konstante ændringer i deres applikationer - og til andre tider venter i måneder på at få rettet hvad der for dem er en helt basal fejl.

Jeg er enig med Jacob Sparre Andersen at en arkitekt er nødvendig, enten en løsningsarkitekt der indenfor rammerne af virksomheden kan sætte en løsning sammen eller andre der kan bidrage til det baggrundsmateriale der gør agil udvikling mulig. Og når det er på plads er der også plads til agil sw udvikling.

Jeg fik i tidligere ansættelse et spørgsmål fra en udvikler: 'Hvad laver I arkitekter egentlig? For vi udviklere styrer jo hvad der bliver lavet af rigtigt arbejde'. Et par min senere forstod han så fødekæden fra behov til emne i en backlog der så kan plukkes fra. Og al respekt i øvrigt for alle i den lange kæde der skal til før og inklusive agil udvikling kan være effektiv.

Ganske vist en kommentar af ældre dato, men jeg tror der er en del rigtigt i det (som også andre kommentarer her har antydet):

http://steve-yegge.blogspot.dk/2006/09/good-agile-bad-agile_27.html

Edsgar Dijkstra (som er god at citere) kaldte softwareudviklingsmetoder for "snake oil", og sagde bl.a.

What our immediate industrial environment overwhelmingly seems to ask for is different brands of snake oil, Software Engineering, of course, being one of them.

og

As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."

Groft sagt er hans holdning, at succesen af et IT-projekt har meget lidt at gøre med de metoder, man bruger, men meget at gøre med de personer, der udfører arbejdet. Ligesom den erfarne tømrer i et svar på dit næste blogindlæg kom ind og reddede et køkkenprojekt, der sejlede. Dijkstras holdning var, at man skulle koncentrere sig om at lære programmører at programmere i stedet for at fokusere på "metoder", der stort set kun virker, når de involverede faktisk ikke behøver dem. Jeg giver ham i en vis grad ret, men anerkender behovet for projektstyring og kommunikation med slutbrugerne. Men at tro, at selve udviklingen af software sker hurtigere og bedre ved at bruge "metoder", hvad enten det er Scrum, Prince2, eller noget helt tredje, er noget af en tilsnigelse.

P.S.
Velkommen som blogger, kære fætter.

Men at tro, at selve udviklingen af software sker hurtigere og bedre ved at bruge "metoder", hvad enten det er Scrum, Prince2, eller noget helt tredje, er noget af en tilsnigelse.

Bingo!

Der er alt for megen brug at diverse bull-shit banko ord, men i bund og grund kan det koges ned til:

Forretningsforståelse og god (og løbende) dialog med kunden.
God projektledelse og kommunikation.
Godt håndværk og tydeligt forklarede opgaver.
Delmål og løbende kvalitetstest.
Evt. prototype/mock up.
Dokumentation.

Og så er det ellers flintrende ligegyldigt hvilke oppe-it-tiden-smarte-ord der hæftes på, og sådan set også om det programmeres i det ene eller andet sprog (hvor det vigtigste er de håndværksmæssige evner og dokumentation).

Alligevel hører vi jo jævnligt om kuldsejlede projekter, men det er altså yderst sjældent det skyldes at man ikke kan finde ud af at programmere. Det skyldes ofte en helt masse andre ting, der bl.a. kan tilskrives metoderne og måske især anvendelsen af dem.

Dijkstras citater er fra 1970'erne, så det er givet, at ting har ændret sig. De kuldsejlede projekter skyldes nok ikke overdrevet brug af specifikke metoder, men snarere mangel på fokus og kommunikation med slutbrugerne. Nogle metoder har kommunikation i centrum, men i mange tilfælde er det ikke slutbrugerne, men deres ledere, der snakkes med. Og det kan ofte give systemer, der er bøvlede for slutbrugerne at arbejde med, eller som ikke løser de problemer, slutbrugerne sidder med til hverdag.

Et af de store problemer er at at agile og Scrum 'lover' tidlig leverance.

Det er blevet sagt mange gange at kunden ikke ved hvad han vil have før han har fået leveret det. Derfor skal vi hurtigt levere noget til kunden. Det store problem er kvaliteten. Der er alt for mange 'prototyper' der bliver lappet på i uendelighed for at få noget der kan bruges i produktion. Det skaber masser af problemer.
Kundens ledelse får et et urealistisk billede af hvor langt man er nået de ser en prototype. Det at blive ved med at lappe på en prototype giver ikke et godt produkt, men et kludetæppe.
En mere reelt løsning er for at citere Frederic Brooks "Build one to throw away". Her havner vi bare i et psykologisk problem. "Er det nu nødvendigt, vi har jo noget der næsten virker". Hvorefter der kastes en masse ressourcer efter lapperiet i stedet for.

Så snart systemer har en vis størrelse er der brug for at de har en ordentlig arkitektur. En ordentlig arkitektur er en forudsætning for et godt produkt. Det kan til gengæld godt være en en iterativ process, men der er et ordentligt forløb for det enkelte gennemløb. En væsentlig del af et sådant gennemløb er "requirement scrubbing" hvor man får fjernet alt det der ikke er brug for.