Agil Udvikling vs. Klassisk Projektledelse

28. februar 2015
Hvis du vil have indblik i hvordan dine medarbejdere oplever de agile udviklingsprocesser og du ønsker indblik i hvordan de effektivt kan implementeres eller forbedres? Klassisk projektledelse med baggrund i den kendte vandfaldsmodel for udvikling af nye produkter har som underliggende præmis, at specifikation, design og konstruktion af disse produkter kan defineres på forhånd og styres gennem opbygningen af en detaljeret projektplan. Udvikling bliver således en stort set mekanisk proces, der gennemføres i henhold til planen med få tilpasninger og justeringer, der skyldes håndtering af de usikkerhedsmomenter der vil opstå undervejs i forløbet. Et grundlæggende problem ved anvendelsen af vandfaldsmodellen til udvikling er, at specifikation, design og konstruktion ofte ikke præcist kan besluttes og planlægges på forhånd. Produkt- vision, krav og behov, mål og teknologi kan ændres uforudsigeligt undervejs i udviklingsforløbet når nye idéer opstår, der kommer påvirkninger fra konkurrenter og fra markedet eller der gøres teknologiske opdagelser. For at opnå succes i en dynamisk verden er det derfor fleksibilitet og tilpasningsevne, der er brug for i højere grad end den intense up front planlægning, der er karakteristisk for klassisk vandfaldsudvikling. Der er en række spørgsmål, som man kan stille sig for at afgøre om den klassiske udviklings-model er tilstrækkelig, eller om der er behov for agile metoder:
  • Er det muligt at opstille et kortfattet sæt af produktkrav, der vil opfylde kunde- og markedsbehov 1, 3 eller 5 år ud i fremtiden?
  • Er produktkravene stabile igennem projektforløbet?
  • Opfylder produkterne til stadighed kunde- og markedsbehov?
  • Er det muligt at opbygge en detaljeret projektplan, der præcist beskriver den komplette udviklingscyklus og de detaljerede aktiviteter forud for udviklingen
  • Forbliver den detaljerede projektplan stabil igennem projektforløbet
  • Leveres produkterne altid til tiden?
  • Er der tid til grundig test og dokumentation inden produktet leveres?
  • Er de anvendte teknologier grundigt forstået og stabile igennem projektforløbet og over produkternes levetid?
  • Er produktets arkitektur uforandret over produktets levetid?
  • Vil udviklingsteamet normalt designe og udvikle produkterne på samme måde flere gange?
  • Er udviklingsteamet og medarbejdernes respektive viden og færdigheder let udskiftelige?
Hvis svaret er ja til alle disse spørgsmål er den nødvendige stabilitet og forudsigelighed til stede, for fortsat at anvende den klassiske vandfaldsmodel til udvikling af nye produkter, men de fleste vil dog besvare flere af disse spørgsmål med et rungende NEJ! Mange udviklings-teams præsterer dårligt på trods af intens planlægning og projektstyring, fordi præcis planlægning af deres projekter simpelthen ikke er muligt. For disse udviklingsteams er det deres niveau af agilitet og deres evne til at udnytte usikkerhed – ikke undgå den – der er afgørende for deres succes.

Kerneprincipperne i agil udvikling

De agile udviklingsmetoder har sit udspring inden for software udvikling, hvor metoderne nyder stor udbredelse. Agil udvikling beskrives ud fra fire kerneværdier, som står i direkte modsætning til den klassiske vandfaldsudvikling:
  • Individualitet og samarbejde frem for processer og værktøjer
  • Fungerende software frem for omfattende dokumentation
  • Kundesamarbejde frem for kontraktforhandling
  • Respondere på forandring frem for blot at følge en plan
Kerneværdierne skal forstås således, at mens der fortsat er værdi i punkterne til højre, er det af større betydning, at punkterne til venstre fungerer optimalt. Individualitet og samarbejde. Software udvikling udføres af mennesker med støtte fra processer og værktøjer – ikke den anden vej rundt. Mange virksomheder kobler fejlagtigt succes til effektivt anlagte processer og værktøjer, og overser dermed den innovation og kreativitet der skabes af dygtige personer og velfungerende teams. Denne værdi opfordrer virksomheder til at se mennesker og deres samarbejde som de kritiske faktorer i opbygningen af succesfulde teams og innovative produkter. Fungerende software. En almindelig talemåde i agil software udvikling er, ”jeg forstår det, når jeg ser det”, hvilket betyder, at den største indsigt opnås ved at have produktet i hænderne frem for gennem planer og produkt dokumentation. Derfor opfordrer den agile metode til hurtigst muligt at udarbejde prototyper af produktet og så gradvist at tilføje funktionalitet igennem hele udviklingsforløbet. Fungerende prototyper giver udviklingsteamet, interessenter og kunder mulighed for regelmæssig at måle fremskridt og give feedback på, hvorvidt den udviklede funktionalitet er det der ønskes. Kundesamarbejde. For at opnå en høj grad af kundetilfredshed er man nødt til løbende at sikre, at udviklingsteamet har en klar forståelse af kundernes behov og ønsker. Den eneste praktiske måde at opnå dette er et tæt samarbejde med kunderne, da deres ønsker uundgåeligt udvikler sig over tid og ofte først bliver eksplicit udtrykt senere i udviklingsforløbet.
Agile metoder er ikke et spørgs-mål om blot at gennemføre morgenmøder, så de enkelte projektdeltagere kan give en status rapport. Det kan opfattes som tidsspilde og kontrol!
Respondere på forandring. For mange er det at kunne reagere hurtigt og effektivt på forandringer selve essensen af et agilt udviklingsteam. Software udvikling er en proces, hvor det er umuligt over en længere periode at forudsige og planlægge, hvorledes processen vil forløbe. I de fleste tilfælde bliver langtrækkende planer et forgæves forsøg på at minimere risici og opnå kontrol, men kundernes behov og krav, team dynamik og projektmålene vil ændre sig over tid og gøre planerne forældede. I stedet vil agile teams kunne absorbere forandringer ved at kombinere en detaljeret kortsigtet planlægning med langtrækkende estimater. I et agilt udviklingsprojekt vil analyse, udvikling, test og leverance typisk foregå parallelt hvor hver iteration i princippet betragtes som et lille selvstændigt projekt i projektet. Det betyder, at delkomponenter leveres så tidligt som muligt til slutbrugerne for at brugere og udviklingsteam hurtigt kan blive klogere på, hvad det færdige produkt skal indeholde. Feedback for hver leverance bruges således aktivt i planlægningen af de næste iterationer.

Fordele og udfordringer ved agil hardware udvikling

Siden starten af 1990’erne har agile udviklingsmetoder som Extreme Programming (XP), Scrum, Dynamic Systems Development Method (DSDM) og Lean Development vundet større og større indpas blandt software udviklingsteams verden over med stor succes, mens det er gået noget langsommere med at overføre disse metoder til produktudviklingsprojekter, der også omfatter elektronik og mekanik. Årsagen til dette er, at hardware udviklingsprojekter indeholder aktiviteter som indkøb, fremstilling af prototyper og test, der ikke umiddelbart ser ud til at være foreneligt med korte iterationer og hyppige leverancer, men de virksomheder der har indført agile principper i hardware udviklingen har opnået en lang række fordele:

Fleksibilitet / Agilitet

Den agile metode giver mulighed for løbende at foretage tilpasninger og ændringer baseret på brugernes ønsker og de teknologiske opdagelser igennem projektet. Den tætte interaktion med kunden sikrer, at den vigtigste funktionalitet udvikles først, og man verificerer tidligt, at principperne i designet passer til kundens faktiske ønsker. Der udvikles altså et produkt som markedet har brug for på leverance tidspunktet og ikke et produkt, som man gættede på, at der var brug for dengang idéen til projektet blev beskrevet. Den tætte involvering af kunder og øvrige interessenter som supply chain, salg og marketing sikrer en løbende forventningsafstemning og et højt informationsniveau, så projektets interessenter holdes ajour med funktionaliteten af det endelige produkt og har bedre mulighed for at planlægge deres aktiviteter som markedsføring og produkt launch.

Time to market

Det giver en væsentlig konkurrencemæssig fordel at være blandt de første på markedet med nye innovative produkter, og med agile udviklingsmetoder opnås en væsentlig effektivisering og dermed kortere udviklingsforløb. Dette skyldes, at den hårde fokusering på netop den væsentlige funktionalitet og kravet om hurtigt at kunne demonstrere funktionaliteten i en fysisk prototype giver en væsentligt højere udviklingshastighed – ikke bare for hardware udviklingen men også i integrationen mellem hardware og software.

Kvalitet

Et centralt princip i forbindelse med agil udvikling er at test skal være integreret med udviklingen gennem hele udviklingsforløbet, således at fejl findes og rettes så tidligt som muligt. Dette giver en signifikant gevinst, idet sandsynligheden for større fejl ved det endelige produkt stort set elimineres, og omkostningerne ved væsentligt re-design sent i udviklingsforløbet dermed minimeres. Den bedste måde at implementere tidlig integration og test er ved hyppig anvendelse af simulering, prototypeprint og evalueringsboards, hvor dele af kredsløbet med tilhørende firmware kan testes. Hermed får man tidligt afgjort, om principperne i designet holder. Ved at udvikle testudstyr, der automatisk kan teste hardwaren, kan man hurtigere gentage test ved nye hardware revisioner, og testopstillinger med tilhørende software kan typisk genbruges senere til certificeringstest, systemtest, HALT, debug af hardwaren og softwaren. Tiden brugt på udvikling af testopstillinger kommer derfor mange gange igen.

Samarbejde

Større organisationer har ofte opdelt de forskellige udviklingsteams efter faglige kompetencer i hardware teams, mechatronics teams og software teams, men med en fælles agil udviklingsmodel bliver det muligt at etablere tværfunktionelle feature teams, der fokuserer på udviklingen af specifikke features i samarbejde med relevante kunderepræsentanter. Dermed opnås langt bedre samarbejde mellem de forskellige fagdiscipliner og en løsning, der teknisk set er bedre integreret. For at få de forskellige udviklings discipliner til at arbejde sammen under en fælles agil metode, gælder det dog ikke blot om at få dem samlet til fælles stand up møde eller at påpege at hardware og mekanik udviklerne skal tænke iterativt. For at få den maksimale effekt skal der indarbejdes en fælles udviklingsmetode, som tager højde for de forskelle der er mellem de forskellige udviklings discipliner.

Medarbejder tilfredshed og engagement

Udviklingen foregår i selvorganiserende teams, hvilket giver den enkelte udvikler langt større ansvar og indflydelse på sit daglige arbejde. Udviklingsmodellen giver også bedre indsigt i baggrunden for hvorfor krav og specifikationerne er som de er, hvilket også giver et væsentligt større engagement og tilfredshed med arbejdet, selv om udviklerne typisk arbejder mere koncentreret og effektivt. Agile projekter kører med en meget synlig plan, meget gennemskueligt beslutningsforløb for design og implementering og synlig monitorering af fremdrift. Alle ved hvor i udviklingsforløbet udviklingsteamet er, og hvor effektivt det arbejder. Den store synlighed koblet med en kultur, hvor der stilles klare forventninger til teamets præstation giver et højt fokus på konstant at opnå resultater. Med den rette ledelse vil dette skabe en team ånd, hvor alle føler ansvar for teamets succes og bidrager med at hjælpe de øvrige teammedlemmer, når der opstår vanskelligheder.

Udfordringer

Agil hardwareudvikling minder på mange måder om agil softwareudvikling, og midlerne er de samme: Selvstyrende teams, tæt kundekontakt, tidlig integration, kontinuerlige tests og sprint-baseret udvikling med demonstrationer. Men der er også væsentlige forskelle, der stiller anderledes udfordringer til agile udviklingsteams der også omfatter elektronik og mekanik. Den primære forskel for udvikling af elektronik og mekanik er, at der eksisterer en højere omkostningsstruktur og længere turn-around tider for fremskaffelse af komponenter og fremstilling af prototyper, end der eksisterer for software. Dette betyder, at break-even punktet for hvornår det er mest rentabelt at tænke og designe i forhold til, hvornår det er mest rentabelt at bygge prototyper og eftervise omfatter en smule mere tænkning. For at opnå den nødvendige fleksibilitet og evne til at tilpasse sig de ændrede krav skal der etableres de nødvendige metoder, der gør det muligt at udvikle og prototype trinvis funktionalitet inden for hver iteration. Disse vil omfatte en højere grad af simulering, etablering af partnerskaber med leverandører der er specialiseret i rapid prototyping, samt udarbejdelse af et koncept til ud fra HW blokdiagrammet løbende at frigive kredsløbsblokke i hver iteration, så de senere kan blive integreret i det endelige design. En af de mest almindelige faldgruber, når man indfører agile metoder i HW udviklingen er, at man undlader at definere konkrete mål for hver iteration, men i stedet anvender upræcise definitioner på den ønskede fremdrift. Derved fjerner man muligheden for objektivt at vurdere, om en milepæle rent faktisk er nået eller ej, og målingen af projektets fremdrift bliver således ikke bedre, end hvis man havde anvendt traditionel projektstyring. I stedet bør man beskrive hver iteration ud fra de konkrete mål, der skal være opnået som f.eks. kritiske komponenter defineret, diagrammer klar til layout etc.

Vores erfaring med Agil hardware udvikling

Folkene bag og medarbejderne i mpeople, samt vores nære partnere på området, har gennem mange år arbejdet med agile udviklings metoder, og det også i andet end software udviklings siloen. Vores erfaring kommer fra mange års aktiv deltagen som projektdeltagere, projekt ledere, forandrings agenter projekt chefer, projekt ejere og som rådgivere til hvorledes de forskellige processer og procedurer omkring de agile metoder implementeres og tilpasses den enkelte organisations sær egenskaber – de er der altid og dem skal der tages højde for. Vi har også erfaring fra organisationer hvor det af kulturel og historiske årsager ikke var muligt at bibeholde en agil udviklings model i hardware afdelingen, der var simpelthen for mange for stærke medarbejdere som ledelsen ikke ville tvinge til at arbejde på en anden vis. Det sidste har givet os den erfaring, at ethvert projekt med at sikre en succesful implementering af agile metoder i andet end software afdelingen starter med et mindre forandrings projekt blandt hardware udviklerne. mpeople har bl.a. hjulpet flere kunder med, at indføre agile metoder i udviklingen af både hardware og software. Det har givet dem alle store produktivitetsforbedringer og en bedre kvalitet. Specielt har integration af software- og hardwareudvikling, tættere brugerkontakt og udbredt brug af løbende test givet signifikante og målbare forbedringer og resultater. Vi har selv kørt hurtige, agile udviklingsforløb og prototypeproduktion for kunder hvor først tidsplanen, senere kvaliteten var afgørende. Dette skift af fokus, for at tage risikoen ud af potentielt større projekter, understøtter agile metoder fint, også i udvikling af hardware. Indførelse af metoderne er dog ikke bare noget man gør – det er en forandring som skal ledes for at sikre at alle er med på den gode og rigtige måde. Senest har vi benyttet muligheden for at printe i 3D, en mulighed som er perfekt til HW udvikling ifm agile metoder, idet der kan printes i en formfaktor der er til at forholde sig til. mpeople er en medarbejderejet konsulentvirksomhed med primær fokus på udviklings- og ledelsesressourcer indenfor embedded apparat udvikling og de omkringliggende PC applikationer. Vores filosofi er ikke at blive de største, men konstant at sikre at vi til enhver tid er de bedste set med vores kunders øjne. På den måde sikrer vi os, at vi har det sjovt med at arbejde med det vi gør og bliver endnu bedre til det. Dette er en væsentlig del af vores virksomhedskultur. Ligeledes er det vores virksomhedsfilosofi ikke at opbygge en stor, tung og dyr administration, som det oftest ses i konsulent-branchen. Vi vil til enhver tid sikre os, at vi er en agil organisation, som udover at have de bedste konsulenter også kan levere til en konkurrencedygtig pris, en klar win – win situation.

Senest nyheder

Ekstra ScrumMaster certificeringskursus i København

Grundet den store interesse for vores ScrumMaster certificeringskurser afholder vi et ekstra kursus den 3. og 4. november på Islands Brygge i København. Kurset vil blive undervist af Certified Scrum Coach Bent Myllerup, der har over 10 års erfaring med agile metoder....