Warning: The magic method Visual_Form_Builder::__wakeup() must have public visibility in /customers/6/2/6/vilma-consulting.dk/httpd.www/wp-content/plugins/visual-form-builder/visual-form-builder.php on line 68 Warning: The magic method Visual_Form_Builder_Form_Display::__wakeup() must have public visibility in /customers/6/2/6/vilma-consulting.dk/httpd.www/wp-content/plugins/visual-form-builder/public/class-form-display.php on line 35 Warning: Cannot modify header information - headers already sent by (output started at /customers/6/2/6/vilma-consulting.dk/httpd.www/wp-content/plugins/visual-form-builder/visual-form-builder.php:68) in /customers/6/2/6/vilma-consulting.dk/httpd.www/wp-content/plugins/download-monitor/src/DownloadHandler.php on line 481 Warning: Cannot modify header information - headers already sent by (output started at /customers/6/2/6/vilma-consulting.dk/httpd.www/wp-content/plugins/visual-form-builder/visual-form-builder.php:68) in /customers/6/2/6/vilma-consulting.dk/httpd.www/wp-content/plugins/onecom-vcache/vcaching.php on line 624 Ikke kategoriseret Arkiv | VILMA Consulting

Kategori: Ikke kategoriseret

Skalere Agil – Sådan kommer du i gang

Skalere Agil – Sådan kommer du i gang

At skalere agil er et emne der synes at poppe op flere og flere steder. PÅ IT-konferencer, blandt ledelsen og når HR starter med at rekruttere en ny medarbejder. Men det at skalere agil er ikke bare én specifik og veldefineret ting der skal gøres. Der findes en længere liste af agile skaleringsrammeværk, kombinationer af rammeværk og metoder opbygget inde i organisationer. Og ja, det har stor betydning hvordan du starter med at skalere agil.

Skalere Agil - nøglen er at starte rigtigt
Skalere Agil – nøglen er at starte rigtigt

Skalere agil – at starte bedst muligt med at skalere agil er nøglen til succes med den skalerede agile rejse.

Skalere agil er et område at færdigheder der kan tillæres, ligesom addition i matematik i folkeskolens små klasser. Men mens addition er entydigt defineret og følger logiske regler (2 + 3 = 5, altid), er det at skalere agil hverken entydigt defineret eller følger en logik, som addition.

Inden vi fordyber os i at skalere agil, ser vi først på hvad agil er.

Agil

Ordet agil er ikke nyt og bruges almindeligt i sproget. Ok, måske mere almindeligt på engelsk end på dansk (omend det faktisk kommer fra latin agilis).

Ifølge Den Danske Ordbog ordnet.dk, har ordet agil følgende betydning og oprindelse

  • OPRINDELSE fra latin agilis, afledt af agere ‘bevæge, handle’
  • hurtig, let og smidig i sine bevægelser SPROGBRUG sjældent
  • SYNONYMER bevægelig, adræt

I relation til udvikling af IT-løsninger er et mere udbredt udgangspunkt det agile manifest

Agile manifest

Rækken af agile teknikker er lang, men de mest udbredte er Scrum, Kanban og XP, om end flere anvendes i Danmark. Helt overordnet kan man sige at hvis et produkt udvikles agilt, er der kun et team der arbejder på det, om end der naturligvis er undtagelser.

Ligesom der er flere måder at organisere arbejdet agilt (fx om det er organiseret omkring en iteration eller ikke), er der tilsvarende flere måder at skalere agil udvikling.  

En helt central forskel til agil på team niveau, er at mere end et team arbejder med det samme produkt. Om det så er 5-8 teams, 25 teams eller 1000 teams der arbejder med samme produkt, afhænger af selve produktets definition. Ved bredere produktdefinitioner er der typiske flere teams der arbejder på samme produkt, hvilket giver mulighed for at håndtere synergier og afhængigheder indenfor produktets domæne. Smalle produktdefinitioner medfører typisk at der er flere produkter i organisationen.

Vi vil nu bevæge os videre ind i det at skalere agil, og de væsentlige skalerede agile rammeværk. Med væsentlige rammeværk til at skalere agil, følger vi listen over hvad de danske organisationer bruger, som afdækket af VILMA Consulting i undersøgelsen du kan læse mere om her.

Hvilke niveauer er der ved at skalere agil

En helt central forskel mellem agil for et (eller få) team(s) og det at skalere agil, er der kun er et niveau når vi taler agil på team-niveau. Der er ikke en porteføljestyring ‘ovenpå’ eller ‘omkring’ teamet. Med andre ord, er det den direkte kontakt mellem stakeholdere og Product Owner der bidrager til indholdet i teamets Product Backlog. Eftersom hvert produkt udvikles af ét team, vil eventuel koordinering mellem teams være koordinering mellem produkter og ikke indenfor et produkt. I det følgende kalder vi dette agil på team-niveau.

Når vi i stedet ser på skaleret agil organisering, bliver koordinering indenfor produktet nødvendig, eftersom flere teams trækker opgaver fra den samme Product Backlog der dækker produktet. Denne Product Backlog dækker opgaver til flere teams, og repræsenterer derfor et højere niveau. Det hyppigste er at se at opgaver for en gruppe på 4-8 teams samlet på denne Product Backlog, men eksempler på grupper med både 10 og 11 teams findes.

Denne gruppering kan gentages for derved at skabe endnu et niveau og derved kan vi se organiseringer med 3, 4, eller endnu flere niveauer for at skalere agil i en organisation. Dette er opstillet herunder.

  • Niveau 1: Teams (fx 5 teams)
  • Niveau 2: Gruppe af teams (fx 5 x 5 teams = 25 teams)
  • Niveau 3: Gruppe af niveau 2-grupper (fx 5 x 25 teams = 125 teams)
  • Niveau 4: Gruppe af niveau 3-grupper (fx 5 x 125 teams = 625 teams)
  • Niveau 5: Gruppe af niveau 4-grupper (fx 5 x 625 teams = 3,125 teams)
  • etc.

Hvis hvert team består af 6 personer i gennemsnit, vil niveau 4 svare til 3.750 personer,  mens niveau 5 vil rumme 18.750 personer, såfremt antallet af teams er som i eksemplet herover.

Rammeværk til at skalere agil

Der er grundlæggende tre måder at skalere agil på i en organisation; 1) implementer et veldefineret rammeværk til at skalere agil. 2) Definér jeres egen måde at skalere agil på. Og sidst men ikke mindst,  3) skab en hybrid af de to foregående. I Danmark har vi eksempler på alle tre måder at takle udfordringen, som beskrevet i artiklen Skalerede Agile Organisationer i Danmark 2019, som du kan læse her https://www.vilma-consulting.dk/da/artikler/.   

De mest udbredte rammeværk til at skalere agil, er SAFe, Nexus, Scrum@Scale og LeSS, som alle er fremkommet mellem 2011 og 2018. Vi vil herfra fokusere på disse.

Nexus

Nexus blev udviklet af Ken Schwaber (medskaber af Scrum) sammen med en gruppe hos Scrum Inc. Nexus rammeværket har været til rådighed siden 2015.

Nexus er en videreudvikling af of Scrum, og er skabt ved at gentage de mekanismerne i Scrum for flere teams og på to niveauer i organisationen. Med andre ord er Nexus baseret på at, mekanismerne der virker for et team, kan virke for en gruppe af teams.

Kort fortalt virker rammeværket til at skalere agil ved at have op til 8 teams i en ”Nexus” (gruppe af teams), hvor de alle arbejder ud fra den samme Product Backlog med kun en Product Owner til alle teams. Team medlemmer fra alle teams deltager i klargøring af backlog emner (refinement). Alle teams leverer et samlet og integreret klar-til-kunden produktudvidelse (shipable product increment), der fremvises til den fælles Nexus Sprint Review. For løbende af inspicere og forbedre, holder teamet dagligt møde (Daily Standup) efter at Nexus’en har holdt et dagligt møde (Nexus Daily Standup) og dertil inspektionsmøder (Retrospective) efter hvert sprint på både team- og Nexus-niveau.

Nexus rammeværket til at skalere agil.
Gengivet fra Scrum.org med accept. Materialet kan findes her (engelsk)
https://www.scrum.org/resources/online-nexus-guide. Copyright Scrum.org.

Nexus kan anvendes for 2 niveauer (team + grupper af teams), mens Nexus+ kan anvendes for 3 niveauer, ved at kombinere flere parallelle Nexus-er.

Den struktur der anvendes til at skalere agil i et rammeværk er designet til at optimere for en udvalgt parameter. I dette tilfælde er Nexus designet til at optimere for realiseret værdi. Med andre ord er formålet med at anvende Nexus til at skalere agil, at maksimere den realiserede værdi via den klar-til-kunden produktudvidelse der er resultatet af iterationen.

Scrum@Scale

Scrum@Scale  blev udviklet af Jeff Sutherland (medskaber af Scrum). Scrum@Scale rammeværket har været til rådighed siden 2018.

Scrum@Scale er en videreudvikling af  Scrum, og er skabt ved at gentage de mekanismerne i Scrum for flere teams og på flere niveauer i organisationen. Med andre ord er Scrum@Scale baseret på at, de mekanismer der virker for et team, kan virke for en gruppe af teams og hele vejen op til C-level i en organisation.

Kort fortalt virker rammeværket ved at have op til 5 teams i en gruppe (team of teams). Hvert team har deres egen Product Owner og Product Backlog, hvor opgaver flyder fra Product Backloggen for team-of-teams (niveau 2) til teamets Product Backloggen (niveau 1). Team  medlemmer deltager i klargøring af opgaver (refinement) på team niveau.

På hvert niveau er der mindst en Product Owner med sin Product Backlog. Konkret er der en Product Owner (PO) for hvert team (niveau 1), en Chief Product Owner (CPO) for hvert team-of-teams (niveau 2), en Chief Chief Product Owner (CCPO) for hvert Team-of-Team-of-team (Level 3) etc.  Og dertil er der for hver Product Owner (PO, CPO, CCPO etc) en Product Backlog.

Alle Product Ownere arbejder i Product Owner cirklen fra strategisk vision (fra højeste niveau) til prioriteret Product Backlog på alle niveauer klar til teamets sprint planlægning (Sprint Planning). Derved sikres til enhver tid, konsistens fra visionen til hvert teams prioriterede backlog.

Alle teams leverer et integreret klar-til-kunden produktudvidelse, der demonstreres til teamets Sprint Review ved iterationens afslutning. For løbende af inspicere og forbedre, holder teamet dagligt møde (Daily Standup) efterfulgt af  Scrum-of-Scrums (niveau 2), Scrum-of-Scrum-of-Scrum (niveau 3) og gennem alle niveauer op til øverste niveau. Som eksempel vil en organisation med 3.750 personer afholde 4 standup møde á 15 minutter (60 minutter ialt) for at eskalere problemer fra team til øverste niveau.  

Ydermere afholdes inspektionsmøder (Retrospective) efter hvert sprint på team-niveau.


Gengivet fra Scrumatscale.com med accept. Materialet kan findes her (engelsk)  https://www.scrumatscale.com. Copyright Scrum Inc, Scruminc.com

Scrum@Scale virker i princippet for et vilkårligt antal niveauer fra 2 og opefter.

Den struktur der anvendes til at skalere agil i et rammeværk er designet til at optimere for en udvalgt parameter. I dette tilfælde er Scrum@Scale designet til at optimere for realiseret værdi. Med andre ord er formålet med at anvende Scrum@Scale til at skalere agil, at maksimere den realiserede værdi via den klar-til-kunden produktudvidelse der er resultatet af iterationen.

LeSS (Large Scale Scrum)

LeSS (Large Scale Scrum) blev udvikle t af Craig Larman og Bas Wodde og rammeværket er offentliggjort i 2014. LeSS er en videreudvikling af de strukturer der virker for teams i Scrum, kombineret med organisations design, systemisk design og principper fra Lean.

Udgangspunktet for LeSS er at reducere organisationens kompleksitet (de-skalere organisationen), forud for at organisationen skaleres. Derved reduceres mængden af kompleksitet, interne bindinger og afhængigheder, som derved ydermere bidrager til at den skalerede agile organisation bliver mindre kompleks.  

LeSS er centreret omkring en Product Owner der har det fulde ansvar. Fra ide til klar-til-kunden produkt, arbejder Product Owner og teamet på ideen, mens relevante stakeholdere kaster lys over relevante detaljer.  Helt konkret betyder det at teamet er langt mere involveret i klargøringsprocessen (refinement) fra første ide til at opgaven er klar til at trække ind i sprintet.  

Alle teams leverer et samlet integreret klar-til-kunden produkt, som bliver demonstreret på det fælles Sprint Review, der afslutter sprintet.

For løbende af inspicere og forbedre, holder teamet dagligt møde (Daily Standup) og teams koordinerer med andre teams løbende og efter behov.  Dertil afholdes inspektionsmøder (Retrospective) efter hvert sprint for både team (Niveau 1) og team-of-team (niveau 2).


Gengivet fra LeSS.works med accept. Materialet kan findes her (engelsk) https://less.works/. Copyright LeSS.works

LeSS er opbygget omkring de to niveauer team og gruppe af teams, mens LeSS Huge kan anvendes til at indeholde tre niveauer (Niveau 1 – 3), der fortsat er underlagt en fuldt ansvarlig Product Owner med en samlet Product Backlog.

Den struktur der anvendes til at skalere agil i et rammeværk, er designet til at optimere for en udvalgt parameter. Det skalerede agile rammeværk LeSS, er mere fleksibelt, da organisationen reorganiseres, designes og LeSS derfor kan optimere efter den ønskede parameter, fx realiseret værdi, beskæftigelse til alle (business), fortrolighed (secrecy) eller anden relevant parameter.  

SAFe (Scaled Agile Framework)

SAFe Scaled Agile Framework, blev udviklet af Dean Leffingwell og var det første offentligt tilgængelige rammeværk til at skalere agil, da det blev offentliggjort i 2011. Den nuværende version 5.0 er frigivet i 2020. SAFe kombinerer Lean og agile principper i et sæt lean-agile principper der er en del af fundamentet. SAFe er det eneste af rammeværkerne der implementerer det at skalere agil på både team niveau (Niveau 1) og gruppe af teams niveau (Niveau 2) parallelt.

SAFe starter med organisationens porteføljelag og Lean Portfolio Management, hvor målet er at have en trimmet organisation (lean enterprise) med klare beskrivelser af roller og ansvar. SAFe er ikke direkte linket til Scrum eller Kanban, da alle teams selv frit kan vælge arbejdsmetode, så længe de er kompatible med faste kadence der er fælles for gruppen af teams. Kadencen er oftest fastsat som 2-ugers sprints, sammensat i en længere planlægningshorisont (PI) på fem 2-ugers sprints. Der planlægges i SAFe både for sprint (sprint planning) og laves klar forventningsdannelser for PI’en (PI Planning).

Full SAFe overblik.

Gengivet fra Scaledagileframework.com med accept. Materialet kan findes her (engelsk)
https://www.scaledagileframework.com. Copyright Scaledagile Inc

Overbliksbilledet for SAFe findes ikke kun som en, men i hele fire versioner, afhængig af størrelsen af organisationen. Ovenfor er vist den samlede version Full SAFe, der de dækker 4 niveauer (Niveau 1-4). Dertil findes versionen Essential SAFe for 2 niveauer (Niveau 1-2) og to versioner for tre niveauer (Niveau 1-3) Portfolio SAFe og Large Solution SAFe.

Den struktur der anvendes til at skalere agil i et rammeværk, er designet til at optimere for en udvalgt parameter. I dette tilfælde er SAFe designet til at optimere for Outcome. Med andre ord er formålet med at anvende SAFe til at skalere agil, at maksimere outcome via den klar-til-kunden produktudvidelse der er resultatet af iterationen.

Andre rammeværk

Udover de allerede nævnte rammeværk til at skalere agil, er der et antal organisationer der har ladet sig inspirere af den struktur der tidligere blev anvendt hos Spotify. Strukturen er ikke beskrevet i samme detaljeringsgrad som de ovenstående rammeværker, ligesom de personer der har bidraget til opbygningen af dem ikke anser dem for at være rammeværk. Deres måde at arbejde med skaleret agile r beskrevet i videoer fx denne og denne på YouTube.

De hybrider af andre skalerede agile rammeværk vi ser, kombinerer ofte en struktur for team niveauet med en eller flere strukturer på porteføljeniveauet. Der er ikke en klar opskrift for hybriderne, men flere af dem lader sig inspirere af Lean Portfolio Mangement.

Men hvilken måde til at skalere agil skal vi så vælge

Det er netop 100.000kr spørgsmålet vi ofte hører, når vi taler om at skalere agil. Men før vi kommer frem til at kunne besvare det, skal vi først identificere jeres mål med at skalere agil. Hvad er det I gerne vil opnå?

Når jeres mål er kendt, er I klar til at undersøge om 1) Skal/kan I de-skalere organisationen og opnå målet? 2) Skal/kan I starte med at indføre agile arbejdsgange på team niveau (Niveau 1) og opnå/komme nærmere målet? Sidst men ikke mindst, 3) Kan skaleret agil hjælpe jer med at opnå/komme nærmere målet?

På trods af de forholdsvist enkle spørgsmål, bør disse trin ikke udelades. På samme måde som I ikke ville springe over et trin i en modenhedsmodel.

Nu til svaret om hvilket skaleret agilt rammeværk I bør vælge. Og svaret er at det kommer an på jeres kontekst. Der findes desværre hverken universelt korrekte eller universelt forkerte rammeværk. Det rammeværk der er ”bedst” for jer, vil være det rammeværk der bedst bringer jer tættest på målet. Og målene er ikke ens på tværs af organisationer, landegrænser, brancher eller forretningsmodeller.  

Anbefalinger

VILMA Consulting anbefaler at før I starter på en agile transformation, at afdække hvorfor I vil være en skaleret agil organisation. Hvad specifikt ønsker I at opnå (målet) ved at være en skaleret agil organisation, samt hvorvidt I kan de-skalere organisationen for at opnå målet.

Som det næste skridt, anbefaler vi at sammenligne 3-4 forskellige skalerede agile rammeværk, hvor I inddrager både risiko, omkostningsaspektet og dette menneskelige aspekt ved at gå igennem en transformation. Sammenligningen kan opstilles som en business case for hvert skaleret agilt rammeværk, hvorved sammenligning på tværs af rammeværk bliver understøttet.  

Når I derefter er klar til at begynde den skalerede agile rejse, selve transformationen, er I samtidig blevet bedre klædt på til at lave den første backlog, transitions-backloggen. Denne prioriteres efter evnen til at bringe jer tættere på jeres mål.

Vi er i VILMA Consulting klar til at hjælpe jer med alle disse skridt. Og samtidig ønsker vi jer:

Held og lykke med at starte – eller fortsætte, jeres agile transformation!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting 

PS: Hvis I har startet jeres skalerede agile transformation for et stykke tid siden, er der stadig god inspiration at hente fra de øvrige skalere agile rammeværk. Det kan fx være hvis I er interesseret i Continuous Learning…

Governance for agile og vandfaldsprojekter – Fordele og Ulemper

Governance for agile og vandfaldsprojekter – Fordele og Ulemper

Projekter startes og afsluttes hver dag, både af de rigtige og de knap så attraktive årsager. Governance (styring af og overblik over) projekter og porteføljer er fokuseret på at træffe de rette beslutninger, på det rette tidspunkt. Og derfor er governance både relevant og vigtigt, uanset om du anvender agile metoder eller vandfaldsmodellen.

Men lad os starte med konklusionen, så du ved hvad du kan forvente længere nede:

  • Kan du udføre governance på agile projekter? Ja!
  • Kan du udføre governance i sammen grad som hvis det var vandfaldsprojekter? Ja!
  • Gennemføres governance på præcis samme måde? Nej!

Både Agile og Vandfaldsmetoden kan kombineres med Governance.
Agile eller Vandfaldsmetoden er dit valg. Hvordan governance udføres afhænger af dette valg; med hænger naturligt sammen med begge.

Men hvad handler governance egentligt om

Når jeg sender penge efter et projekt, er jeg ivrig efter at se værdien af det. Jo længere det tager før jeg kan se værdien, jo mere desperat bliver jeg efter at få vished om at fremdriften er bedst mulig.

Governance for projekter handler om netop det; at få vished for at investerede penge skaber værdi. Tilstrækkelig værdi, hurtig værdi og højere værdi end af alternative investeringer (har den højeste marginalafkast – ROI, Return-On-Investment – i økonomiske termer). Og hvis flere projekter gennemføres parallelt, hvilket er det typiske scenarie når vi snakker projekt governance; sikre at knappe ressourcer er udnyttet tilstrækkeligt/ optimalt.

For at kunne sammenligne projekt governance, må vi først opstille hvordan vi ideelt ønsker at følge op på og sammenligne projekter, uanset hvilken metode vi anvender for projekterne. Såfremt vi vurderer agile projekter på sammen måde som vi vurderer vandfaldsprojekter, ville vi hverken yde retfærdighed til vandfalds-governance eller governance for agile metoder.

 

Hvordan evaluerer vi fremdrift

Den ideelle situation for projekt og portfolio governance, er at have et fremdrift-o-meter, der konsistent og kontinuert måler fremdriften for et vilkårligt projekt eller initiativ, og fejlfrit sammenligner data på tværs af projektportefølgen. Fakta er dog at vi endnu kun har en prototype for dette, der dog har været rimelig stabil længe – men stadig med god plads til forbedringer.

I den perfekte metode til at gennemføre et projekt (uanset om denne er formuleret, eller ej), ville vi formentlig evaluere et projekt på disse nøglefaktorer:

  • Reel fremdrift + forventningsafstemme i forhold til tid
  • Reelle omkostninger + forventningsafstemme i forhold til omkostninger
  • Risici, forhindringer og hvad der gøres for at afhjælpe disse
  • Om løsningen matcher behovet/ kunden og/eller markedet (fitness for use/ customer/ market)

Dertil kommer at vi formentlig ville evaluere porteføljen af projekter på disse nøglefaktorer:

  • Arbejder vi på de rette projekter/ initiativer?
  • Arbejder vi på de rette projekter/ initiativer, med den rette intensitet?
  • Hvor hurtigt kan vi ændre kurs (levere noget andet) – fra ny ide til produktet/ produktudvidelsen rammer kunden/ markedet?
  • Hvordan er behovet for ressourcer?

 

Hvordan ser det ud når vi sammenligner governance for agile og vandfaldsprojekter  

I virkeligheden ville vi formentlig sammenligne projekter på mere end 4 faktorer, uanset hvor tillokkende det måtte synes med bare fire. Endvidere kan man forestille sig at faktorerne varierer fra branche til branche, og dertil med størrelser af projekter, og om projekter indeholder lovgivnings- og/eller sikkerhedskrav. Dog vil de overfor nævnte faktorer formentlig være relevante for de fleste projekter på tværs af branche og projekttype.

Lad os se nærmere på hvordan agile og vandfaldsprojekter leverer på de fire governance faktorer, beskrevet ovenfor.

 

Hvordan vurderes governance indikatorerne for vandfaldsprojekter

Fremdrift rapporteres hyppigt af projektlederen, og alle projekters rapporteres på samme måde på tværs af projekter. Den reelle fremdrift er rapporteret som en proxy, hvilket er det nuværende bedste bud, omend det er subjektivt. Værdien ligger mellem 0-100%.

De reelle omkostninger er angivet ret nøjagtigt som summen af løn og andre direkte omkostninger. Dertil kommer at vandfaldsprojekter typisk er ret effektive til at håndtere risici; registrering, planlægge imødekommelse af risici, samt holde styr på den enkeltes status.

