olav m.j. christiansen bloghoved olav christiansen

Arbejder du agilt?

Som selvstændig konsulent har man et stort netværk, og igennem årene har det en tendens til at blive større og større.

En gang imellem er der en ny konsulentformidler, der kontakter mig, og som regel vil jeg da gerne høre hvad de kan tilbyde mig.

For et stykke tid siden havde jeg sådan én i telefonen, og på et tidspunkt fik jeg et spørgsmål, der overraskede mig:

»Arbejder du agilt?«

Når jeg er overrasket over det, skyldes det at jeg ganske enkelt ikke kan forestille mig nogen i IT-branchen der ikke her i 2020 arbejder agilt i en eller anden grad.

Jeg var faktisk lige ved at falde ned af stolen af overraskelse over lige det spørgsmål. Jeg er bl.a. Scrum Master, og det agile skulle gerne fremgå af mit CV mange steder. Endvidere skriver jeg jo lidt på denne blog (når jeg får mig taget sammen til det - har desværre af forskellige grunde været lidt hængt op på det sidste).

Men måske skyldes min overraskelse at jeg troede, at han spurgte om jeg arbejdede efter disse retningslinjer:

Manifest for agil softwareudvikling

Vi afdækker bedre måder at udvikle software på
ved at gøre det og ved at hjælpe andre med at gøre det.
Gennem dette arbejde har vi lært at værdsætte:

  • Individer og samarbejde frem for processer og værktøjer
  • Velfungerende software frem for omfattende dokumentation
  • Samarbejde med kunden frem for kontraktforhandling
  • Håndtering af forandringer frem for fastholdelse af en plan**

Der er værdi i punkterne til højre,
men vi værdsætter punkterne til venstre højere.

