KRONIKK: – Det er mange grunner til at digitale prosjekter går galt

[Redaksjonen.]

KRONIKK: – Det er mange grunner til at digitale prosjekter går galt

[Thomas Arp]

JA! Takk for denne her, Beth og Erik. Vi trenger flere som dere, som forteller om suksess opplevd med smidig utvikling, også i offentlig sektor.

[0laf]

Det eneste som egentlig manglet var at det offentlige skulle hive seg på Agile/Scrum bølgen å bli religiøse, for dette er mer religion enn det er noe annet.

 

Dette med "smidig" utvikling er ikke nødvendigvis bare positivt, stadig flere selskaper opplever at det er problematisk å jobbe på denne måten, og at det fører til dårlige produkter og misfornøyde ansatte.

 

Jeg gidder ikke gå inn på detaljer, det finnes nok om Agile på nett, både fra de som mener det er totalt pissrør og fra de som er "nyfrelst".

 

https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church?share=1

https://news.ycombinator.com/item?id=5406384

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

 

Dette blir vel som å banne i kirken, da de som har lest Bibelen ("Manifestet") som oftest er totalt hjernevasket og vil forsvare sin "religion" med nebb og klør.

[ButterScotch]

Smidig er fint det, så lenge det ikke heter SCRUM, har begrenset med møteaktivitet, ikke brukes som unnskyldning til å mikroadministrere utviklerne, ikke legger all risiko på leverandøren, ikke brukes som botemiddel for bestillere som ikke vet hva de vil ha, osv.

[Kristofer Selbekk]

Kan jeg bare peke ut hvor frustrerende dette cover-bildet til denne saken er? Hvorfor i all verden skal du skrive meta-tags med tusj? Hvorfor bytte på å skrive meta og META? Hvorfor ha meta tags med verdien title? Det er da vitterlig ikke vits å ha keywords-metataggen med lenger anyways! Hvorfor holder personen på bildet en svart tusj som skriver hvitt? Og hvorfor skriver personen speilvendt for seg selv? Hvorfor er det en tom javascript-blokk - og hvorfor spesifisere type-attributten (både der og på link-taggen)?

 

Og til slutt, hvorfor i all verden har man innført et lite touch med java / jsp-helvete? Så jeg kan relatere?

 

arghhhh

[Paynster]

Problemet er stort sett konsulenter som "møter ihjel" utviklingen. Byråkratiet rundt koster ofte 2/3 av et budsjett, og det er ofte der det sprekker.

 

Smidig utvikling er viktig, ja, men som @adeneo og @ButterScotch sier så styr klar Agile/SCRUM.

 

Test-drevet utvikling er et minimumskriterie for all utvikling, men ikke glem den aller viktigste utviklingsmetoden, GTCD.

 

Get The Crap Done.

[0laf]

Kan jeg bare peke ut hvor frustrerende dette cover-bildet til denne saken er?

 

For å ikke snakke om

<script language="javascript">

Som ble utdatert på nittitallet en gang...

[quantum]

Det skal altså være smidig, men ikke agile. Jaja ... ikke rart det går trått, for å si det sånn ...

[Thomas Arp]

Det eneste som egentlig manglet var at det offentlige skulle hive seg på Agile/Scrum bølgen å bli religiøse, for dette er mer religion enn det er noe annet.

 

Dette med "smidig" utvikling er ikke nødvendigvis bare positivt, stadig flere selskaper opplever at det er problematisk å jobbe på denne måten, og at det fører til dårlige produkter og misfornøyde ansatte.

 

Dette blir vel som å banne i kirken, da de som har lest Bibelen ("Manifestet") som oftest er totalt hjernevasket og vil forsvare sin "religion" med nebb og klør.

 

Som det kommer frem i en av kommentarene på en av de sidene du lenket til, er "smidig" egentlig bare det motsatte av "fossefall" eller BDUF.

Jeg synes det høres ut som en god idé å ha mulighet for å justere målene underveis, etter hvert som vi vet mer om hva man kan oppnå. Det er hva jeg mener begrepet "smidig" dekker.

 

