CMMI og Agile

Formålet med denne artikel er at vise, at det er muligt at opnå både forudsigelighed og agilitet i ens udviklingsprocesser, også selv om organisationen udvikler komplekse produkter og/eller har med komplekse markeder at gøre. CMMI V2 er modellen, der kan skabe overblik og vise vejen.

CMMI og Agile

Share:
    Indhold       ► CMMI vs Agile   ► Hvad er Agile   ► Hvilken type udviklingsorganisation?   ► Agile fordrer tillidsbaseret kultur   ► De nødvendige kompetencer for agilitet   ► ML2 - Den agile opstart   ► ML3 - Den agile spurt   ► ML 4 & 5 - Den agile excellence  ► Resumé og nyttige links

CMMI_Agile.jpg

Formål og målgruppe for artiklen

Formålet med denne artikel er at vise, at det er muligt at opnå både forudsigelighed og agilitet i ens udviklingsprocesser, også selv om organisationen udvikler komplekse produkter og/eller har med komplekse markeder at gøre. Kompleks i denne kontekst betegner, at

  • produktet skal leve op til en vis kvalitet (fx opfylde visse compliance-krav),
  • det er er ikke teknisk trivielt,
  • kunde-siden ikke er triviel og det kan have store konsekvenser at fejle (kan evt. være kontrakt-baserede bestillinger),
  • produkterne/services har en længere levetid i markedet.

Denne artikel henvender sig til organisationer, som

  1. overvejer at skifte over i et mere agilt udviklingstempo med hyppigere releases af produkter og services til markedet og kunderne
  2. har søgt at arbejde agilt i nogle år, men ikke har opnået de gevinster endnu, som man oprindeligt håbede på
  3. har søgt at udbrede / opskalere agilitet i større dele af organisationen uden held

Opstiller vi en lille modenhedsskala

  1. Agilitet og CMMI kan ikke sameksistere
  2. Agilitet og CMMI kan sameksistere (men har ingen synergi)
  3. Agilitet og CMMI har synergi
  4. CMMI bidrager med noget værdifuldt til agilitet, som ikke ellers ville komme på bordet
  5. CMMI er en forudsætning for værdifuld agilitet eks. skalerbarhed og robusthed

så ligger artiklens budskab på niveau 4 eller 5 :-)

CMMI vs Agile - er det reelt en modsætning i en moderne organisation?

CMMI eller Capability Maturity Model Integration, er et best practice rammeværk, som opstiller en række discipliner (Practice Areas), som en organisation bør mestre, hvis de ønsker eller har behov for at udvikle produkter eller services til markedet med en vis præcision, pris og kvalitet. Practice areas er opstillet inden for projektledelse, engineering, procesledelse samt ikke mindst ledelse. Læs mere om modellen her: CMMI Overbliks artikel.

Er CMMI ikke en voldsom bureaukratisering af organisationen, når vi gerne vil være agile, reagere hurtigt på markedsændringer, tilføje nye features til vore produkter dagligt - ja, er det ikke ligefrem i strid med det agile manifest?  Det er desværre manges umiddelbare holdning, når vi møder folk, der ikke er vant til at arbejde i procesorienterede organisationer og derfor mest trækker på antagelser og holdninger hos andre.

Proces-orientering.png

Med procesorientering mener vi, at organisationen har identificeret og kortlagt en række væsentlige forretningsprocesser, så alle medarbejdere ved, hvordan de skal udføre deres rolle, med hvilke værktøjer og metoder og ikke mindst med en forståelse af det ansvar, der ligger i rollen. Processerne understøtter tværfagligt samarbejde, og det er transparent, hvordan kunder, markeder, teknologier og ikke mindst fagligheder håndteres i organisationen.

I denne artikel vil vi forsøge at tilgå emnet ud fra et realistisk billede af en typisk organisation og ikke blot ønsketænkning. 

Hvad er "Agile development"?

Agile, eller på dansk at arbejde agilt, opstod i 90'erne som en reaktion imod at arbejde med lange leveringstider, store kravspecifikationer (og mange andre specifikationer), vandfaldsmodeller eller Rationals Unified Process model. Produkter kunne snildt være 1 til 3 år undervejs, uden at kunderne eller markedet så noget til dem, fordi det ikke blev anset for værdifuldt at have løbende inddragelse (faktisk også for mange indkøbere). Udgangspunktet for agil udvikling er at levere fungerende produkter på markedet på relativ kort tid, men naturligvis ikke med det fulde feature-sæt.

Ideen var, at verden ændrede så meget på 1-3 år, at ingen ville kunne forudsige, hvilken funktionalitet produktet i sidste ende skulle besidde - så hellere lære og tilpasse undervejs, efterhånden som man blev klogere.

I samme periode begyndte teknologien, værktøjer og nye hardwareplatforme (det der senere kommer til at hedde "Cloud") at understøtte hurtige gennemløbstider, fx web-baserede "applikationer", begreber Software as a Service (SaaS) dukkede op og markedet ville have software løsninger hurtigere end tidligere. I år 2000 mødtes en række dygtige software folk i Oregon, USA, for at sætte et sæt nye spilleregler op, som kunne levere gode softwareprodukter, i tæt samarbejde med kunder, med hyppig releases (1  2 uger den gang) med en lean tankegang om kun at lave præcis det, som kunder ville betale for, men samtidig opretholde høj kvalitet.

I 2001 kom det  agile manifest til verden (link), som beskrev en række nye værdier sat i forhold til et sæt gamle (vandfaldstænkningen) og dermed blev Extreme Programming (XP) det nye sort. 

Scrum som agil og især empirisk procesmodel for at lede udviklingsarbejdet dukkede også op begyndelsen af 90'erne bedst beskrevet af Ken Schwaber og Jeff Sutherland (men stammer fra Japan, hvor Ikujiro Nonaka og Hirotaka Takeuchi i 1987 beskrev modellen for hyper-produktiv udvikling), og introducerer en række rafinerede begreber såsom Product Backlog (feature krav), Backlog Refinement, Product Owner, Scrum Master, Scrum Teams (max 7 personer), Sprint (1-3 ugers udviklingsfaser), Sprint Planning, Daily Stand-up, Burn-down, Planning Poker, Definition of Done, Refactoring, Velocity, Demos, og Sprint Review, Retrospectives. Alt dette er beskrevet i bogen "Agile Software Development with SCRUM" fra 2001 (Ken Schwaber, Mike Beedle). Scrum metoden beskriver rent faktisk kun, hvordan eet team af op til 7 personer skal arbejde sammen, så derfor blev "Scrum of Scrum", Nexus og LeSS udviklet til at beskrive, hvordan flere Scrum teams skal koordinere arbejdet omkring et fælles produkt.

Senere er Kanban stødt til, lånt fra Lean verdenen, som dagligt prioriterer opgaver, og som sikrer, at der er få opgaver i gang pr person ("work in progress" < 3). Kanban er blevet populær, hvor Scrum anses for langsomt eller omfattende (!). 

Scrum tegning.png

Begrebet Minimal Viable Product (MVP) blev beskrevet i The Lean Startup (Eric Ries, 2009), som kort går ud på at lave et produkt, der med minimale, men alligevel brugbare features kan sælges på markedet og høste feedback fra kunder og herefter forbedres kontinuerligt.

Målet med en agil udviklingsproces er at levere fungerende software til markedet og kunderne hurtigt, hente feedback fra markedet, rette til, levere i et kontinuum - nogle virksomheder frigiver nye versioner dagligt, andre ugentligt og andre hver fjortende dag. Sammenholdes det med tidligere tiders cykler på 1-3 år, så skal der ikke meget fantasi til at regne ud, at det kræver en hel del kompetencer teknisk, såvel som ledelsesmæssigt, stor og hurtig beslutningskraft, strømlinede processer og værktøjer og ikke mindst tæt kundekontakt. 

Bruger vi et nybyggeri af et ejendomskompleks som eksempel, så vil vandfaldsmodellen sikre at huset i 10 etager er mere eller mindre helt færdigt, inden nogen flytter ind. I den agile model, flytter folk ind allerede når første etages, første lejlighed er klar, og vi ved ikke helt hvor højt huset bliver, og lejlighederne vil ændre sig undervejs.

Et andet billede kunne handle om hastigheden. Jo hurtigere ting ændrer sig jo mere kræver det, at holde styr på dynamikken – både i form af kompetencer hos udviklerne (som skal kunne bidrage i mere ”flydende” omgivelser, og kunne lide det) og ved de værktøjer, der bruges (eks. bliver systemer til konfigurationsstyring/continuous build meget centrale).

Hvilken type udviklingsorganisation taler vi om?

Lad os først opbygge lidt kontekst for artiklen. "Organisationen" er i denne artikel ikke en start-up med et 3-7 mands team, der forsøger at få det første SaaS produkt lanceret på markedet. Forestil dig, at organisationen er en lidt mere kompleks størrelse, fx en mellemstor virksomhed (i Danmark typisk mellem 50 og 500 ansatte, med en udviklingsafdeling på 20 - 200 personer), der har udviklet og "produceret" produkter og services i mange år, og vis produkter skal eksistere i flere år fremad også. Produkter og services, som skal have tilført nye features, som skal følge med teknologiens udvikling, som er under konkurrence på pris, performance, kvalitet mv. 

Organisationen kan desuden være forankret i flere lande, flere tidszoner, flere kulturer, og den kan bestå af en række forskellige fagligheder i produktudvikling (hardware, mekanik, software), og lægger vi produktion, marketing, salg, service, økonomi-funktioner oveni, så begynder vi også at forstå kompleksiteten omkring beslutningsgange. 

Skal organisationen desuden leve op til branchekrav, compliance-krav, og samtidig være profitabel, øge omsætning, tage markedsandele, så bliver det vist tydeligt, at softwareudviklings-teamet risikerer at forsvinde lidt i mængden - selv i rene software-huse. 

Sidst men ikke mindst er organisationen afhængig af at fastholde og tiltrække folk, at videreuddanne medarbejdere til nye teknologier og fagligheder, samt ikke mindst sikre en høj medarbejdertilfredshed for de typisk dyre akademikere.

Udfordringer, der typisk herudover opstår i den slags organisationer, er illustreret herunder.

Kaos_organisation.png

Der skal ikke meget fantasi til at forestille sig, at større organisationer har endog meget svært ved at agere og arbejde agilt. Pointen med denne artikel er at vise, at det rent faktisk godt kan lade sig gøre, hvis man vil investere i det.

Agilitet hviler på en tillidsbaseret kultur

I 2015 benyttede 70-80% af de organisationer, der gennemgik en formel CMMI appraisal (ekstern bedømmelse), agile udviklingsprocesser (kilde: CMMI Institute). Disse organisationer har med andre ord evnet at kombinere høj modenhed med den agile kultur.

CMMI_agile_appraisals.png

Det er der en meget god grund til - grundstammen i den agile tankegang bygger jo på tillid til, at selvstyrende teams rent faktisk evner at levere de produkter og services, som kunderne og forretningen efterspørger - til tiden, til prisen og ikke mindst til den forventede kvalitet, både hvad angår indhold og brugbarhed. Dermed får disse teams så også frihed og ansvar til at arbejde sammen med, hvad der i virkeligheden er virksomhedens kunder.

Scrum, XP, Kanban mv. er blot fremdrifts- og styringsmetoder - men de skaber ikke i sig selv agilitet - hvilket også er grunden til, at rigtig mange organisationer, der har arbejdet med disse metoder ikke har opnået den agilitet og de bedre resultater, man håbede på. 

Hvis det ikke lykkes at opbygge en tillid mellem ledelse og udviklingsteams, så fastholdes vandfaldslignende kontrolregimer samtidig med, at ledelserne nu forventer en langt større fleksibilitet, end hvad virkeligheden omkring de agile teams evner at levere.  

Man kan jo spørge, hvor agile projekter kan være, når de eksisterer i ikke-agile omgivelser (eks. langsommelige beslutningsgange, andre faggrupper/funktioners modstand, klassiske kontrakter med store kravspecifikationer og betalingsudløsende milepæle, ikke-agile kunder, ...)? 

Det er her, hvor CMMI kan hjælpe agiliteten på vej - ved at organisationens ledelsen skaber mulighed for stabilitet og performance i de nødvendige processer, der understøtter agile teams, og herved begynder at performe og skabe værdi, som igen skaber tillid til deres kapabilitet - se mere om dette i næste afsnit.

CMMI-Agil Ledelse.png

De nødvendige kompetencer for agilitet

Vi har i Proces360 selv arbejdet i organisationer, som har gennemført rejsen fra niveau 1 til 5, i hårdt konkurrenceudsatte brancher - og vores erfaring er den, at et forretningstilpasset ledelsessystem rent faktisk understøtter effektiv og langtidsholdbar produkt- og serviceudvikling - og især understøtter, hvad det agile manifest kræver af en større organisation.

Agile værdier og modenhed
   Agil værdi  Høj kompetence og modenhed
1 Individuals and interactions over
processes and tools

Processer er gjort lean, alle kender roller og ansvar. Værktøjer passer til forretningsbehov - end-to-end, og understøtter fuldt ud det agile tankesæt.

Hermed kan medarbejdere arbejde effektivt sammen i hverdagen. 
2 Working software over
comprehensive documentation

Organisationen har identificeret det rette forretningsmæssige behov for dokumentation og form, så der ikke længere spildes tid på debat om dette.

Softwaren virker, fordi den kan opdateres og vedligeholdes effektivt uden en masse møder og afhængigheder til særlige individer.
3 Customer collaboration over
contract negotiation
Organisationen har via effektive kravudviklings- og samarbejdsmetoder fået etableret gode kunderelationer, der er tillidsbaseret og skaber gode resultater. Kunder (eller repræsentanter) deltager aktivt i validerings-workshops, demo's etc. Kundeforholdene er måske ligefrem kommet så langt, at agile kontrakter er grundlag for samarbejde.
4 Responding to change over
following a plan
Organisationen excellerer i Scrum eller Kanban, måske er hele virksomheden blevet agil (fx via SAFe eller andre skaleringsrammeværk), og planer er snarere overordnede tværfaglige planer og product roadmaps, der kan vejlede retningen for organisationen, teknologi og valg af platforme.

 

Modenhedsniveau 2 - Den agile opstart

Rejsen til modenhedsniveau 2 er i høj grad ledelsesdrevet, da det for mange virksomheder er en kulturforandring, der skal til. De fleste niveau 1 organisationer er drevet af stærke individer, og deres måder at arbejde på og ikke mindst deres tilstedeværelse i "rummet". Prioritering og beslutningstagning sker oftest ud fra en magtposition og ikke nødvendigvis ud fra kendte parametre. Agilitet handler i høj grad om at arbejde som teams, hvor man bidraget bedst muligt og hjælper hinanden med at opnå fælles, committede mål.

En organisation, der vælger at operere på niveau 2 modenhed, vil styrke agiliteten på følgende områder i produktudviklingen:

  • Kundekrav og behov identificeres og bearbejdes til et niveau, der er brugbar for udvikling og placeres i en product backlog, der er prioriteret og ændringsstyret. Det er accepteret, at der skal opnås et tæt forhold til kunder (eller repræsentanter for kunder/markedet), så behov og prioriteter kan forstås; det er klart for alle, at der skal afsættes tilstrækkelige ressourcer til modning af de højest prioriterede product backlog items (PBI). Definition of Ready er kriteriet for, at PBI'er klar til udvikling/allokering til Sprint backlogs. 
    (CMMI Practice Area: Requirements Management & Development)
     
  • Estimater af backloggens prioriterede features opbygges i rimelig pålidelig kvalitet, så vi ved, hvad det kræver at færdigudvikle opgaven. Vi har lært at benytte forskellige metoder, fx planning poker og andre team metoder, og vi har opnået en vis forståelse af burn-down og velocity.
    (CMMI Practice Area: Estimating)
     
  • Ressourcer, nødvendige kompetencer, tid og afhængigheder identificeres og committes, så vi ved at opgaverne, der igangsættes - enten i Sprints eller via Kanban overblikket, kan gennemføres med rimelig sikkerhed.
    (CMMI Practice Area: Planning)
     
  • Vi evner at måle de forretningsmæssige væsentlige ting - fx fremdrift (velocity, burn down rate etc.), kvalitet (via test coverage), og omkostninger, og vi bruger målinger i teams til at justere på Scrum eller Kanban processen. Vi bruger bla. disse målinger til at få Daily Standups til at fungere effektivt. Vi oplever dog store variationer i vore målinger. 
    (CMMI Practice Areas: Monitor & Control, Managing Measurement & Performance)
     
  • Vi evner at styre vores sourcekode (effektive, agile værktøjer til styring af versioner, branching/merging/code review, allokering til releases) og væsentlig dokumentation, og vi evner at styre ændringer til indgåede aftaler (krav, sprints, allerede færdiggjorte moduler). Vi er i gang med at få discipliner som automation via continuous build/integration/deployment implementeret.
    (CMMI Practice Area: Configuration Management)
     
  • Vi evner at sikre, at de aftalte måder at arbejde på, rent faktisk følges af teams - og hvis der findes afvigelser, så følges de til dørs. Retrospectives og audits sikrer desuden værdifuld videndeling. (CMMI Practice Area: Process Quality Assurance)
     
  • Bruger vi underleverandører, så sikrer vi, at disse performer på det nødvendige niveau, og vi håndterer afvigelser. Vi planlægger desuden med et effektivt samarbejde.
    (CMMI Practice Area: Supplier Agreement Management)
     
  • Ledelsen sikrer, at de nødvendige ressourcer, kompetencer og værktøjer er til stede til dels at udføre projekterne, men også nødvendige procesforbedringer, at roller og ansvar er definerede og kendte (fx Product Owner, Scrum Master, Scrum coach, QA), at der er banet vej for at arbejde agilt i organisationen (aftalte processer er tilgængelige på projektniveau), fx ved at understøtte implementering af Scrum. 
  • Ledelsen sikrer, at projektprocesser og projektroller justeres, hvis de ikke fungerer tilfredsstillende, og sikrer desuden fokus på at få aftalte processer til at virke tilfredsstillende, inden flere igangsættes (dette kræver nemlig også ressourcer og læringstid). Fx, består Scrum af række individuelle praktikker, som hver især kan være svære for en organisation at implementere, men som er nødvendige tandhjul i Scrums "præcise urværk". 
  • Ledelsen sikrer- ikke mindst - at opståede problemer, der ikke kan håndteres på team niveau løses på højere niveau. (CMMI Practice Areas: Governance, Implementation Infrastructure)

Modenhedsniveau 2 handler meget om at finde ud af, hvordan projektledelsesprocesserne (fx Scrum eller Kanban) skal bringes på plads og fungere sammen med den øvrige del af organisationen uden for udvikling.

Modenhedsniveau 3 - Den agile spurt

Hvor modenhedsniveau 2 organisationen i høj grad fokuserer på projektledelse (i "klassisk" eller agil forstand) og evnen til at levere produkter inden for aftaler, så søger niveau 3 organisationen at standardisere en række projekt- og udviklingsdiscipliner, hvorved projektledelsen kan performe og skalere endnu bedre (fx via Jeff Sutherlands "Scrum of Scrums", Scrum.org's Nexus for Scaling Scrum, eller Craig Larman/Bas Vodde's Large Scale Scrum - LeSS). 

De tekniske discipliner raffineres, avancerede metoder indføres og teams arbejder kompetent og selvstyrende. Læg hertil, at hele ledelsesopgaven, teknisk såvel som styringsmæssigt er data-understøttet.

  • Kundekrav og behov har vi nu velfungerende metoder for at udlede, og de beskrives evt. som Epics, Features og User Stories; der laves fx prototyping, design sprints, user stories mv. for at skabe bedre dialog med kunderne (eller brugere). Vi har desuden langt bedre indsigt i afledte krav (usability, serviceability, maintainability, cybersecurity, performance) og Definition of Ready (DoR) er nu fuldt forankret. Såfremt organisationen ikke allerede arbejder med product roadmaps, så vil det tage form på dette niveau - dels for at opbygge en teknisk strategi, og dels for at sikre, at der er de tilstrækkelige ressourcer tilstede i organisationen til at understøtte en mere langsigtet kunde- og markedsstrategi, fx formuleret igennem Release Planning begrebet. 
    Product Owner rollen, der er en af de mest komplekse roller i Scrum, er nu vel forankret og bemandet i organisationen, og ofte besat af kompetencer udenfor udviklingsafdelingen også. 
    (CMMI Practice Area: Requirements Management & Development)
     
  • Omsætning af kundekrav til produkt eller service foregår ved hjælp af en udviklingsmodel, der tager højde for arkitektur- og designkrav, der lever op til markeds- og forretningsmæssige standarder; kode udvikles i henhold til standarder, der sikrer kvalitets og vedligeholdbarhed, evt. vha Pair Programming for komplekse opgaver, og vi evner at gennemføre en række (automatiserede) unit tests.

    Produktarkitektur kommer i højsædet, da erkendelsen af, at en monolitisk arkitektur med for mange afhængigheder ikke egner sig til opskaleret agil udvikling med CI/CD/DevOps målsætninger.
    Kvalitetssikring foregår tidligt i processen ved hjælp af peer reviews og løbende validering (fx Sprint Demo's), og senere via verificering op imod krav. Definition of Done (DoD) samler disse kvalitetskrav sammen, og det kan være automatiseret gennem Continuous Build/Integration systemer (fx vha. Jenkins, automatiske unit tests, statisk kodeanalyse).

    Såfremt produktet består af en række del-systemer, interfaces og andre afhængigheder, så bruger vi metoder til at koordinere integrationen af del-systemerne i god tid, fx via Scrum of Scrums, der håndterer risiko i interfaces såvel som tidlig verifikation af nye del-systemer. Kultur og metodemæssigt, arbejder vi sandsynligvis med Continuous Integration tool chains på dette tidspunkt og er måske igang med Continuous Delivery også. Hvis markedet og kunderne er indstillet på det, så tænker vi også DevOps ind i processer og værktøjerne.

    Fejl og uhensigtsmæssigheder, vi finder gennem kvalitetssikringen, lærer vi af gennem at undersøge årsager til deres opståen - og vi retter produkt, processer, metoder, værktøjer op, om nødvendigt.

    Består produktudviklingen af mange Scrum teams er vi begyndt at opskalere Scrum teams til at koordinere arkitektur og interfaces (se tidligere). Er produktkvalitet en primær parameter, indfører vi eksempelvis Test Driven Development og Pair Programming som metoder. 
    (CMMI Practice Areas: Technical Solution, Product Integration, Verification & Validation, Peer Review, Causal Analysis & Resolution)
     
  • De projektprocesser, udviklingsmetoder og værktøjer, som organisationen har indført og som skaber værdi, skal udbredes i organisationen til nye medarbejdere, eller medarbejdere, der endnu ikke er løftet kompetencemæssigt. Uddannelsesprogrammer og metoder udvikles, så dette kan gennemføres effektivt, og der stilles krav om, at kompetenceløftet sker. Ledelsen sikrer sig igennem relevante målinger, at det opnås.
    (CMMI Practice Area: Organizational Training)
     
  • Komplicerede eller vigtige beslutninger analyseres af specialister for mulige alternative løsninger ud fra et sæt valgte beslutningsparametre (fx tid, omkostning, kvalitet, risiko eller product roadmap). Dette giver ledelsen mulighed for at træffe kvalificerede valg. Eksempler kan være valg af ny teknologi, valg af agilt rammeværk, valg af værktøjer, valg af leverandør eller blot valg af en ud af flere løsningsmuligheder i et Scrum team.

    Benyttes en formel metode til at understøtte en beslutningsproces, er vores erfaring, at produkt- eller procesinnovation ofte er et meget positivt biprodukt i den kreative proces, som i mange tilfælde er flerfoldigt mere værd, end investeringen i den tid, der bruges i processen. 
    (CMMI Practice Area: Decision Analysis & Resolution)
     
  • (Projekt)ledelsen styrkes gennem fokus på identifikation og håndtering af risici og muligheder. En organisation, der har opnået et modenhedsniveau 2 og på vej mod 3 har mere overskud til at se ud i fremtiden, og håndtere ting, der måske vil ske. Det agile begreb "Refactoring" er blevet en naturlig del af risikohåndteringen, hvorved vi fornyer eller helt omskriver moduler, der ikke længere er holdbare.

    Hele den agile tilgang til produktudvikling kan betragtes som en måde at håndtere risiko på, hvorved det måske nemmere kan kommunikeres ud til omverdenen, hvis den er mindre "agilt" indstillet.
    (CMMI Practice Area: Risk & Opportunity Management)
     
  • Organisationen har set værdien i at opsamle relevante data, der fortæller noget om de processer, der benyttes og de produkter og services vi udvikler. Et eksempel er at relatere fundne fejl (i test eller i marken) til moduler i produktet. Hvis der opstår en trend, der peger i retning af, at et modul er årsag til for mange fejl, relativt set, er det måske på tide at gennemføre en refactoring af modulet. På denne måde får vi løbende håndteret teknisk gæld, fremfor det håber sig op til en større investering.

    Et andet eksempel er at sikre, at vore kvalitetssikrende processer, der ud fra et Lean perspektiv kan ses som spild at tid, rent faktisk finder de fejl, der er. Igen kan trend-analyser af gennemførte DoR's, DoD's, reviews og testindsatser vise, hvorvidt effektiviteten af disse er faldende.
    (CMMI Practice Areas: Managing Measurement & Performance, Causal Analysis & Resolution)
     
  • Organisationen har nu set værdien i at være procesorienteret, dvs. vi ved alle hvad vi laver, hvorfor og hvordan, og der er ressourcer til at gøre det rigtigt. Derfor investerer vi i at opbygge et (kvalitets)ledelsessystem til at forankre de procesbeskrivelser, metoder, og skabeloner, som projekterne har opbygget i løbet af niveau 2 rejsen. Jo bedre definerede projekt- og udviklingsprocesser understøtter arbejdet, jo mere kan teams arbejde selvstændigt. Ledelsen har jo nu fuldt ud erfaring med og tillid til, at det er sådan resultater bedst opnås.

    Værktøjsunderstøttelse til Scrum/Kanban, backlogs, udviklings- og testprocesser og automatisering er i høj grad i fokus for at arbejde så effektivt og fokuseret som muligt i jagten på værdiskabelse og performance. Opnåelse af disse skaber tillid til udviklingsafdelingen og giver derved større frihedsgrader og investeringsparathed.

    Ledelsessystemet er i høj grad også der, hvor læringer og erfaringer fra retrospectives, interne audits og projektresultater opbevares, hvorved det er nemt at genfinde information, fx til forbedring af estimeringsevnen, til raffinering af risikovurdering og håndtering, til forståelse af læringsevnen, og ikke mindst til indsigt i effektiviteten af de forskellige kvalitetssikrende processer (peer review, validering og verifikation). I den agile organisation vil procesforbedringer naturligvis også gennemføres ved hjælp af agile metoder.
    (CMMI Practice Areas: Process Management, Process Asset Development)

Hvis din organisation udvikler produkter eller services, som skal holde mere end 1 år, skal opfylde nogle givne kvalitetskrav, skal leveres til kontraktuelle deadlines og indhold, så er ovenstående eksempler fra CMMI rammeværket i højeste grad relevant for dig. 

Modenhedsniveau 4 og 5 - Den agile excellence


Modenhedsniveau 4 og 5 er rettet imod organisationer, der ønsker at være "best in class", og som befindes sig i høj-konkurrence markeder eller har meget krævende kunder / branche-krav.

 en agil kontekst, perfektionerer organisationen CI/CD/DevOps via velsmurte og sammenhængende værktøjer og processer. Den data-drevne organisation bruger statistiske metoder til at reducere variation i projekt- og kvalitetssikrende processer. Fejl gennemanalyseres for root causes, og processer opdateres for at undgå disse fremadrettet.

Organisationer på disse niveauer har så godt styr på kompetencer og risk management, at de evner at påtage sig langt mere komplekse projekter eller kunder. Nogle virksomheder vil arbejde sig op i værdikæden - fra at være underleverandør eller mindre spiller i markedet til at ende som system integrator. Opkøb af virksomheder vil være en naturlig måde at vokse på, og da man har fuldstændig styr på processerne, kan disse nemt overføres til de opkøbte virksomheder.

Resumé og nyttige links

Vi håber, at vi med denne artikel har bidraget til din forståelse af, hvordan CMMI rammeværket kan øge performance og værdiskabelse og gøre din organisation (mere) agil, men hvor de gode discpliner ikke smides ud med badevandet. Gennem fokus på at få nødvendige ledelses- såvel som udviklingsmæssige fagdiscipliner på plads i en værdiskabende rækkefølge, kan du opnå væsentlige bedre resultater i dine projekter og udviklingsforløb. 

Hvis du har udfordringer med at få den agile udviklingsmaskine til at virke, håber vi, at der er inspiration i artiklen til at forstå, hvorfor og hvilke discipliner, der måske mangler eller skal have større fokus. Et typisk eksempel er, at Product Owner rollen er underbemandet eller ikke er kompetent nok. Et andet eksempel er, at produkt-arkitekturen ikke egner sig til agil paralleludvikling med mange teams, der skal koordinere en række afhængigheder.

Vi har i Proces360 personligt implementeret og oplevet denne forbedring - i forskellige brancher og over tid. Ønsker du en uddybning af modellen, stiller vi også gerne til rådighed for et uforpligtende møde.

Læs mere om CMMI og Agile her: