Projekter i en agil organisation – sådan lykkes det!

Overvejer I at køre projekter i jeres agile organisation ? Så er der særlige faldgruber, I skal være opmærksomme på i jeres tilgang. Bliv klogere på dem, og hvordan I undgår dem, her.

Traditionelle projektorganisationer søger i stigende grad mod agile metoder og tilgange. Men selv efter en agil transformation har mange organisationer – af forskellige årsager – stadig behov for at køre projekter. Det kan ende godt, men det kan bestemt også få katastrofale følger, hvis ikke I som organisation forstår at udnytte og forstå begge verdener, så det giver mening – både for opgaverne selv, men også  medarbejdere og organisationen som hele. Derfor får du her 3 huskeregler til, hvordan I undgår at dødsdømme jeres projekter, når I går agilt:  

• Projekter og den agile organisation skal have fælles prioriteringer
• Find en projektleder med gode agile kompetencer
• Hold fingrene fra at ændre i det eksisterende agile setup

Hold fingrene fra det agile setup

Lad os tage det sidste først, nemlig ”hold fingrene fra at ændre i det agile setup”. Har I etableret et agilt setup, så hold fast i den beslutning. Vær tro mod at agile setups, f.eks. scrum eller SAFe bygger på stabile teams. Netop dette er et kernelement i at arbejde agilt. Derfor nytter det ikke, at projekter lige skal låne nøgleressourcer fra ellers velfungerende stabile agile teams. Gør det ikke, med mindre I ønsker at reducere værdien og leveranceevnen fra de agile setups. Fasttømrede teams, som over tid og gennem læring får roller og opgavefordelinger på plads, bruger mindre tid på at forstå hinanden, afstemme og koordinere, og derved opstår et godt grundlag for high performance teams. Så lad projekter være projekter, og udnyt så al det gode fra den kørende agile motor, som netop er etableret. Pil ikke ved den agile motor – brug den til at komme effektivt og sikkert frem!

Brug det agile setup som projekt-underleverandør

Når opgaven bedst egner sig til at blive håndteret som et projekt (f.eks. fordi der er særlige rapporterings- og styringskrav, interface til traditionelle programmer, flere leverandører til den samlet leverance etc.) så organiser dit projekt til, at kunne leverandørstyre og til eventuelt at kunne specificere, samle, regressionsteste og aflevere leverancerne. Tænk i at bemande projektet med færrest mulige ressourcer. De mest nødvendige projektdyder skal overholdes. Hverken mere eller mindre.

Projekterne skal opfatte organisationens ART´er/teams som underleverandører – på lige fod med eksterne leverandører. Dvs. at projektet i hovedtræk afleverer sine leverancebehov til underleverandøren; ART´en/teamet og som udgangspunkt styrer og kommunikerer med ART´en/teamet som var det en traditionel underleverandør. Dermed lader man projektet være projekt og lader samtidig den agile organisation arbejde uændret efter de agile principper. Samtidig fastholder organisationen værdiskabelsen fra de agile velsmurte leverancemotorer. Med andre ord: Behold det gode fra projekt-setuppet, og behold det gode fra det agile setup. Win-win!

Skal projektlederen så erstattes med en contract manager?

Nej, da. Der er stadig brug for en kompetent projektleder, som kan sin metier. Men projektlederen her skal kunne forstå at agere både i den traditionelle projektverden og i den agile verden og skal formå at kunne interessenthåndtere i begge verdener.

Det er helt essentielt, at projektet anvender og udnytter det agile setup, som det er implementeret. Dvs. projektet må ikke afkræve det agile setup at levere f.eks. traditionelle styringsparametre, men projektet skal kunne udnytte og anvende de agile metoder, værktøjer og rapporter, der som ”standard” kommer fra den agilt arbejdende organisation og dermed udnytte den eksisterende agile leverancemotor.

Projektlederen som Product Owner

Projektet skal altså være i stand til at spille ind og forstå den agile organisations arbejdsform og skal samtidigt kunne sikre en sund projektmæssig styring og håndtering. Eksempelvis skal projektet kunne aflevere sine krav i den agile kontekst – typisk som en epic eller en feature – og projektet skal samtidig kunne agere Product Owner for ART´ernes leverancer, som er relateret til projektet. Det betyder, at projektet skal kunne modtage demoer, kunne koordinere og sikre kundens feedbacks på disse demoer.

På samme måde kan projektet ikke forvente at få traditionelle planer og statusrapporteringer fra ART´erne, men derimod oversigter/inputs som PI- og sprintplaner, backlogs, færdiggørelser af stories etc. Projektet må med baggrund i sådanne informationer opbygge – efter behov – en traditionel projektrapportering til projektets styregruppe. Det er altså helt afgørende, at projektlederen har en robust viden og forståelse for både traditionel projektstyring og det agile setup samt er i stand til at kunne oversætte agile termer til projekttermer og vice versa.

Uden en fælles prioritering er der ingen prioritering – kun en organisation i utakt

Hvis de to verdner (og porteføljer) skal kunne fungere sammen, er det vigtigt at samstemme porteføljeprioriteringen. Dvs. projekter og den agile organisation skal have den samme prioritering. Kan organisationen ikke skabe denne fælles prioritering, går organisationen ikke i takt. Det er som regel ikke kønt. Der opstår ofte uro i geleddet med slåskampe om ressourcer, prioriteringerne og i helt taget dårligere muligheder for at skabe resultater.

Forud for opstart af projektet er det derfor afgørende for leverance-succes – i projektet og i det agile setup – at projektet er porteføljeprioriteret både på projektniveau og på det agile niveau (epics prioriteret). Dette for at sikre leverance-alignment mellem projektets milepæle og ART´ernes PI-planer. Dvs. projektets milepæle skal indpasses og prioriteres ind i ART´ernes PI-planer. Det sikres ved at projektlederen bl.a. deltager i PI-plannings ceremonier og ved at ART-ledelsen har et ophæng og et commitment i projektet.

ART-ledelse som styregruppe

Det anbefales derfor, at f.eks. den mest leverende ART udgør enten projektstyregruppen eller at en repræsentant fra ART-ledelsen varetager seniorleverandør-rollen i projektets styregruppe. Dette for at sikre en fælles interessehåndtering for projektet, dens fremdrift og dens succeskriterier. Det er altså dennes ansvar at sikre, at det agile setup følger organisationens prioritering og at projektets og det agile setups opgaver samlet bliver prioriteret derefter.