Mener du at man bør låse seg til den første visjon man har, den plan man lager når man vet aller minst om hvilke utfordringer man vil komme bort i i forbindelse med implementasjonen? I så fall er jeg redd du selv høres litt religiøs ut.

[quantum]

 

 

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

 

 

 

 

At man faktisk gjør de samme tingene _fortere_, er vel en av de tingene jeg _ikke_ har fått med meg at man skal oppnå med Scrum ... snakker om stråmann ...

[0laf]

Jeg synes det høres ut som en god idé å ha mulighet for å justere målene underveis, etter hvert som vi vet mer om hva man kan oppnå. Det er hva jeg mener begrepet "smidig" dekker.

 

Mener du at man bør låse seg til den første visjon man har, den plan man lager når man vet aller minst om hvilke utfordringer man vil komme bort i i forbindelse med implementasjonen? I så fall er jeg redd du selv høres litt religiøs ut.

 

Jeg antok at man i kronikken henviste til "smidig metodikk" som en direkte oversettelse av "agile development", for det var slik det fremsto, og det er som regel det man mener når man snakker om "smidig metodikk" ?

 

Mange av begrepene og forklaringene i kronikken minner mye om den nærmest religiøse tilnærmingen enkelte har til "smidig", og disse "enkelte" er nesten aldri selv utviklere, men nettopp mellomledere, prosjektledere, scrum-mastere eller hva de nå enn kaller seg selv. "Stolvarmere" er ofte en mer treffende beskrivelse.

 

Dersom det er snakk om "smidig", slik det vanligvis defineres i bransjen, så er definisjonen langt snevrere enn din oppfatning av ordet, og er noe som er godt definert og forholdsvis spesifikt.

 

Hva du mener "smidig" er, er derfor ikke så veldig interessant så lenge "smidig utvikling" er definert av et sett prinsipper nedtegnet i "Manifestet for Smidig utvikling".

 

Er det snakk om Scrum eller enkelte andre slike "systemer", er reglene definert ned på detaljnivå for hvordan alt skal foregå, å gjør det bare enda verre.

 

Som jeg også nevnte i mitt forrige innlegg er ikke dette noe jeg gidder å gå i detalj på, ønsker man å lære "smidig utvikling" så kan man gjøre det på sin egen tid.

Dette interesserer heller ikke meg spesielt, å jeg gidder derfor ikke diskutere det noe særlig ettersom min erfaring er at man enten er "frelst", eller at man mener det er bare "svada".

Det er få som ligger midt i mellom, selvfølgelig med unntak av de som ikke vet hva "smidig" er, og aldri har forsøkt det.

 

Jeg har jobbet en del med smidig utvikling, også Scrum, og mener selv det er fullstendig tøv.

Jeg blir derfor ikke særlig overrasket når det offentlige nå kaster seg over "smidig utvikling" med stor iver, og mener dette er redningen for alle de fallerte offentlige IT-prosjektene vi har sett de senere årene.

Jeg er selv svært skeptisk til dette, men med uttrykk som ;

 

"...tverrfaglige team, å jobbe basert på hypoteser og kundeinnsikt, utvikle enkle prototyper, teste dem, forbedre dem – og i form av små skritt der feil ikke blir særlig kostbare, men desto mer lærerike. Summen av mikrohendelsene/testene gjør at den samlede brukeropplevelsen blir bra"

 

så høres det unektelig veldig flott ut.

Sannheten er nok at det også fører med seg utstrakt møtevirksomhet, skjemavelde, og veldig mye annet som tar tiden vekk fra utviklerne, men som gjør at "stolvarmerne" får mer å surre med i løpet av arbeidsdagen, men dette er jo noe man er vant til offentlige etater. Flere byråkrater fører dog neppe til bedre software.

 