Hvorvidt løsningen matcher behovet hos kunde/ markedet, er svært at vurdere før produktet rammer bruger og/eller markedet. I vandfaldsprojekter kan både preto- og prototyper testes på udvalgte brugere/ kunder, for at få en proxy for om produktet reelt er en løsning.

Vandfaldsmetoden

Er en sekventiel model, hvor hver fase er afsluttet og godkendt, før næste fase kan starte. Faserne er Analyse, Design, Implementering, Test og Idriftsættelse. Alle krav beskrives og godkendes før design påbegyndes osv.

Et afleveringsklart produkt fremkommer når alle faser er afsluttet.

 

Hvordan vurderes governance indikatorerne for agile projekter

I agile projekter evalueres indikatorerne anderledes. Den reelle fremdrift er summen af afleverede og implementerede produktudvidelser  og der medregnes ikke igangværende arbejder. Product Owner’en er central i denne opgørelse, da han/hun er ansvarlig for godkendelsen.

De reelle omkostninger opgøres på samme måde som for vandfaldsprojekter, som summen af løn og andre direkte omkostninger.

I agile projekter, håndteres risici og forhindringer efterhånden som de opstår; og hvis ikke muligt, eskaleres de. Udbedringen oprettes i backloggen, hvis den ikke straks udføres. En dedikeret risici-log udarbejdes kun såfremt dette er nødvendigt, eftersom fokus er på at reducere/fjerne risici fremfor registrering.

Ved afslutning af hver sprint, leveres en afleveringsklar produktudvidelse. Denne er færdigtestet og kan idriftsættes til slutbruger, således at man kan opnå feedback fra slut-brugerne. Denne feedback vil have direkte indvirkning på produktets videre udvikling. Om løsningen matcher behovet bliver dermed løbende evalueret.

Agile metoder

En gruppe af metoder der lever op til det agile manifest. Indenfor agile metoder, foretages alt fra analyse til udvikling og idriftsættelse indenfor sprints. Hvert sprint tager 1-4 uger og derefter haves et potentielt leveringsklart produkt(-udvidelse).

Krav tilføjes og prioriteres løbende, hvorved teamet løbende arbejder på det vigtigste område der endnu ikke er afsluttet.

Fremskrivninger af hvad der kan leveres, og hvornår, opnås ved at bruge den faktiske leveringshastighed samt estimater for de højest prioriterede krav.

 

Sammenligning af governance for agile og vandfaldsprojekter

I figuren herunder er vist nøjagtigheden hvorpå der svares på de fire governance faktorer, hvor grøn er (tæt på) fuld nøjagtighed, gul er medium, mens rød er lav nøjagtighed.

 

Agile og Vandfalds governance.
Sammenligning af Agile og Vandfalds Governance.

Projekt governance er mere end bare fire indikatorer, men for overskuelighedens skyld er de blevet udvalgt. På tilsvarende vis kan portefølje governance sammenlignes for agile og vandfaldsprojekter.

 

Opsummering

Governance er lige så relevant for agile som for vandfaldsprojekter. Selvom vi evaluerer dem forskelligt, søger både agile og vandfaldsprojekter svar på de samme underliggende spørgsmål. Dog kan de underliggende spørgsmål være gået i glemmebogen, mens vi længe har evalueret projekter på en bestemt måde.

Som et lille tip kan du overveje hvorfor du skal rapportere på netop denne metrik (måleparameter), når du bliver bedt om at rapportere på en. Hvis svaret ikke er oplagt, eller ikke er årsags-roden, er der en god chance for du skal rapportere på en proxy. Hvis du skal rapportere på en vandfalds-proxy for et agilt projekt, kan du ende med at rapportere på en proxy-proxy.

Overgangen fra governance for vandfaldsprojekter til governance for agile projekter er bedst faciliteret, hvis du har stærk indsigt i hvordan de værdiskabende aktiviteter hænger sammen. Alternativt kan i overveje få hjælp af en agile specialist til netop det, for at få maximalt udbytte og en smidig overgang.

 

 

Held og lykke med din agile governance!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer Owner af VILMA Consulting

 

PS: Hvis du kigger nærmere på jeres KPI struktur, er der gode chancer for du finder tilsvarende approksimationer, der slørede for opmærksomheden på det oprindelige spørgsmål.

 

 

 

Hvad er Forskellen på Agile Kontrakter og Traditionelle Kontrakter

Hvad er Forskellen på Agile Kontrakter og Traditionelle Kontrakter

Understøttes agile projekter bedst af agile kontrakter? På hvilken måde adskiller de agile kontrakter sig fra traditionelle kontrakter? Og gør det egentlig en forskel hvad man bruger?

Læs videre og få belyst forskelle og implikationer af at anvende agile kontrakter til agile projekter. Og her kan du få en kort introduktion til hvad agile projekter er.

Hvorfor skal vi bruge agile kontrakter

I den komplekse verden vi operer i, løses opgaver ofte af højtkvalificerede leverandører – det er både hensigtsmæssigt i forhold til kompetencer og omkostningseffektivt. I større virksomheder medfører det ofte et behov for indkøbsadministration og sammenligning af leverandører hvor (som minimum) forventet pris og leveringsdato typisk bruges som kvantificerbare sammenligningsparametre. Samtidig ses at ændring af løsningen uden merpris, mulighed for undervejs at stoppe arbejdet når 60-80% af værdien er leveret og ”kun” skulle betale for faktiske omkostninger, kun sjældent medtages om end det også kraftigt kan påvirke den faktiske pris.
Men det er muligt med agile kontrakter.

Hvad betyder det om der bruges agile kontrakter eller traditionelle kontrakter

Selve udførslen af arbejdet er fundamentalt forskelligt om det udføres agilt eller traditionelt (også kendt som vandfaldsmetoden). Ved et traditionelt udført arbejde aftales opgaven og præmisserne derfor på forhånd med brug af projektledertrekanten; scope, price og quality.
Ved et agilt projekt arbejdes mod et mål, og hvad der skal gøres for at nå målet, aftales løbende. I praksis betyder det at kvalitetsnormen er aftalt på forhånd og løbende verificeres, mens der løbende bygges på scope så der matcher kundens behov. Prisen er løbende omkostninger, typisk indenfor et aftalt bånd, eksempelvis aftales at der leveres et antal fuldtids udviklingsteam bestående af et fast antal personer, hvorved måneds- og årspriser er kendte.

Traditionelle kontrakter

I traditionelle kontrakter er aftalegrundlaget HVAD der skal laves, HVORNÅR det skal være færdigt, og PRIS for det afsluttede arbejde. Alt dette er meget rart som rekvirent af opgaven, men måske skal man være opmærksomme på hvor stort et incitament man giver sin leverandør til at finde eventuelle upræcisheder og mindre manglende elementer – for slet ikke at tale om større huller. Hver gang en leverandør finder en upræcis beskrivelse, er ”findelønnen” at der kan sendes en ekstraregning. Eller hvis man som bestiller ”bliver klogere” i processen, og måske endda skifter mening, så resulterer det i en ekstraregning og ofte også en forsinkelse.
Fordelen er klart at man fra start har et godt bud på pris og afslutningsdato, samt hvad der er med i ”pakken”.
Ulempen er at pris, leveringsdato og indhold typisk afviger fra det forventede, samt at der undervejs er brugt mange ressourcer på justeringer og forholde sig til ekstraregninger.

Hvad er agile kontrakter

Med agile kontrakter er meget vendt på hovedet. Der er ikke en ”rigtig” måde at lave agile kontrakter på, men fællestrækkene er at de tager udgangspunkt i flowet i agile produktudvikling, den agile model og dertil continuous deployment og continuous improvement.
Kort fortalt arbejdes der i den agile model ikke med et veldefineret endepunkt (design for hvordan skal opgaven løses), men i stedet med hvad skal der til, for at opgaven er løst (acceptkriterier for hvad en løsning som minimum skal kunne). Forskellen ligger i høj grad i om løsningen er designet inden opgaven startes, eller designes løbende når der arbejdes med specifikke dele af den samlede løsning. Uden at gå i tekniske detaljer, så skal der designes løsning for færre løsningsområder, laves mindre om i design og løsninger designes på et væsentligt højere vidensniveau, herunder at der automatisk tages højde for de dele af løsningen som allerede er bygget.

Hvad indeholder agile kontrakter

Arbejder du ud fra agile kontrakter, leveres løbende det der for kunden er vigtigst i en fast kadence, eksempelvis release hver 2. eller 4. uge. Derved oplever kunden løbende at få værdi tilført og ikke kun ved projektets afslutning. Varigheden af agile kontrakter vil ofte være fleksibel, fx min. XX måneder med option på forlængelse.
Ydelsen som kunden køber, er et antal udviklingsteams med en fast besætning, således at kvaliteten på forhånd kan valideres og sammenlignes mellem mulige leverandører. Kunden modtager og accepterer løbende kvalitet og indholdet fra leverandøren og kan derfor løbende få værdi ud af sin investering.
Selvfølgelig er der et klart element af tillid i kontrakten, men det kommer oven på det element af tillid du under alle omstændigheder skal udvise til en leverandør der skal levere et forretningskritisk system til dig.
Eftersom det løbende fastlægges hvad der skal leveres, har du som kunde løbende fingeren på pulsen i forhold til hvad der bliver arbejdet på. Dertil skal kunden løbende acceptere det leverede og der kan derfor ikke ophobe sig overraskelser. Kunden har naturligvis altid mulighed for at omprioritere eller skifte kurs, uanset om kursskiftet er foranlediget af eget strategisk skifte, markedsomstændigheder eller andet.
Aftalegrundlaget er HVEM der udfører arbejdet, HVORNÅR der releases (fast kadence), og PRIS per time og materiale (klassisk T&M).

Fordelen er klart at man løbende får leveret systemet og kan taget dele i brug tidligere. Kunden kan altid og uden ekstraomkostninger skifte kurs. Forløbet kan afsluttes når kunden ønsker, og typisk når marginalværdien er højere på et andet ventende projekt. Projektet kan startes tidligere, da alle krav ikke skal defineres og afstemmes først.
Fremdriftsrapportering handler nu om hvad der faktisk er leveret (working product increments), fremfor vurderinger af hvad der udestår.
Ulempen ligger i opstarten af første agile kontrakt, hvor det er et andet klargøringsarbejde der skal udføres, kunden skal løbende prioritere og præsentere krav og opfølgning virker i starten meget anderledes for nogen.

Hvordan kan tillid til den agile leverandør skabes

Udover de klassiske greb med referencer og økonomiske nøgletal er der andre elementer i vurderingen af en agil leverandør.

  • Evnen til at samarbejde som et agilt team – både internt på teamet, men mindst lige så vigtigt, samarbejdet med kunden
  • Udviklingshastigheden fx Lead time – perioden fra krav/ ønsker er opstået til løsningen er i produktion
  • Antallet af fejl der ses i produktionssystemet, set i forhold til den leverede mængde løsninger

Kender du leverandøren fra tidligere, er det ofte en stor fordel, da du allerede ved hvilken kvalitetsnorm de arbejder efter.
Er der tale om en ny mulig leverandør, er en mulighed at teste dem i den konkrete setup. Eksempelvis kan leverandørerne inviteres til at deltage i en agile prøveperiode hvor de dels skal levere en løsning på en konkret opgave, fra deres eget udviklingsmiljø til jeres produktionsmiljø; og dels vurderes de på evnen til at samarbejde internt hos leverandøren og samarbejde med jer.
I praksis bruges 1-2 dage ved et agilt setup og 4-5 dage ved et skaleret agilt setup. Denne investering af ressourcer træder i stedet for et ofte omfangsrigt udbudsmateriale med hundredvis af krav til løsningen.

Hvad er fordelene ved agile kontrakter

Mens arbejdet udføres efter agile kontrakter, vil i høste fordele som

  • Tydelig involvering som kunde. Kunden prioriterer løbende hvad der er vigtigst
  • Løbende værditilvækst fra løbende idriftsættelser.
  • Det vigtigste leveres først, hvorved projektrisiko om overordnede succeskriterier hurtigt minimeres
  • Værdiskabende samarbejde, hvor alle parter arbejder på den løsning der er bedst mulig for jer som kunde, og uden skjulte dagsordener om mulige ekstraregninger
  • Fravær af change requests, både administrativt og selve ekstraregningerne
  • Mulighed for at afslutte kontrakten når opgaven er (tilstrækkelig) løst – også hvis det er markant tidligere end forventet.
  • Vælger du at teste nye leverandører og evt. stille krav om fast team, kender du de udførende parter lidt bedre inden selve projektet starter.

 

Hvem er agile kontrakter relevant for

Agile kontrakter er relevant for alle der sender ikke-standardiserede opgaver i udbud eller direkte til en leverandør. Det er både virksomheder og offentlige institutioner og fælles for dem er at de ønsker mest mulig kvalitet for pengene, leveret tidligere, med lavere projektrisiko mens der stadig skal være rig muligt at navigere i en forandrende markedssituation.
Det er eksempler på både større virksomheder og offentlige myndigheder der udbyder agile kontrakter, og området er i vækst. På det offentlige område har der i kølvandet på større kuldsejlede projekter været stillet krav om radikalt anderledes styring af projekterne.

 

Held og lykke med at komme i gang med agile kontrakter

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

Om at Estimere – og Hvordan du Kommer til at Elske Det igennem den Værdi det Giver Dig

Om at Estimere – og Hvordan du Kommer til at Elske Det igennem den Værdi det Giver Dig

Estimering er noget rigtig mange prøver at komme nemt om; som i helst slet ikke gøre. Eller få andre til at gøre for sig. Men hvorfor? At estimere ER et effektivt redskab når det kommer til at skaffe overblik og indsigt, hvis det bliver gjort smart. Og ja, der er selvfølgelig mere end en måde – nogle kan så være smartere i præcis din kontekst.

Hvordan estimerer du?

Hvis du arbejder indenfor IT og har gjort det i mere end 5 år, er du formentlig enten en af dem der selv arbejder med at estimere (på andres foranledning), eller gør hvad du kan for at skubbe det med at estimere over på en andens bord. Sidste mulighed er at du tilhører den heldigvis voksende gruppe der har set styrken i at estimere relativt – og specielt, den værdi det bringer med sig.

Hvorfor skal lige netop JEG estimere

Det er der mange gode grunde til.

  • Der er nogen der har bedt dig om det. Og de kender dem der udbetaler din løn, så det er nok i bund og grund en god idé
  • Det kan være du er chef for nogen, og beder om estimater fra andre så du kan skabe overblikket. Der sker typisk det at du alligevel skal estimere ”det der ikke kom estimater for”, uanset hvad grunden til det måtte være.
  • Du er en del af et agile team og udfører hyppigt relativ estimering på ganske kort tid, og anvender disse estimater til at prognosticere dette og kommende sprint udfald.
  • Du er en del af et agile team, og estimerer overhovedet ikke! På trods at dette er du stadig i stand til at forudsige dette om kommende sprints udfald.

Hvad skal estimater bruges til

Helt generelt bruges estimater til at forudsige noget på kortere eller længere sigt. Men helt ærligt, hvornår har du sidst set en langsigtet prognose der rent faktisk ramte bulls eye? Det sker, bevares. Men mener du frekvensen af det matcher omkostningen af at estimere og alle de opdateringer af dem, der typisk også bruges ressourcer på? Også hvis du indregner alle ”forbi’erne”.

Hvordan kan vi gøre det anderledes

Når vi arbejder på den agile måde, bruger vi det at estimere ofte men med er ret lille tidsforbrug. En sprint planlægnings session for et 2-ugers sprint tager omkring to timer, og end ikke al den tid er brugt på at estimere. Typisk er der 6-12 elementer der skal estimeres, og hver estimering tager fra 2-5 minutter. Ikke mere, men faktisk ofte mindre. Men bliver det præcist? Nej, egentlig ikke. Men det er ikke et problem, da det kommer til at passe i gennemsnit (og er du virkelig nysgerrig på det, så er der noget tung matematik der kan bevise det).

Forskellen ligger i at bruge relativ estimering i stedet for absolut estimering, samt at angive værdien i en tidløs enhed, som fx Story Points, eller hvad du har lyst til at kalde det. Estimaterne er specifikke for det team der har udført dem, og kan bruges til dette teams fremskrivninger som fx hvor meget de kan levere af produktionsklart software på en sprint, når det bruges i kombination med den realiserede velocity (teamets hastighed i story points).

Hvad er fordelene ved relativ estimering

Det er simpelt, hurtigt, omkostningseffektivt (hvad mere kan du ønske) og løser opgaven med at forudsige rimelig godt. Desuden aktiverer det hele teamet med at estimere, og leder derfor til mere velunderbyggede estimater. Sidst men ikke mindst, så kobles det at estimere med kvalificerende og opklarende spørgsmål, således at mere detaljeret information overføres fra rekvirent til teamet. I praksis er det information der ikke blev skubbet fra rekvirenten men i stedet trukket af teamet.

Men lige inden du sender hele dit estimeringsteam på porten, så er de stadig klart at foretrække hvis du byder på en opgave!

Er der så nogen faldgruber ved at estimere relativt

’There ain’t no such thing as a free lunch’. [Ukendt]

Så ja, der er mere du skal vide. Men det er mindre og ganske rimelige ting, hvorefter du effektivt kan begynde at estimere relativt til fremskrivninger.

  • Det team der skal levere arbejdet, skal udføre estimaterne. Dels fordi estimater ikke kan overføres fra team til team. Men vigtigere er at teamet for væsentlig information mens de estimerer.
  • Det er teamet – og ideelt alle på teamet – der estimerer. Der er ingen chefer (eller kløgtige sælgere) der skal påvirke estimaterne. Og egentligt ganske fair, da det er teamet der skal comitte til at levere arbejdet og dermed den ønskede produktionsklare løsning.
  • Adgang till information forud for, og mens teamet skal estimere, direkte fra kilden dvs. rekvirenten er helt centralt. Teamet skal hurtigt vurdere en opgave i forhold til andre, for at afslutte estimatet.
  • Respektfuldt samarbejde mens der estimeres. Uanset hvad der kommer op mens der estimeres, er bragt op af en grund. Og her er det både elementer der øger estimatet og kendte genveje der sænker estimaterne der er relevante.
  • Det at estimere relativt kan bruges operationelt, i visse sammenhænge også taktisk men taber pusten før vi kommer til det strategiske niveau. Eller rettere, det kræver væsentlig mere erfaring at få succes med det på dette niveau.

Hvordan kommer jeg i gang

Det er nemt! Metoden kan forklares på 2 minutter, og et team kan have lært det på en time. Så det er desværre ikke her du kan finde begrundelsen for at du ikke kan/vil begive dig ud i at estimere relativt. Og som altid, søg efter videoer på nettet eller inddrag en agile specialist for at komme nemt og sikkert I gang.

Så alt taget i betragtning, så synes jeg det er et effektivt redskab som jeg gerne anbefaler. Lave omkostninger ved implementering, lave operationelle omkostninger, og rimelig kraftig prediktiv styrke også sammenlignet med traditionel estimering.

 

Held og lykke med at komme i gang med relativ estimering!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

PS: Ikke at estimere (Not to estimate, no-estimate) svarer i denne sammenhæng alligevel til at estimere. Men på den indirekte måde hvor alle opgaver i stedet skal være nogenlunde lige store, hvorefter det er tilstrækkeligt at tælle antallet af opgaver, for at kunne fremskrive. Dog kræver det et ret modent team at kunne få succes med i praksis.

 

6 trins guide til at starte med agile metoder, for dig er der ”ny” i forhold til agile metoder

6 trins guide til at starte med agile metoder, for dig er der ”ny” i forhold til agile metoder

At starte med agile metoder er samtidig at starte en transformation. At starte med agile er at gå ombord på en rejse der vil føre dig nye steder hen, og på et tidspunkt lede dig til svaret på hvorfor du skal starte med agile metoder.

Men lad os først, hvis du er helt ny i forhold til agile metoder, ridse op hvad de går ud på, før jeg kommer til hvordan du kommer i gang. Der er groft sagt to måder at gennemføre projekter på; der er sekventielle og iterative metoder, som også er kendt som agile metoder.

Den sekventielle metode vil gennemføre og afslutte en fase før den næste påbegyndes, og tilsvarende kan fase tre begyndes, når fase to er gennemført og afsluttet. Ofte skal der endvidere besluttes om næste fase påbegyndes, for at starte en ny fase. Meget kendt er vandfaldsmodellen der typisk indeholder faser á la Analyse/ specifikation – Design – Udvikling – Integration – Test – Idriftsættelse/ drift.

Iterative metoder – eller agile metoder vil på den anden side, groft sagt arbejde parallelt med små bidder af projektet i alle projektets faser, og vurdere hver enkel bid løbende når den er færdig. I praksis betyder det, at vi kun beslutter os for mindre dele af krav til funktionalitet, da vi konstant og løbende vurderer hvad der er den næste vigtigste ting af levere, efterhånden som vi ser løsningen blive sat sammen som et puslespil. De korte afklarings- og udviklingsperioder kan være så korte som 1-2 uger, og stadig levere meningsfulde tilføjelser til projektet. De mest kendte af de agile metoder på teamniveau, er Scrum, Kanban og hybrider med disse. Da agile ligeledes anvendes på team niveau, findes der også skalerede agile metoder (program lignende, og større), hvor de mest kendte er rammeværkerne SAFe og LeSS.

Fælles for agile metoder er at den bedste måde at bruge dem på, er ganske anderledes end hvad der er optimalt i vandfaldsprojekter.

Så hvordan finder jeg ud af hvor jeg skal starte med agile?

Den gode nyhed er at alene ved at stille spørgsmålet, er du allerede i gang! Ved at stille spørgsmålet er du allerede på vej til at erkende, at det kan være relevant at starte denne forandring anderledes. At spørge betyder nemlig også at invitere hjælp og viden indenfor.

”Hvis du ønsker noget som du aldrig har haft, må du gøre noget du aldrig har gjort”

Thomas Jefferson

1. Alliér dig med viden og konkret erfaring

Hvis du vil ind på et nyt marked, en ny teknologi eller et nyt kundesegment formoder jeg at du vil tilføre viden og sikkert en god portion konkret erfaring først. Og dernæst lade denne viden (og knap så meget teori) guide dig videre. Brug samme koncept her for at komme i gang, og drag nytte af agile specialister og agile erfaringer i dit netværk. Allerede her kan så sagtens være første gang du oplever at den agile rejse er svær, på flere måde end du troede.

At finde den rette vej at tilføre agile viden der relaterer sig til din forretning og dit domæne og din tidsplan – muligvis uden at besidde redskaberne til selv at vurdere agile kvalifikationer, kan være udfordrende. Men du er ikke den første med udfordringen.

2. Start simpelt, lær løbende og voks med opgaven

Hvis du planlægger at rulle agile metoder ud på hele virksomheden på en gang, gætter jeg på din plan er at planlægge det omhyggeligt, og så starte? Præcis ligesom du sædvanligvis kører projekter og programmer i vandfalds-komfortzonen.

Den oplagte pilottest på at være agile, er at planlægge at være agile, på den agile måde. Start helt simpelt og kortsigtet. Prøv det, opbyg noget erfaring, og bred det så mere ud som ringe i vandet.

Du vil lave fejl, og der vil være masser af overraskelser. Men tager du imod med åbent sind, vil du komme styrket igennem det.

3. Giv mandatet til de rette personer. Og hav tillid til dem

At være agile som virksomhed eller organisation, handler i høj grad om at forventningsafstemme. Oppefra-ned, og nedefra-op; og begge veje hele tiden. Oppefra-ned angives forventninger til hvad der er mest vigtigt, som imødekommes med hvor meget du får leveret med førstkommende aflevering, lige om lidt. Dine mest kvalificerede folk, som du har givet mandatet, vil optimere hvordan det løses.

