Agile Program Manager

En agile program manager holder sammen på noget, der er for stort til ét team.

Et program er en samling af teams, der leverer mod samme mål. Det kan være en ny selvbetjeningsløsning, en migrering til skyen eller et helt nyt kernesystem i en bank. Fem til tolv teams er almindeligt.

Det, der gør rollen svær, er dobbeltheden. Teamene arbejder agilt og planlægger få uger frem. Bestyrelsen, kunden eller ministeriet vil have en dato og et budget. Program manageren står midt imellem og skal kunne begge sprog.

Typiske opgaver

• Holde styr på afhængigheder mellem teams — den vigtigste enkeltopgave i rollen
• Eje programmets budget og følge forbrug mod fremdrift
• Planlægge og facilitere fælles planlægning, i SAFe kaldet PI planning, typisk hver ottende til tolvte uge
• Føre og håndtere risikolog og issue-log, og eskalere det, der ikke løses i teamene
• Rapportere til styregruppe, direktion og ofte til en ekstern kunde eller myndighed
• Koordinere releaseplaner, testmiljøer og go live-datoer på tværs
• Håndtere leverandører: kontrakter, leverancer, ændringsanmodninger og forsinkelser
• Sikre at business casen følges op, ikke bare skrives én gang
• Fjerne forhindringer, som scrum masterne ikke selv kan løse, fordi de kræver budget eller beslutning
• Bemande programmet: hvilke roller mangler, hvem lånes hvorfra

En almindelig arbejdsdag

Morgenen går ofte i overblik. Hvad står stille, hvem venter på hvem, og hvad skal eskaleres i dag.

En typisk formiddag har to eller tre koordineringsmøder. Et team kan ikke komme videre, før et andet leverer en snitflade. Din opgave er at få de to teams til at aftale en dato, ikke at bestemme løsningen.

Midt på dagen kan der ligge en leverandørsamtale om en forsinkelse, eller en snak med en arkitekt om, hvorvidt en teknisk beslutning rammer tre andre teams.

Om eftermiddagen skriver du. Statusrapport, risikolog, opdaterede milepæle og materiale til styregruppen. Meget af rollen er skriftlig kommunikation, der skal kunne læses af folk uden teknisk baggrund.

Op mod PI planning, større releases og kvartalsrapportering fylder forberedelse næsten alt.

Det svære i jobbet

Du har ansvar for leverancen uden at have teamene som medarbejdere. Du kan ikke pålægge nogen noget, kun aftale.

Du skal også rapportere ærligt. Presset for at farve en status gul i stedet for rød er reelt, og det er den fælde, der ødelægger flest programmer. Røde statusser tidligt er billigere end sandheden sent.

Dertil kommer forventningskonflikten. Bliver du målt på en fast dato og et fast scope, er der ikke meget agilt tilbage, uanset hvad rollen hedder.

Og du bliver aldrig færdig med afhængigheder. Hver gang én er løst, er der opstået to nye.

Hvem har rollen

Stillingen findes i organisationer med mange udviklingsteams og store leverancer.

Brancherne er især finans og pension, hvor Danske Bank, Nykredit, Nordea, PFA, Danica og Bankdata kører store programmer. Derudover telekommunikation, energi og forsyning, medicinal med digitale afdelinger, shipping og transport samt de større softwarevirksomheder.

Den offentlige sektor er en tung arbejdsgiver. Styrelser, regionerne og de største kommuner kører flerårige it-programmer, og SAFe er meget udbredt her. Fejlslagne offentlige it-programmer har været fast stof i pressen i årtier, og Rigsrevisionen undersøger dem jævnligt.

Konsulenthuse som Netcompany, KMD, Systematic, Accenture, Deloitte og Implement Consulting Group leverer også program managers ind i kundeprogrammer.

En sondring, der er værd at kende: i SAFe hedder den nærmeste rolle Release Train Engineer, RTE. Mange danske opslag bruger de to titler om det samme, men en RTE er mere procesfokuseret, mens en program manager typisk også ejer budget og leverandører.

Hvilken lovgivning dækker denne rolle?

Større offentlige it-programmer er omfattet af statens it-projektmodel og skal risikovurderes af Statens It-råd under Digitaliseringsstyrelsen, som følger projekter over en vis beløbsgrænse og offentliggør statusvurderinger. Løsninger, der udvikles til offentlige myndigheder, skal desuden leve op til webtilgængelighedsloven og WCAG-standarden. Behandles personoplysninger i programmet, gælder EU's databeskyttelsesforordning, GDPR, som kræver databeskyttelse gennem design og ofte en konsekvensanalyse, DPIA, før udvikling går i gang — Datatilsynet fører tilsyn. I finanssektoren stiller EU's DORA-forordning krav til it-modstandsdygtighed og til styring af it-leverandører, og Finanstilsynet fører tilsyn. Er virksomheden omfattet af EU's NIS2-direktiv, skal sikkerhedskrav og leverandørstyring desuden være indbygget i programmets leverancer fra start.

Der findes ingen uddannelse til agile program manager. Man kommer til rollen efter flere år med projekt- eller teamansvar, og der er ingen genvej.

De typiske uddannelsesveje

• Cand.it. eller cand.merc.it., 5 år
• Cand.polyt. i software, digitalisering eller teknisk ledelse, 5 år
• Cand.merc. i økonomistyring eller strategi, 5 år, som er stærk til budget- og business case-delen
• Datamatiker, 2,5 år, eller professionsbachelor i softwareudvikling, hvis man kommer fra udviklersiden
• Professionsbachelor i økonomi og informationsteknologi, 3,5 år
• Cand.scient.pol. eller cand.soc., hvilket er almindeligt i offentlige programmer

Adgangskravene til erhvervsakademi- og professionsbacheloruddannelserne er normalt en gymnasial eksamen eller en relevant erhvervsuddannelse. De aktuelle krav for den enkelte uddannelse fremgår af Uddannelsesguiden fra Uddannelses- og Forskningsministeriet.

Certificeringer

Dette er et certificeringstungt felt, og flere efterspørges direkte i danske stillingsopslag og i offentlige udbud.

• SAFe Release Train Engineer, RTE, som er den mest direkte match, hvis organisationen kører SAFe
• SAFe Program Consultant, SPC, hvis man også skal indføre rammeværket
• MSP, Managing Successful Programmes, som er standarden for klassisk programledelse og bruges meget i det offentlige
• PRINCE2 og PRINCE2 Agile, som ses i næsten alle danske offentlige udbud
• IPMA-certificering gennem Dansk Projektledelse, den danske forening på området
• PMI-ACP eller PMP fra Project Management Institute, mest relevant i internationale koncerner
• PSM I eller II fra Scrum.org, hvis man kommer uden agil baggrund

Certifikaterne åbner døre, især i udbud hvor de er et krav i tilbudsmaterialet. De erstatter ikke erfaring med at have stået i et program, der var forsinket.

Alternative veje ind

• Fra projektledelse. Den mest almindelige vej. Man kan styring, budget og interessenter, men skal aflære at planlægge to år frem i detaljer
• Fra scrum master eller agil coach. Man kender teamene og processen, men skal lære budget, kontrakter og styregrupperapportering
• Fra tech lead eller arkitekt. Stærk teknisk troværdighed og god forståelse for afhængigheder, men skal opbygge ledelses- og økonomidelen
• Fra product owner eller product management. Kender prioritering og interessenter i forvejen
• Fra konsulenthus, hvor man har ledt kundeprogrammer og derfor er vant til leverandørrollen

Karriereveje videre

Den typiske rute er senior program manager eller programdirektør på de største programmer. Andre veje er portefølje- eller PMO-chef, udviklingschef, it-direktør eller CIO. En tredje mulighed er transformationsrådgivning i et konsulenthus, hvor erfaringen sælges direkte. Nogle går til leverandørsiden som delivery director.

Realistisk tidshorisont

Regn med otte til femten år fra første projekt- eller udviklingsjob. Du skal have kørt mindst ét program hele vejen til levering, helst også ét der gik skævt.

Den erfaring er den vigtigste. Man lærer ikke afhængighedsstyring af et kursus.

Hvis du skal hyre

Bed kandidaten tegne afhængighederne i et program, hun har kørt. Kan hun ikke det på en tavle, har hun ikke haft ansvaret.

Spørg til et program, der blev forsinket, hvornår hun sagde det højt, og hvad reaktionen var. Svaret afslører, om hun tør rapportere rødt. Spørg også, hvordan hun håndterer en styregruppe, der kræver fast dato og fast scope samtidig. Og afklar mandatet i opslaget: ejer personen budget og leverandører, eller er det ren koordinering? De to jobs kræver vidt forskellige kandidater.

Program- og porteføljeoverblik

Jira er standarden i teamene, i Microsoft-tunge organisationer Azure DevOps. På programniveau bruges Jira Align, Azure DevOps' porteføljemoduler, Planview eller Smartsheet til at se afhængigheder og fremdrift på tværs.

Mange store danske programmer kører dog stadig afhængighedsstyringen i Excel ved siden af. Det er ikke elegant, men det virker, og det er ærligt at vide.

Microsoft Project bruges fortsat til milepælsplaner, især hvor en styregruppe eller en kontrakt kræver datoer.

Facilitering og planlægning

Miro og Mural bruges til fælles planlægning, afhængighedskort og risikoworkshops. Ved PI planning i SAFe er programboardet med snore mellem teams i praksis flyttet ind i Miro for distribuerede teams. Møder afholdes i Teams eller Zoom.

Rapportering

Statusrapporter, risikolog og issue-log holdes i Confluence, SharePoint eller Excel. Til styregruppen laves materialet i PowerPoint, typisk med et fast sæt slides hver gang. Power BI bruges til at vise fremdrift, forbrug og leveringstakt over tid.

De nøgletal, der reelt bruges, er fremdrift mod milepæle, budgetforbrug mod plan, antal åbne afhængigheder, gennemløbstid og hvor ofte der leveres til produktion.

Test og release

Testforløb styres i Xray, Zephyr eller Azure Test Plans. Releaseplaner og miljøbookninger koordineres ofte manuelt, fordi flere teams skal dele de samme testmiljøer. Driftsovervågning i Grafana, Datadog eller Application Insights bruges efter release.

Leverandør og økonomi

Kontrakter, ændringsanmodninger og fakturaer håndteres i virksomhedens økonomisystem, ofte SAP, Business Central eller Oracle. I offentlige programmer er udbudsmateriale og kontraktstyring en fast del af arbejdet, og K02- og K03-kontrakterne er de standarder, der oftest bruges til statslige it-anskaffelser.

Krav i leverancen

Sikkerhedskrav, tilgængelighed og databeskyttelse skal ligge i planen fra start. GDPR kræver databeskyttelse gennem design, offentlige løsninger skal følge webtilgængelighedsloven og WCAG, og i finanssektoren stiller DORA krav til it-modstandsdygtighed. Kommer de krav først ind til sidst, koster de langt mere.