Agilefall og watergile: Virksomheder går i stå i vadestedet på vej mod agil

Det er helt ekstremt, hvor lidt af teorien der har ramt virkeligheden, siger DevOps-konsulent.

Selvom agil-udvikling som koncept er årtier gammelt, er mange virksomheder gået i stå i et grænseland, hvor agil mest af alt ligner en sminket vandfaldsmodel.

Partner Leif Sørensen, konsulentvirksomheden Praqma: Jeg oplever ikke, at mange leverer tidligt og ofte. Illustration: Praqma

Én ting er at udpege scrum-masters og holde korte møder på sine fødder. Noget helt andet er rent faktisk at leve op til formålet med den agile udviklingsmodel: at levere hurtigt og ofte.

»Der er meget lang vej igen,« konstaterer Leif Sørensen, der er partner i Praqma, der vejleder virksomheder i DevOps og continous delivery.

Læs også: DevOps-ekspert: Udviklere bliver bedre, hvis de selv skal lide under dårlig kode

»Jeg oplever, at mange har set agilt som vejen frem, og så har man implementeret Scrum. Men det agile manifest siger jo, at fordelen er at levere tidligt og ofte til dine kunder, og det oplever jeg ikke mange steder,« siger han til Version2.

Resultatet er, hvad Leif Sørensen kalder Agilefall eller Watergile - en uskøn hybrid mellem den klassiske vandfaldsmodel og den agile udviklingsmodel.

Når konsulenten præsenterer begreberne for virksomheder, griner de og nikker genkendende.

»Jeg har ikke været ude et sted, hvor de siger: 'Det passer ikke'. Det er helt ekstremt, hvor lidt af teorien der har ramt virkeligheden. Man er gået ind i agil udvikling, men der er ikke mange steder, man har taget hele leverancedelen højtideligt,« siger Leif Sørensen.

Agil med en hammer

Hos it-virksomheden Nagarro har man et andet begreb for tilfælde, hvor agil-implementeringen gik i stå: waterfall med standups. Det sker ikke mindst, når virksomheder forsøger at tvinge en agil transformation igennem på rekordtid.

»Hvis folk er vant til en seks måneders produktionscyklus, så kan du ikke sige, at vi kører en 14-dages produktionscyklus fra i morgen,« fortæller Kanchan Ray, der er teknisk VP hos Nagarro.

Læs også: Træt af it-monolitten? Prøv en microservice

»Vi arbejdede med et selskab, hvor der var en top-down-beslutning om at arbejde agilt. Men mange mennesker blev freaked out. De har lavet kode på en bestemt måde i årtier. Og så bliver de bedt om at lave peer-programming eller mob-programming. Og det gør folk nervøse,« fortæller han og tilføjer:

»Det går sjældent godt, hvis du indfører agile med en hammer.«

Meget sværere end at implementere Scrum

Scrum er blevet implementeret meget bredt, vurderer Leif Sørensen. Men selv hvis Scrum indføres efter bogen, er agil udvikling ikke i sig selv nok til at gøre en virksomhed agil hele vejen fra programmør til bruger.

»Du skal have agil kvalitetssikring, så du kan stole på det, du leverer, og du skal have agil deployment - og det er meget sværere end at introducere Scrum,« understreger Leif Sørensen.

»Det at turde levere nye versioner af ens applikationer flere hundrede gange om ugen - det kræver en hel masse mere,« tilføjer han.

Læs også: De stærke argumenter for agile metoder i enhver organisation

Kanchan Ray oplever forskel på virksomheder i forhold til f.eks. at automatisere test og deployment. I en app-virksomhed, hvor man skal levere et stykke software til 1.000 forskellige smartphones og skalere fra tusind til millioner af brugere på kort tid, er det nemt at få øje på fordelene. Men sådan er det langtfra altid:

»Hvis du deployer en business-applikation som et ERP-system, tænker du måske: 'Hvorfor bruge tid på at automatisere test af alle usecases, når jeg kan få brugere til at teste det?'. Og sådan er der stadig folk, der tænker.«