Nedefra-op vil de efterspørge støtte når de vurderer det relevant, hvis din virksomhed understøtter en tillidsbaseret kultur.

Dine højtuddannede medarbejdere vil gøre deres bedste med alt deres arbejde, eftersom de ligeledes ønsker at være en succes. Hvis du ikke har tillid til de gør det, så få fat i nogle du har tillid til. Ellers udvis tillid til dem du allerede har, da tillid er en grundpræmis for agile metoder. Her handler det både om empowerment og trust.

4. Støt teamet til at få succes, på alle måder

En nøgle til success med agile metoder er inspektion og tilpasning (inspect & adapt). En nøgle til det er vidensdeling, da du dermed signalerer at du, og du alene, ikke kan opnå målet, men at det kræver en fælles indsats. At skabe den tillidsbaserede kultur hvor både store og små ting deles, uanset om de er relevante nu eller måske senere, støtter i sig selv kulturen med inspektion og tilpasning. Det er her den positive spiral starter.

Så del de overordnede linjer i det store billede, og teamet vil tage det med når de optimerer for succes. Giv teamet mandatet til at skabe forandringen og forbedringen, og de vil skabe succes, og gøre sig fortjente til den tillid du viste.

5. Del ud af læringen

Når man skal starte med agile handler det også om at lære af dine fejl – dine hovsa’er. Men det er nok de færreste der gerne vil være kendt som du-lavede-en-fejl-personen, mens de fleste gerne vil kendt som den-der-gav-guldkorn-og-viden-videre.

Så min opfordring er at sløjfe ordet ”fejl” og kald det i stedet ”læringspunkt”. Ja, det kan man sagtens kalde snyd, men det virker! Og så leder det direkte til sidste punkt på listen.

6. Fejre succes. Fra den første lille bitte og fremad

Du siger wauw når babyer smiler første gang, eller tager deres første skridt; for at opfordre dem til at blive ved med at gå. Og det virker! På samme måde når du gør noget der er lige så nyt for dig, får du fornyet energi til processen gennem opmuntringen, wauw’erne. Faktisk får du dobbelt valuta for opmuntringen; dels vil den enkelte bemærke det, og dels virker det samtidig som teambuilding, hvor teamets fælles ejerskab og ansvarlighed vokser. Og hvem kan ikke bruge det, når man skal starte med agile.

Du er nu klar til at starte med agile!

Slå dig sammen med viden og erfaring, giv mandatet til de rette personer, stør udviklingen på alle måder, del viden og fejr resultaterne sammen. Vær stolt over at se teamene agere agile , samt at tage og udvise ejerskab for det du gav dem mandat til. – Og vis det!

 

Held og lykke med den agile rejse!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

 

PS: Hen ad vejen vil du lære at vurdere agile erfaring på antallet at fejl du lavede, og lærte fra.

Hvorfor Tværfunktionelle Agile Team ligner Istapper – mens Medlemmer er T-formede

Hvorfor Tværfunktionelle Agile Team ligner Istapper – mens Medlemmer er T-formede

En af de største udfordringer ved at arbejde agilt, er at fremfor at den enkelte er ansvarlig er det nu teamet der er ansvarlig. I alle henseender. For den enkelte er det en kæmpe udfordring, men for den der tidligere var stjerneudvikleren er forandringen endnu større.

Hvis denne udfordring får særlig opmærksomhed, har du et godt fundament for et godt tværfunktionel team, eller det der på ”ny-dansk” hedder et cross-funtional team.

Hvad er forskellen på et agilt team og andre teams?

Et agilt team er et team af individer der hver besidder sine individuelle kompetencer og løser opgaver lige som alle andre gør. Den store forskel mellem agile teams og traditionelle (også kaldet sekventielle, vandfald mv) udviklingsteam, ligger i organiseringen af arbejdet. På det agile team, er det det teamet, som enhed, er ansvarlig for det arbejde det leveres. Desuden er det det agile team – som enhed – der modtager feedback for det leverede product og kvaliteten deraf, samtidig er det agile team selv ansvarlig for at løbende forbedre sine processer, metoder og de rammer de arbejder indenfor.

De kompetencer der er nødvendige for at arbejde på med agilt udvikling, er i stor udstrækning de samme som der bruges til andet udviklingsarbejde. Hvis du arbejder med udviklingsarbejde, har du behov for udviklerkompetencer og testkompetencer. Dertil kommer kompetencer indenfor identifikation beskrivelsen og prioritering af krav, salg, idriftsættelse, vedligehold (i bred forstand) mv.

På et agilt team kombineres de forskellige sæt kompetencer ind på selve det tværfunktionelle team, således at teamet selv, og indenfor teamet, har kompetencerne til at identificere, beskrive og prioritere kravene samtidig med at der inddrages behov for salg, idriftsættelse, vedligehold. Desuden kan teamet løbende inddrage opdatere fakta om udviklingen med viden om hvad der er klar til kunder og ændringer i markedsforhold.

Hvad skal der til for at blive et tværfunktionelt team?

Et team med et antal specialister er i klar et team med et højt kompetenceniveau. Er de gode til at løse opgaver? Ja, sandsynligvis. Men det kommer alligevel an på hvilke type opgaver og om de kan løse dem individuelt eller skal løse dem sammen. De er findes mange eksempler på teams med knap så skarpe kompetencer, men med høj grad af samarbejde der præsterer bedre – husk bare EM92 i fodbold.

Et tværfunktionelt team er også et team med mange kompetencer – men en af de meget allervigtigste kompetencer er evnen til at samarbejde. Helt fundamentalt kræver samarbejde, at man forstår hvad den anden person siger, og samtidig selv er i stand til at formidle sin viden på en måde som den anden person kan forstå. Selv om det er yderst komplekst og måske uden for eget domæneviden. Det er ikke nemt, men super vigtigt.

Helt konkret kræver det at visse kompetencer er besiddes af alle teammedlemmer uden dog samtidig at kræve at alle teammedlemmer er kloner af hinanden. Prøv bare at forestille dig prisen for et team hvor alle er superstjerne i alle aspekter af identifikation og prioritering af krav, udvikling og test, salg, idriftsættelse, vedligehold mv. Et potentielt dream team, men i praksis nok ikke et ønsket arbejdssted for mange eftersom den enkeltes personlige udviklingsmuligheder allerede er udtømte.

Så hvordan skal jeg sammensætte mit team?

Det du skal stræbe efter er en kombination af dybe kompetencer i de relevante domæner (udvikling og testere i relevante teknologier), konkret og relevant forretningsviden, analytiske og problemløsningskompetencer, kombineret med generelle samarbejdskompetencer, for bare at nævne dem der er relevante på tværs af forretningsområder.

For at teamet skal være effektiv og robust (fx ved individuelt fravær) bør hver kompetence besiddes af mindst to (og helst tre) personer på teamet. Selvsagt ønsker du at samarbejds- og problemløsningskompetencer besiddes af alle, men generelt set kan du klare dig med lidt mindre.

En person der har dybe kompetencer indenfor et område og visse kompetencer lidt bredere, kaldes også for T-profil (T shaped på engelsk), ud fra dybe kompetencer på et område og et vist niveau af viden derudover – inspireret af formen på bogstavet T.

Til dit team skal du således stræbe efter et samlet competencesæt der minder om T’er sat tæt på række ved siden af hinanden som TTT. Dette er illustreret her med tre T-profiler, der hver har dybe kompetencer og andre kompetencer derudover. Samarbejdskompetencer er indeholdt i den vandrette del af T’et.

 

Naturen kan dog givet en meget pænere billede af dette; en række istapper.

Hvordan starter jeg et tværfunktionelt team – eller bare får en indication af hvor jeg er?

Bare det at du stiller spørgsmålet, så er du godt i gang! Pointen er at man skal være opmærksom på den enkeltes individuelle specialist kompetencer, men samtidig også fokusere på samarbejdskompetencer, problemløsningskompetencer og helt generelle kompetencer indenfor at forbedre processer og værktøjer relateret til den agile proces.

Spørgsmålene kan rejses af teamets ScrumMaster, Product Owner eller afdækkes af en Agil Specialist der coacher teamet.

Hvor du end identificerer ”huller” i kompetenceniveauet, kan dette muligvises løses ved at udvikle alle/udvalgte på teamet, og/eller ved at have netop disse kompetencer for øje ved næste rekruttering til teamet – også så evt. ”huller” ikke udvides.

 

Så held og lykke med at dyrke agile istapper!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

At blive et High Performance Team Starter med Product Owner’en

At blive et High Performance Team Starter med Product Owner’en

Er det så simpelt? Ja!

Du bør aldrig undervurdere værdien af en virkelig, virkelig god Product Owner eftersom Product Owner kan betyde forskellen mellem succes og fiasko – til tider uden selv at være klar over det. Lad os starte fortællingen lidt før.

I den ideelle verden er listen af krav (Product Backloggen) altid i perfekt orden; dvs. alt er velspecificeret og velbeskrevet, både i forhold til hvad der er behov og hvad der ikke er behov for, sammen med den ønskede kvalitet velbeskrevet. Desuden er alt på Product Backloggen splittet i ”passende bidder”, således at teamet kan levere hver og en, inden for en sprint. Sidst men ikke mindst er alle elementer unikt prioriteret efter vigtighed, for at undgå tvivlstilfælde.

Det forberedende arbejde med at planlægge hvilket output der leveres ved sprintens afslutning, bliver gennemført effektivt, gnidningsfrit da alle svar er til stede, samt forudsigeligt da tilstrækkelig viden understøtter glat estimering af punkter på listen, og dermed den samlede forventning til sprintens resultat (sprintens mål). Igennem sprinten bliver forventninger løbende afstemt, hvis og når der er behov for det. Samlet gør det teamet i stand til til stadighed at levere i forhold til aftaler – og uden overraskelser.

Fint, men jeg befinder mig i den virkelige verden!

Og det er PRÆCIS det vi alle gør. ”Noget” går i stykker, love/regler bliver ændret, vi bliver ramt af konkurrence, faktisk kan ALT ske på en almindelig dag på kontoret. Forskellen i hvordan vi håndterer det, handler om hvordan vi er forberedte på det.

Så hvad skal jeg gøre?

For at få en idé om hvor du står, skal du have styr på de overordnede prioriteter. Hvad er vigtigt for din virksomhed, for teamet og måske nogle aktionærer.

  • Laveste gennemsnitlige omkostninger for udvikling
  • Korteste gennemsnitlige tid fra idé til idriftsat product
  • Nul fejl opdaget i produktion
  • Hurtigste reaktion på markedsændringer (eller andet), eller måske er noget helt andet vigtigst

Når de overordnede prioriteter er kendt, start med at samle data, og mål på det, både konsistent og vedholdende over tid. Tilfør synlighed og transparens  ved at resultater løbende deles med teamet og alle små som store forbedringer fejres. Det vil i sig selv føre til flere forbedringer.

Men HVORFOR vil det blive bedre?

I et tillidsbaseret miljø vil teamets stræben efter succes, afsløre de steder med overlevering af information, der kan forbedres. Og disse involverer i hovedsagen Product Owneren og (dele af) teamet, uanset om det handler om at indsamle information, effektivt strukturere information, dele informationen, samt stå til rådighed for yderligere information – både for teamet og interessenter.

Derfor kan Product Owner betyde forskellen mellem succes og fiasko!

For at komme frem til den nødvendige indsigt i samspillet, kan du enten starte med at vende hver en sten, eller slå dig sammen med en Agile Specialist der kan hjælpe med at vende de vigtigste sten først, således at du får resultater hurtigere.

Held og lykke med den agile rejse!

Majken Vildrik Thougaard, Uafhængig Agile Specialist, Ejer VILMA Consulting

 

PS: Product Owner’en kan ikke trylle, så en god ting er at sikre at Product Owner er empowered til at skabe succes!

Nu er vi agile! Men var dét så det?

Nu er vi agile! Men var dét så det?

Jubii! Nu har vi agile arbejdsgange og alle er glade. Men er dét så det? Kunne vi blive (endnu) bedre, kunne vi levere (endnu) mere, kunne vi ”blive mere glade for vores agile omstilling”?

For hvordan kan man egentligt vide om det der er gjort er ”godt”, eller bare ”godt nok” og hvor meget bedre kunne det blive? Og hvad skal man gøre for at det kunne blive bedre?

 

I holder de agile møder som beskrevet, måske har i også et scrum board (digitalt eller som tavle) og en ScrumMaster – så må det da være agilt! Tja, det kan det sagtens være – men det er faktisk ikke en garanti. Man kan også være agil uden agile møder og board (det kræver bare noget andet).

Og derfor får i heller ikke den fulde værdiskabelse af at være agile!

Steder at kigge på jer selv er fx hvor lang tid der går fra ide til produktet er i virkeligheden. Hvor gode er i rent faktisk til at reagere på forandringer? Hvordan bliver i ramt, hvis i fjerner en nøgleperson fra teamet? Hvor tit og hvor længe venter teamet på en afklaring? Hvor motiveret er den enkelte? Leverer teamet på et stabilt og højt niveau? Trives den enkelte på teamet (og tror du de også er der om ½ eller 1 år)? Hvem repræsenterer teamet?

Disse er eksempler på spørgsmål der indikerer at i kan få mere agil værdiskabelse.

Men hvordan kan jeg vide det?

Det kræver at man opsøger informationen, lytter efter, når og hvor det bliver italesat. Og nogen gange kan andre personer bedre få svar, end man selv kan. Måske fordi det ikke altid bliver udtrykt på en 1-10 skala, men kommer (indirekte) frem til fx Sprint Review eller andre inspection tidspunkter. En erfaren og dreven Agile Coach, der selv har udfoldet de forskellige agile roller, ved hvordan det kommer til udtryk, og bør kunne se på teamets samspil og samarbejde, AT skoen trykker og hvor.

Held og lykke med den agile rejse

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

PS: Hvis du allerede har investeret i den agile transformation, så husk at tage værdiskabelsen med! Der er ingen der takker dig, for at lade den ligge.

Enkelt at lære – svært at mestre

Enkelt at lære – svært at mestre

At være agile er lige så nemt som at cycle, for den der kan det. Kun få ting skal du vide før du er klar – bremser du med foden eller hånden og hvilken side af vejen kører du i. Og så er du klar til at køre.

Det samme gælder faktisk for agile metoder hvor principperne er beskrevet i det agile manifest (http://agilemanifesto.org/), om end mere overordnet. Det positive er at det er eminent som pejling i komplekse situationer; men samtidig er det også nærmest uanvendeligt, hvis du lige skal til at starte din agile rejse.

Men hvad så?

Lidt afhængigt af hvor meget det haster med at levere hurtigere og til en lavere omkostning, kan du vælge enten at prøve dig frem, eller alliere dig med en der kender faldgruberne, hvordan man styrer uden om og kommer videre, hvis uheldet er sket. En allieret der kan guide dig til at komme hurtigere i gang, komme mere effektivt i gang og opnå mere.

Vælg den første løsning hvis du har god tålmodighed og kerer dig mindre om budget og mere om organisk læring i et holdbart tempo. Du bliver stærk til at lære af egne fejl og oplever fuld kontrol over rejsen.

Men vælg en allieret og tilfør massiv agil praktisk erfaring og indsigt, hvis overskud (dels lavere omkostninger og højere provenu), muligheden for at sætte og indfri mål, og ikke mindst ønsket om hurtigere start og resultater er vigtigst. Den initiale investering i en agile coach bliver rigeligt opvejet af den kontinuerte levering af holdbare produktudvidelser, højere kvalitet og kortere time-to-market (responstiden fra idé til produktudvidelsen er en realitet, internt eller eksternt).

Held og lykke med den agile rejse!

Majken Vildrik Thougaard, Uafhængig  Agile Specialist & Ejer af VILMA Consulting