(fra https://agilemanifesto.org/iso/dk/manifesto.html)

Men i virkeligheden spurgte han måske om jeg arbejdede efter denne metode:

Illustration: Dr. Ian Mitchell

Fra https://en.wikipedia.org/wiki/Scrum_(software_development)

Efter at have arbejdet som konsulent i rigtigt mange år på især ret store projekter (for både offentlige og private kunder), må jeg desværre konstatere at der mange steder er gået noget galt i den såkaldte agile transformation.

Mange tror at man ikke kan arbejde med 'vandfald' samtidig med at man også arbejder agilt (agile scrum fall, water-scrum-fall, scrumfall og lignende betegnelser), men det er nu en sandhed med modifikationer.

Jeg tror faktisk aldrig jeg nogensinde har set et projekt, som var entydigt 'vandfald' eller entydigt 'agile'. Der vil altid være en tilpasning, der gør at det bliver en form for mix, typisk enten et topstyret projekt (f.eks. PRINCE2) med eller uden faste krav suppleret med f.eks. Scrum nedenunder til at bygge produktet eller måske i stedet en agil model med en overbygning lagt på til det, der ikke ligger i den valgte agile model.

Men mange tror desværre fejlagtigt at følgende er den ultimative sandhed:

Scrum = Agile

Altså: Scrum er en agil metode, og hvis vi vil køre agilt skal vi vælge Scrum. De gør det ikke altid bevidst. Jeg hører mange mennesker bruge udtrykket 'agile', hvor de faktisk i virkeligheden mener Scrum - måske fordi de ikke har set så meget andet.

Her er en væsentlig pointe, som jeg gerne vil argumentere for i det efterfølgende:

Rent Scrum er ikke agilt

Lad os først lige kaste et blik på hvad Scrum egentlig er. Man kan f.eks. se denne video:
https://www.youtube.com/watch?v=9TycLR0TqFA

Her kan vi bl.a. se at der kun er tre roller i 'ægte' Scrum:

  • Product Owner
  • ScrumMaster
  • Team

Så er det jo bare ærgerligt hvis man har en jobbetegnelse som f.eks. projektleder, test manager, forretningsanalytiker, it-arkitekt osv. osv. osv. Skal man køre ægte Scrum, bliver man nødt til at finde sin plads i en af de tre roller. Ellers er man udenfor Scrum, og så er man jo slet ikke med.

Tough luck!

(udviklere og testere er implicit med i teamet, så de kan tage det helt roligt)

Så er der processerne og ceremonierne (som man ofte kalder det indenfor Scrum-verdenen). Der er forskellige faste begivenheder og møder, typisk følgende:

  • Sprint Planning
  • Daily Standup (også kaldet Scrum)
  • Sprint Review og Retrospective

Det er selvfølgelig lidt forskelligt hvor meget tid man bruger på disse møder, men min erfaring (ud fra mange projekter, hvor man anvender disse 'ceremonier') siger mig at man roligt kan regne med at bruge minimum fire timer i snit per uge bare på møder (og jeg har også set det meget værre). Hvad værre er: Mange steder holder man disse møder udelukkende fordi det står i en bog at man skal. Ikke fordi det nødvendigvis passer ind i det aktuelle projekt eller den måde man arbejder på, men kun fordi det står i en bog.

Det samme gælder måden man løser problemer på. Hvis der opstår udfordringer, som gør at man ikke kan nå de ting, man havde planlagt i sprintet, så har man en 'impediment', altså en forhindring. Og hvis teamet ikke lige selv kan løse det, skal ScrumMasteren finde ud af hvordan man løser problemet:

https://www.scrum.org/resources/what-is-a-scrum-master

Her er endnu en udfordring med processen, for hvad er en ScrumMaster egentlig, og skal vedkommende have specielle egenskaber? Der kræves i hvert fald ikke nogen form for teknisk kunnen - ejheller egentlige projektlederkundskaber (for en projektleder findes slet ikke i Scrum). Jeg har set mange forskellige varianter af hvem der er ScrumMaster: En af udviklerne (ofte på skift), en teamleder, en projektleder eller en decideret ScrumMaster som ikke har andet ansvar. Man kan nok regne ud at måden forhindringerne bliver løst på, langt hen ad vejen afhænger af hvem der skal løse det og hvilken baggrund vedkommende har.

I Scrum er man ligeglad med det. Her står der bare listet som en del af ansvaret:

"Removing impediments to the Development Team’s progress."

Så må man jo bruge sin fantasi og finde ud af hvordan det håndteres ....

Det største problem (som jeg ser det) er nok at virksomheder og andre organisationer - når de forsøger at blive 'agile' - ofte går helt firkantet efter netop Scrum-modellen, dvs. disse ganske få faste roller og de helt samme ceremonier (møder m.v.) uden skelen til om det giver fornuft i det aktuelle projekt og den aktuelle organisation - og uden at tilpasse modellen overhovedet.

Her vil jeg lige pointere den første af de fire linjer i det agile manifest - og efter min mening den allervigtigste:

Individer og samarbejde frem for processer og værktøjer

Hvad betyder den sætning så i praksis? Her er mit bud: Man skal selvfølgelig have nogle rimeligt faste processer og værktøjer i et givet projekt. Men hvis man står i en opstået situation, hvor processerne eller værktøjet ikke rækker længere og ikke hjælper, så bliver man nødt til at gribe til "individer og samarbejde".

Hvad kan man så gøre, spørger den kloge læser jo nok? Der er masser af muligheder, f.eks.:

  • Lav om på processerne
  • Tilpas dem
  • Ignorer processerne
  • Lad være med at bruge dem lige her
  • Fjern processerne
  • Lav nye processer

(det samme gælder i øvrigt værktøjerne)

Altså: Lyt nu til den sunde fornuft i stedet for bare at gøre noget, fordi det - står - i - en - bog!

Desværre må man slet ikke gøre nogle af de ting jeg foreslår, hvis man kører ægte Scrum. Der er ritualerne (og dermed processerne) så vigtige, at man for at kunne følge modellen bliver nødt til at overtræde det første og allervigtigste bud i det agile manifest.

Dette bringer mig til denne konklusion:

Scrum != Agile

NB: Dette indlæg er heller ikke en sandhed, bare fordi jeg har skrevet det. Det giver kun mening, hvis du som læser synes det lyder fornuftigt.

https://agilecomicstrip.com/2018/03/19/common-sense/

PS: Jeg ved stadig ikke om jeg egentlig arbejder agilt ...

Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Henrik Eriksen

Det ser jeg tit i jobannoncer til IT-stillinger, hvor man også efterlyser at man kan dit eller dat - visse ting som kun er en parantes i programudvikling og man næsten ikke kan være udvikler uden at kunne.

Det får jobannoncer til at se ud som om det er en ikke-IT-kyndig som har brokket indholdet sammen og spædet det op med nogle bullshit-bingo ord.

Det er ekstra tåkrøllende hvis lederen af IT-afdelingen ikke selv ved ret meget om IT, og hævder at "her arbejder vi agilt!" samtidig med at arbejdsprocessen er 100% vandfald.

Jeg har endnu ikke været på en arbejdsplads hvor lederen ikke afholdt 'scrum' hver morgen, som ikke havde det fjerneste med scrum at gøre.

Jobanonncer er i det hele taget frygelige at læse. "Har du lyst til at arbejde i en spændende virksomhed, hvor udvikling og nytænkning er i højsædet, og bla bla bla."

Man skimmer vrøvlet indtil man finder ud af hvad man skal kunne, og hvad man skal lave. Det er det eneste der er interessant når man søger et ny job. Det, og så adressen.

  • 13
  • 0
#2 Olav M.j. Christiansen Blogger

Det får jobannoncer til at se ud som om det er en ikke-IT-kyndig som har brokket indholdet sammen og spædet det op med nogle bullshit-bingo ord.

Tak for kommentaren. Ja, vores branche er desværre fyldt med bullshit, og jeg forsøgte faktisk i et tidligere indlæg at finde de bedste ord fra Version2 til en rigtig bullshit bingo-plade. Men jeg bør nok følge op på det på et tidspunkt. Vi blev ikke helt færdige.

Der er dog også nogle i branchen, som gør op med ceremonierne og forsøger sig med noget andet, f.eks. disse her: https://www.usehaystack.io/blog/we-cancelled-standups-and-let-the-team-b...

  • 5
  • 0
#3 Rune Hansen

Det virker heldigvis til at folk på Version2 holder sig fra at svinge sig helt op i "bull shit" skalaen (nok af risiko for at der rent faktisk er nogen der piller én ned igen). Med alle de forkortelser og nye udtryk der vælter frem for tiden, er det lige før man kronisk bør rende rundt med et leksikon under armen for at føre en konversation. Heldigvis er der forskel på at lære alle forkortelser og "bull shit" termer uden ad, og have en reel indgående forståelse af grundpricipperne bag og evne til at se hvor de kan udnyttes optimalt. Det gælder branchen generelt og ikke bare projekt styrring. Synes dog det er allerværst når man begynder at bevæge sig ud i lagene omkring alle "håndværkerne", sælgere, konsulenter, IT-ledere (kandidater) og resten af det store lag af folk der lukrerer på formidlingsdelen. (Alle dem der ligner et stort spørgsmålstegn hvis man siger ord som "variabel", SQL, sudo, men som sjovt nok har lært alle "bull shit bingo" ordene uden ad)

  • 1
  • 0
#4 Olav M.j. Christiansen Blogger

Det virker heldigvis til at folk på Version2 holder sig fra at svinge sig helt op i "bull shit" skalaen (nok af risiko for at der rent faktisk er nogen der piller én ned igen).

Faktisk har bullshit i IT været oppe at vende flere gange her på bloggen, bl.a. her: https://www.version2.dk/blog/bullshit-bingo-1-1086377 https://www.version2.dk/blog/agile-bullshit-1087247 https://www.version2.dk/blog/hvem-bullshitterne-1087961

Jeg tror du har ret. Det er ikke blandt version2's læsere vi finder de fleste bullshittere. Men hvordan håndterer folk så de rigtige bullshittere? Jeg er sikker på at mange læsere har mødt nogen.

  • 1
  • 0
#5 Michael Cederberg

I mine øjne er det vigtige ved agil udvikling netop erkendelserne der ledte til det agile manifesto. Det handler om at levere det produkt kunden faktisk gerne vil have (men ikke nødvendigvis har artikuleret eller forstår kravene til) på en effektiv måde.

Det agile manifesto er kommet ud af en række erkendelser: Processer er gode men ikke altid og man skal ændre dem eller ignorere dem når de ikke virker. Når projektet starter ved kunden sjældent hvad han vil have - et projekt er en læreproces for alle. Dokumentation ender nemt med at blive "write only". Og vigtigst: Ingen plan overlever kontakt med fjenden aka "Everyone has a plan until they get pounched in the mouth" (Mike Tyson).

Det er alt sammen fornuftigt. Men ingen starter et kommercielt projekt uden at have et billede af hvad projektet leverer, hvornår og hvad det koster. Og når der først der ligger et budget, en beskrivelse af produktet og en deadline så hænger man på limpinden. Der ligger også ofte en forventning om at produktet er dokumenteret – også selvom det meste dokumentation der skrives aldrig bliver læst. Og det kan godt være at projektet ikke passer helt ind i firmaets test-proces eller release-proces, men der er også ofte værdi for virksomheden i at ting sker på samme måde også selvom det kan virke suboptimalt i nogen tilfælde.

Så ligesom så meget andet i livet handler det om at finde en balance mellem modstridende krav. På en pragmatisk måde. IT projekter adskiller sig fra mange andre projekter ved at vi altid bygger noget nyt og anderledes. Hvis vi bygger noget på samme måde som vi allerede har gjort tidligere så er vi på vildspor. Hvis vi kan, så skal vi genbruge tidligere lavet kode. Hvis man bygger et bygning, så kan man måske genbruge designet fra et tidligere projekt et andet sted men man kan ikke genbruge den fysiske bygning.

For mig handler agil udvikling først og fremmest om at alle erkender at kunden ikke ved præcist hvad han vil have når projektet starter, udviklerne forstår ikke helt hvad kunden ønsker og ved ikke præcist hvordan det skal bygges. Undervejs bliver alle klogere. Agil udvikling handler om at italesætte denne usikkerhed sådan at alle er (nogenlunde) komfortable med den.

  • 3
  • 0
#6 Philip Juhl

Jeg kan sagtens genkende det ligehedstegn der sættes mellem Scrum og Agile og det ligehdestegn at Scrum og Agile passer lige godt til alle aspekter af Software udvikling.

Jeg kan desværre også genkende den tolkning du laver for at udviklingsteamet i Scrum kun består af softwareudviklere og testere. Det nævnes i videoen du linker til at det f.eks. kan bestå af udviklere og testere og i Scrum Guiden står der hverken software udvikler eller tester. Så hvordan drager du den konklussion at der f.eks. ikke kan være en forretningsanalytiker i et udviklingsteam der bruger Scrum eller at organisationer der bruger Scrum ikke har andre roller?

Når du skriver processerne ikke kan ændres, mener du så ændring af Scrum rammeværket eller de processer der bruges sammen med Scrum? Begge dele kan ændres, men hvis Scrum rammeværket ændres, er det ikke Scrum. Det betyder ikke det er bedre eller værre, blot at det ikke er Scrum. Men ønsker man at ændre Scrum rammeværket er det så for at kunne arbejde mere efter de agile principper eller for at bevare de eksisterende ansvar og roller?

For mig kan Scrum være et rigtig godt udgangspunkt for teams der vil arbejde efter Agile principper.

  • 0
  • 0
#7 Olav M.j. Christiansen Blogger

Så hvordan drager du den konklussion at der f.eks. ikke kan være en forretningsanalytiker i et udviklingsteam der bruger Scrum eller at organisationer der bruger Scrum ikke har andre roller?

Hej Philip

Tak for din kommentar. Der kan faktisk godt være en forretninganalytiker eller lignende i et Scrum-team, men ofte ser man desværre at der kun er udviklere og testere i selve teamet. Og så er Scrum pludselig blevet til en masse små vandfaldsprojekter i stedet for at være agil.

  • 1
  • 0
#9 Olav M.j. Christiansen Blogger

Det agile manifesto er kommet ud af en række erkendelser: Processer er gode men ikke altid og man skal ændre dem eller ignorere dem når de ikke virker. Når projektet starter ved kunden sjældent hvad han vil have - et projekt er en læreproces for alle. Dokumentation ender nemt med at blive "write only". Og vigtigst: Ingen plan overlever kontakt med fjenden aka "Everyone has a plan until they get pounched in the mouth" (Mike Tyson).

Helt sikkert. Et af problemer er når man så står med et projekt, hvor kunden egentlig godt ved (sådan ca.) hvad man vil have - man har bare ikke dokumenteret det hele endnu eller lavet en detaljeret plan. Så er det man tager Scrum i brug i en eller anden form. Men glemmer man at tilpasse modellen, sker der ofte det at nogle i projektet tror at man kører rent Scrum og agerer derefter, mens andre har en formodning om at det bliver nødt til at være tilpasset. Så sejler samarbejdet pludselig.

Offentlige projekter bliver f.eks. nødt til at køre i en PRINCE2-ramme, og det kan man ikke så godt ignorere.

  • 1
  • 0
#10 Michael Cederberg

Et af problemer er når man så står med et projekt, hvor kunden egentlig godt ved (sådan ca.) hvad man vil have - man har bare ikke dokumenteret det hele endnu eller lavet en detaljeret plan.

Men kunden ved det kun på et plan ... det kan godt være han ved hvilke features han ønsker, men han mangler typisk viden om usability, teknologivalg, testatbility, code quality, arkitektur, integration patterns, udviklingsmodel efter produktet kommer i produktion, etc. Alt sammen ting der har stor betydning for total cost of ownership for kunden. Derfor kan han heller ikke fra start komme med alle kravene der er vigtige for produktet.

I øvrigt kan man sejle en supertanker gennem den ladeport som "sådan ca." åbner :-)

  • 0
  • 0
#11 Olav M.j. Christiansen Blogger

Men kunden ved det kun på et plan ... det kan godt være han ved hvilke features han ønsker, men han mangler typisk viden om usability, teknologivalg, testatbility, code quality, arkitektur, integration patterns, udviklingsmodel efter produktet kommer i produktion, etc.

I de projekter, jeg taler om, har man faktisk også ofte en god idé om i hvert fald nogle af de ting, du der taler om. Nogle af tingene giver sig selv pga. politikker på området eller f.eks. det man kalder 'compliance krav'.

Det, der er det usikre, er hvor lang tid det tager at bygge skidtet. Estimering er et kæmpestort område i sig selv, som f.eks. Scrum angriber på sin egen måde (typisk ved at måle Story Points).

  • 1
  • 0
#12 Olav M.j. Christiansen Blogger

I øvrigt kan man sejle en supertanker gennem den ladeport som "sådan ca." åbner :-)

Nu prøvede jeg jo sådan set bare at gøre et stort og kompliceret emne meget enkelt, så du skal nok ikke lægge mere i det end det.

Ofte ligger der en omfattende liste af krav og behov fra kunden, men det er ikke ensbetydende med at man anvender en traditionel vandfaldsmodel til at køre projektet efter. Tit ser man en iterativ model, som Scrum er et eksempel på. Men det er faktisk ikke nogen ny opfindelse. Det har man gjort i mange år før nogen fandt på Scrum og 'agile'.

  • 3
  • 0