»Men hvis man laver den investering, så man er i stand til at udføre automatisk test, så er livet mere simpelt. Så ved du, at din mobil-app virker til alle telefoner, og din web-app virker til de her 50 kombinationer af browsere og styresystemer. Det ville du aldrig gøre manuelt,« siger han.

Baby-skridt ud af vandfaldet

I virksomheder med legacy-systemer og it-afdelinger med mange års erfaring med en bestemt arbejdsmodel, er agilitet ikke et tiltag, der kan løses ved at udsende et memo, understreger Kanchan Ray.

Hvis en konservativ it-afdeling sendes på kursus i agiludvikling, vil de fortsætte, som de altid har gjort, når de kommer hjem. Derfor skal holdet gerne bolstres med garvede agile udviklere, mens produktionscyklussen forkortes i etaper.

Læs også: Er du obs på DevOps?

»Der er ikke noget i vejen med at indføre agile i baby-skridt,« siger Kanchan Ray og fortsætter:

»Lad os se, om vi kan lade, som om vi er agile, i et stykke tid. Og se hvordan det går. Og lad os være ærlige omkring det. Du får ikke noget ud af at gøre folk nervøse.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Jünckow

Hvorom jeg er helt enig i at virksomhederne er fanget midt i vadestedet og at agil transformation i Enterprise er op ad bakke, er jeg også bekymret for den definition af Scrum der gives udtryk for i denne artikel.

Scrum siger ikke noget om at det handler om at kunne deploye 1000 gange om ugen. Efter bogen siger scrum at hvert sprint leverer en potentiel releaseable ny version af produktet - en såkaldt incremental. Dvs. er dit sprint på 2 uger, så er forventningen at der kan releases en ny version hvis man måtte ønske det hver 2. uge. Det er stadig vanvittig meget oftere end et typisk vandfaldsforløb hvor en ny version kan tage halve eller hele år, men det er altså også meget mere opnåeligt for Enterprise virksomheder end scenariet om at skulle kunne release adskillige gange dagligt - vi skal også passe på ikke at skræmme folk ved at få det hele til at fremstå uopnåeligt og urealistisk.

Scrum efter bogen er et framework - der er mange ting som man kan implementere indenfor dette framework, som komplimenterer Scrum godt - herunder automatisk test, CI/CD, TDD osv, - men rent faktisk siger Scrum intet om dette. Det er værktøjer du kan bruge der understøtter en agil process , men du kan også lade være hvis et andet setup passer jeres organisation bedre. Det synes jeg er en vigtig pointe.

  • 4
  • 0
Denny Christensen

Der er så heller ikke noget der tilsiger at en release skal sættes i produktion, der kan være andre dele af IT eller organisation der ikke er klar til dette.

Det er altid svært 100 pct at implementere en arbejdsform, hvis ikke hele organisationen omkring er klar til det, og en del brugere og sponsorer ønsker at deres platform er stabil over længere tid og at forandringer kommer i pakker man kan træne medarbejdere i.

Så en release der ikke påvirker UI eller adfærd på en måde der kræver noget af andre er fint, andre release pakker må vente af andre årsager.

Og ellers er jeg enig i at hybrider af metodiker tiere er kompromiser end fornuft - men det skal man altså også kunne forholde sig til.

  • 0
  • 0
Timothy Harris

It is true that you can run SCRUM without continuous integration, continuous delivery and continuous deployment.

Really what you are doing is following a framework, which provides some rituals and processes that can be beneficial.

But this doesn't make you agile in itself. You can run sprints, demos, retrospectives and any other rituals you want. But that won't really provide the benefit, most people want. Without doing automated test how can you keep a velocity and quality that will result in a potentially releasable version? I mean what are you going to. Allocate half your sprint to manual testing? That is not very agile in my mind. Manual testing is time consuming, error prone and inefficient. So if you want to verify that a version is releasable after a sprint you need to automate this. For this to work, reliably, you will need to implement some level of CI/CD. Verifying small changes is much easier and more efficient than large changes.