Som utvikler er man jo ofte litt i "sonen" når man kommer i gang, å endelig har fått satt opp alt, satt seg inn koden igjen osv. De fleste utviklere kjenner seg nok litt igjen, og arbeidsdagen går fryktelig fort når man er oppslukt i programmeringen, det er ofte helt utrolig hvor fort timene flyr.

 

Når man da flere ganger daglig skal stoppe opp i arbeidet, for å fylle ut skjemaer, være på møter, teste mikrohendelser, kodesnutter på tre linjer og den slags, kun for å forsøke å oppdatere mellomledere, scrum-mastere og andre som egentlig ikke har noe greie på kodebasen, men som kun har ulne mål om hypoteser og "brukeropplevelser", så virker det ofte mot sin hensikt, man får rett og slett gjort mindre, og resultatet blir på sikt dårligere.

 

I motsetning til hva artikkelen påstår når forfatterne hevder at ;

 

"Dette er fremgangsmåten alle toneangivende teknologiselskaper – i Norge og internasjonalt – jobber etter"

 

så virker det som de fleste større selskaper går vekk i fra dette igjen, etter å ha forsøkt det i en periode.

Særlig Scrum var veldig populært for noen år siden, men viser seg ofte å være noe skikkelig herk som de aller fleste selskaper ikke får noe greie på.

Jeg synes de lenkene jeg postet beskriver mye av det negative rundt denne tilnærmingen på en god måte.

 

Min personlige erfaring er nærmest ensidig negativ, men hadde jeg noen gang jobbet i et miljø med "smidig" utvikling som faktisk fungerte, så hadde kanskje jeg også vært "frelst", hvem vet, jeg har dog min sterke tvil til at dette er noe som faktisk fungerer hos Ruter, og kanskje enda mer tvilsom er jeg til at dette er noe som vil være til gode for offentlig sektor, tvert i mot tror jeg det vil føre til mer inkompetanse og mindre produktivitet, å det sier litt, for når det kommer til produktivitet skulle man tro at de fleste offentlige IT-prosjekter kun har en vei å gå, og det er ikke nedover.

 

Jeg personlig mener at man kommer mye lengre ved å jobbe mer tradisjonelt, å la utviklerne få jobbe mer i fred osv, men dette forutsetter at man har kompetente mennesker i arbeid, og at disse prater sammen, slik at UX, front-end, back-end og alle de andre komponentene, uansett hva det måtte være (IT-prosjekter kan spenne om så mangt) fungerer som tiltenkt.

Gjør man det, trenger man ikke ha møter hver dag, eller fylle ut skjemaer for å forklare for mellomlederen hvor mange linjer kode man klarte å produsere per time eller lignende.

 

Kort summert, så mener jeg altså at dersom selskapene har kompetente medarbeidere, så trenger man ikke møtevirksomhet og skjemaer flere ganger om dagen for at man skal utvikle gode produkter, heller tvert i mot, de fleste utviklere jobber langt bedre uten å bli heftet med den slags vås.

 

Som noen eksempler, så er både Google og Facebook per definisjon "smidige" i måten de utvikler produkter på, men begge selskapene vil gjerne ha seg frabedt å bli kalt nettiopp "smidig" ettersom de mener slike merkelapper, og særlig systemene som ofte følger med, fører med seg mer negativt enn positivt.

I stedet er som regel fokuset på mest mulig frihet for utviklerne, og teamene administrerer gjerne seg selv uten noe behov for hverken mellomledere eller fastsatte regler om "smidighet", problemet er selvfølgelig at dette forutsetter at man har høyst kompetente utviklere som kan tenke selv, noe det offentlige Norge ser ut til å ha manko på.

 

Endret 5. desember 2016 av adeneo

[quantum]

 

Er det snakk om Scrum eller enkelte andre slike "systemer", er reglene definert ned på detaljnivå for hvordan alt skal foregå, å gjør det bare enda verre.

 

 

 

Smidig utvikling i praksis er altså å underlegge seg rigide og detaljstyrende regelverk? Artig anskuelse ...

Endret 6. desember 2016 av quantum