#13 Povl H. Pedersen

Vi har ikke helt et tilsvarende ord på dansk, og derfor forbinder folk det bare med scrum. For mig er agilitet er adræthed, hurtighed, eller evnen til at gøre noget nyt.

Sålænge man følger en statisk metode, og bare deler opgaver ud til udviklere, så er der intet agilt i det. Så sidder kodekarlene bare og er kodekarle, og de kunne lige så godt være rent vandfaldsudviklere. Den store forskel for dem er de kontinuerte leverancer.

Agilitet er hvis kodekarlen trækkes ud af mørket, møder brugerne, og lidt bliver systemudvikler. Taler med kunden og finder ud af hvad han vil have. Det tror jeg mangler mange steder. Og mange andre steder er kunden "proxiet" af en mand i IT afdelingen der taler på kundens vegne.

Når det så er sagt, så er det vigtigt at huske, at der er mange der har trygheden i at lave det samme i morgen som de lavede i går. De kan godt være kodekarle i et agilt styret projekt, uden selv at være agile. Jeg tror at de fleste medarbejdere IKKE trives ved forandringer, men gerne vil have stabilitet. Og for dem er det fint at de aldrig oplever kunden, at det er samme mellemmand der repræsenterer kunden.

  • 1
  • 0
#14 Olav M.j. Christiansen Blogger

Vi har ikke helt et tilsvarende ord på dansk, og derfor forbinder folk det bare med scrum. For mig er agilitet er adræthed, hurtighed, eller evnen til at gøre noget nyt.

Meget god pointe. Faktisk havde de, der skrev det agile manifest, overvejet at bruge udtrykket 'ligthweight', da det mest var letvægtsmetoder, de kom med (f.eks. Scrum).

Nu blev det så ordet 'agile', der hang ved, og folk kan fortolke det på mange måder. Men du har helt sikkert fat i noget af det rigtige. Det handler blandt andet om at koble forretningen tættere på udviklerne.

Men det handler også om at kunne tage hurtige beslutninger, og der har vi måske den største udfordring.

  • 1
  • 0
#15 Michael Cederberg

Ofte ligger der en omfattende liste af krav og behov fra kunden ...

Min pointe var at der er en række krav der er vigtige for TCO som først træffes i projektet. Fx. arkitekturvalg og teknologivalg som måske ikke er så vigtige for den initielle leverance, men som har stor betydning for produktets levedygtighed på langt sigt.

Det jeg siger er at næsten alle købere af custom IT systemer ikke er i stand til at formulere de krav som er vigtige up-front. Og hvis de er IT svage så er de heller ikke i stand til at forstå konsekvenserne af de arkitektoniske og teknologiske valg der foretages undervejs.

Med en traditionel kontraktmodel hvor man up-front aftaler milestones, krav og leverancer da kommer kunde og leverandør nemt til at have forskellige prioriteter. I den agile model har alle stort set samme prioriteter. Det er styrken.

... men det er ikke ensbetydende med at man anvender en traditionel vandfaldsmodel til at køre projektet efter. Tit ser man en iterativ model ...

Jo men så er vi også ovre i noget der ligner agil udvikling. Jeg er ligeglad hvilken farve katten har, bare den fanger mus. Det vigtigste er at undgå at kunden betaler for leverancer at systemer hvor de ikke kan gennemskue om målene er opfyldt (hvor mange kunder er i stand til ar vurdere kodekvalitet eller testability?). I den agile verden betales for indsats.

Et af problemer er når man så står med et projekt, hvor kunden egentlig godt ved (sådan ca.) hvad man vil have ...

Jeg tvivler på at de kunder eksisterer. Selv dygtige udviklere har svært ved at måle kode- eller arkitekturkvalitet. Men de ved når de ser noget der er dårligt. At kunder skulle være i stand til at sætte krav derom på forhånd har jeg aldrig set (andet end latterlige krav som at alt kode skal have mindst en score på 87 i et eller andet ligegyldigt static code analysis tool, e.lign.).

  • 0
  • 0
#16 Morten Olsen

Jeg undrer mig over at du undrer dig over spørgsmålet hvis du har været i branchen længe. Jeg er glad for at være freelancer, hvad jeg ikke er glad for er, at det desværre for det meste indebærer at mine kontrakter går igennem bureauer der lever fedt på at brugt fem minutters arbejde på at kontakte folk på linkedin, hvor de tit ikke en gang har matchet imellem krav, og hvad der står i ens profil. De rangerer næsten lige så højt som brugtbilsforhandlere og ejendomsmæglere i min verden.

  • 3
  • 0
#17 Mogens Bluhme

Det får jobannoncer til at se ud som om det er en ikke-IT-kyndig som har brokket indholdet sammen og spædet det op med nogle bullshit-bingo ord.

En bekendt gjorde mig opmærksom på efter søgning i Jobindex' arkiv, at da Sundhedsdatastyrelsen skulle ansætte udover lederen 12 sikkerhedsmedarbejdere, skulle kun to vide noget om sikkerhed og databeskyttelse,

Resten skulle være rapportskrivere i et eller andet omfang.

Og hvis det er en ikke-IT-kyndig, som har udfærdiget annoncerne i en bullshit, er det ikke så mærkeligt, at de tiltrækker bulshitt'ere.

Som Einstein sagde:

"No problem can be solved from the same level of consciousness that created it"

  • 1
  • 0
#18 Emil Kampp

Jeg vil gerne dele vores model, fordi vi har en super sær hybrid, som vi netop har udviklet ved at stjæle det vi synes vi kunne bruge og efterladt det, vi ikke synes gav os værdi:

  1. Vi har standups. Vi har identificeret mange situationer, og fået startet en god del gode debatter baseret på hvad der blev sagt på vored daily.
  2. Vi har "epics", som vi scorer ud fra ICE modellen. Baseret på det bliver de prioriteret til et "sæt af sprints"
  3. En epic tager så mange sprint som vi har brug for til vi er tilfredse med kvaliteten. Det giver fordybelse og mange, mange færre bugs og change requests senere.
  4. Et sprint er stadig et selvstændigt, timeboxed, deliverable sæt af opgaver som betyder vi kan efterlade en epic dér, hvis vi har brug for at lave noget andet.
  5. Vi har både civil enginører, business folk, infrastruktur-, app-, api-, og frontend udviklere med på et team, alt efter behovet i en epic.

Nå, det var bare lige det, som jeg ville dele.

  • 2
  • 0
Log ind eller Opret konto for at kommentere