No, you don't need to do continuous deployment. It is quite possible that the business doesn't need that speed of releases. But, in my opinion, if you want to say you are agile. I don't see how you can do that without some level of CI/CD.

  • 1
  • 0
Martin Jünckow

There are lots of good arguments for CI/CD, unit testing, integration testing etc.
It is however an evolving area seeing changes to best practices almost yearly, which is probably the reason Scrum is not too keen to go into these implementation details.

Scrum is a framework based on universal best practices and allowing quite a lot of freedom for the implementation placeholders. These placeholders exists because what is the best implementation may vary due to many factors, such as organisation size, the product being developed, team composition etc.

I am not objecting against the general trend we see at the moment that goes towards automating things to the point where we can release 1000 times a week - there are many project types where this is great.

All I am saying is that this is an extreme agile process and I would be more than happy if we can start by at least getting Enterprises to work in a standard agile process. And for Enterprises it is not always so easy to be this agile - there are things such as government regulations, quality assurance and data-integration from teams spread out across the world that you have to factor in. These things will slow you down, sometimes to the point where delivering on a 2 week sprint is quite an achievement!
Let's start by celebrating that.

  • 0
  • 0
Leif Sørensen

Hvis det fremgår at det handler om at levere 100 eller 1000 gange per uge, var det helt sikkert ikke meningen med artiklen. Det var heller ikke meningen at angribe SCRUM - SCRUM er fantastisk! Pointen er bare at agilitet skal måles på at levere "tidligt og ofte" (og jeg er helt med på det betyder noget forskelligt fra sted til sted). Under alle omstændigheder kræver det meget andet end en agil metode, og jeg ser en del steder hvor det ikke lykkes at levere hverken tidligt eller oftere

  • 3
  • 0
Martin Jünckow

Hej Leif

Jeg kan se artiklen er blevet opdateret i mellemtiden og formuleringen ændret i det problematiske afsnit.

Ellers ganske enig i dine pointer og et vigtigt emne at få mere spot på.
Jeg er bekymret over den negative holdning jeg oftere og oftere møder angående Scrum, fordi de færreste faktisk har oplevet det virke - de har oplevet de her sære hybrid-versioner af Scrum og de konflikter det giver når man på forretningssiden stadig insisterer på at køre vandfaldsforløb.

Faktisk er jeg af den overbevisning at det er en fejl at Scrum kun forsøges indført på IT siden, skal det virke ordentligt skal forretningenssiden med. Vi har gjort forsøg i nogle af de helt store virksomheder hvor også forretningsfolkene og ledelsen blev inddraget i Scrum teams og udførte opgaver fra sprintloggen. Eks. opgaver som udarbejdelse af blue-print dokumenter, budget-planlægning, data behovsanalyse, user journey udarbejdelse og lign. som vi oprettede stories på, refinede og inddrog i vores sprints.

I starten var der en del skepsis - det er svært at ændre på folks vaner, men da vi afsluttede projektforløbet efter 6 måneder var begejstringen stor for denne måde at arbejde på og hvad vigtigere var at både vi IT folk og forretningensfolkene havde fået en meget større forståelse og respekt for hinandens arbejde - både det at være med til at refine sådanne opgaver, men især også review af resultatet er noget der er sundt for begge sider. Et andet interessant fænomen var at IT udviklingen til sidst i projektet var mindre kritisk end forretningsopgaverne og at vi nu var istand til at allokere IT udviklere til at arbejde på forretningsopgaverne istedet - faktisk med ganske stor success selvom det måske ikke lige er den type opgaver de normalt sidder med i det daglige.

Desværre kom der ny CEO til i virksomheden derefter og de agile eksperimenter døde der pga. reorganiseringer.
Sådan er livet i Enterprise :-)

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize