Forstå hvordan Incident Management og Release Management passer ind i arbejdsrammen ved agil udvikling og giver samme kontante fordele takket være flere evalueringer undervejs, kortere udviklingscyklus og højere kvalitet Læs mere her: bit.ly/softwaredagservices3

1. Få fordelene ved
agil udvikling i IT-porteføljen
Annette Klink Dalgaard
Senior Certified Project Manager, IBM Agile coach

2. Agil IT-portefølje forvaltning
• Agil udvikling er mere end blot en metode til
projektudvikling og kan også bruges som arbejdsramme
til vedligeholdelse af produktporteføljen.
• Med agile metoder arbejder man for minimering af
risikoen og maksimering af produktiviteten ved at
udvikle gennem en kort iterativ proces.
• Agile metoder har en dynamisk planlægningsproces,
således at forekommer der uundgåelige ændringer under
udviklingsprocessen, kan disse indarbejdes i produktet.
Traditionelle, ikke-agile metoder, har en statisk
planlægningsproces, der forhindrer forandring og som
ofte skaber konflikter mellem den statiske plan og den
dynamiske virkelighed.

3. Iterationer sikrer dynamisk planlægning
Success zone
Planlagt mål
Planlagt vej
Start
Øget viden
Aktuel vej
Efterhånden som større
viden opnås bruges
iterationer til at sikre at Aktuelt mål
projektet opnår det
udvidede mål

4. Med agile praktikker og teknikker...
• Er der fokus på kundens forretningsbehov og
udviklingen kan styres efter leverancer med det
største investeringsafkast.
• Giver mulighed for at bruge fundamental
funktionalitet af en applikation og sætte den i
produktion tidligere og få afkast af den tidligere
• scope kan ændres med minimal bureaukrati
• risici associerede med leverancer og tidsplaner
identificeres og mitigeres mere effektivt

5. Agil udvikling med SCRUM
Scrum - standard
Branchen
anbefaler
2-4 ugers sprint
2 uger
potentially shippable
product increment
Bemærk:
• Ordene sprint og iteration betyder det samme
• Scrum er efterhånden førende indenfor industrien

6. Scrum som det agile rammeværk
• SCRUM er ikke raketvidenskab
–Det er et simpelt rammeværk
–Blokkere viser sig tydeligt
–Ved at følge simple (IKKE nemme!!!)
regler og processer viser problemerne
sig ved at dukke op på ”overfladen”

7. Scrum er lommelygten som
fremhæver problemerne –
Det løser dem ikke!

8. Agil portefølje forvaltning
i IBM GBS/AMS
• Annette Klink Dalgaard, IBM senior certificeret projektleder,
Certificeret scrummaster, Agil coach
• Min praktiske erfaring kommer fra IBM Payments Systems (PS)
– Verdensomspændende system til clearing af kredit kort og
elektroniske betalinger
– PS interfacer med en del bank-partnere: Chase, Citibank,
American Express, First Data, Certegy, Wells Fargo,
Deutsche Bank, Barclays, Diners såvel som Paypal.
• IBM Payment System har brugt agil udvikling siden 2006. Jeg
startede som projektleder, blev senere program manager og i
dag vedligeholdes også porteføljen problemfrit med agil
udvikling

9. Payment systems realiserede fordele
med Agil udvikling
• Agil udv. gør problemer/blokkere mere synlige
• Demonstrerer hurtigere resultater
– Tidlige målinger viste forbedringer i produktivitet på omkring 50%
• Fokus på opgaver som er mest vigtige for forretningen
– Kunden er omdrejningspunkt for alle beslutninger
vedrørende prioritet af krav
• Hurtigere udviklings cyklus
– Tilføje en ny connector (online og/eller batch)
• Siden IBM har startet med hvad de kalder ”co.sourcing” (agile
udvikling, genbrug, komponentbaseret udvikling etc...) vi har
reduceret tiden det tager at udvikle en connector til at tage mindre
end 25% af den oprindelige udviklingstid

10. Realiserede fordele...
• Bedre team motivation
– Globale ressourcer bliver længere i jobbet (tidligere max.
18 måneder, nu flere år)
– Bedre samarbejde mellem danske og globale ressourcer
– ”Penetration procent” i udviklingsteams er langt over 50%
• Hyppigere leverancer
– Projekter/releases havde tidligere en gennemsnitlig
længde på 12-18 måneder, nu er den 3-4 måneder
• Indbygget kvalitet
– Automatisk og hyppig test som sikrer udvikling og afvikling
af end user test cases samtidigt med koden

11. IT-portefølje i scrum rammeværk
Daglige scrum
møder –
samme tid,
samme sted
hver dag
Krav, udvalgt
Alle krav Krav, udvalgt til til et sprint
en release
2 uger
Product Backlog Release Backlog potentially shippable
product increment

12. Grafisk gengivelse af release-modellen for PS
Forretningsprojekt 1
Forretningsprojekt 2
Forretningsprojekt 3
Vedligeholdelsesopgaver
Projektstart omfatter opgaver som f.eks.allokering af projekt team-medlemmer
Start op Hvert sprint (2-4 uger) afsluttes med en Demo
Sprint 1, Sprint 2, Sprint 3... Accept Test Udrul
Release 1 Koncept
Identificerede fejl addresseres i sprint i
den efterfølgende release
Koncept Sprint 1, Sprint 2, Sprint 3... Accept Test Udrul
Release 2 Overordnet
planlægning og
arkitekturspor
Overgang til næste release Koncept Sprint 1, Sprint 2, Sprint 3... Accept Test Udrul
Release 3
Tid

13. Release backlog kræver valg
Ved projekter skal hvert eneste
backlog item analyseres for:
•Kundens fordele af et backlog item
•Hvad giver forretningen det største
investeringsafkast?
•Hvad er vigtigst for kundens forretning?
•Hvilke (tekniske) beslutninger er
nødvendige for produktets stabilitet og
skalerbarhed?
•Hvordan passer det med releasens vision?

14. Release backlog kræver valg...
For portefølje vedligehold:
•Incident management håndteres af driften
•Problem management – buffer tid er reserveret i sprintet
• Buffer-tiden nedskrives med tid forbrugt til
undersøgelse/analyse af incidenten
• Et backlog item laves til den detaljerede
design/udvikling/test når analysen er færdig
• Beslutning vedrørende prioriteten for de(n) nye
backlog item(s) I forhold til de eksisterende
•Hvis den tid, der er reserveret, overskrides – kan
sprintet afbrydes og gen-planægges eller der må
accepteres at fjerne fra scope – et aktivt valg skal tages

15. Produktejer – den praktiske implementering
• Vedligehold
– I forretningen udpeges en produktejer for hver
vedligeholdelsesopgave – en produktejer kan have flere opgaver
• Projekter
– Hvert projekt tildeles en produkt-ejer (denne person er ofte
forretningens projektleder)
• Produktejeren og ansvar
– I den agile vedligeholdelsesorganisation har ansvaret for koordinering
af krav mellem projekter og vedligehold historisk flyttet sig fra
udviklingsorganisationen til forretningen selv, men for at sikre
koordinering og prioritering af kravene faciliterer
udviklingsorganisationen kravsmøder hver 14. dag, hvor kravene
diskuteres – alle produktejere er tilgængelige sammen med
arktitekterne og udviklingsprojektleder.

16. Annette Klink Dalgaard – annettej@dk.ibm.com