Når du har læst dette blogindlæg, har du fået indblik i mit syn på sikring af organisations- og forretningsudvikling i moderne organisationer gennem agil forretningsudvikling.
”A potential shippable product” er outcomet af ét ”sprints” udvikling i alle agile projekter (iflg. SCRUM-terminologien). ”A potential shippable produkt” dækker over leverancen af et produkt, en brugbar del af et produkt, en procesforbedring, en ny funktionalitet, fjernet en besværlig arbejdsproces etc., som kan tages i brug efter release. Ved hele tiden at skubbe brugbar nyudvikling og eventuelle ændringer og tilpasninger igennem et sprint, sørger man for kontinuerligt at skabe værdi i forretningen og organisationen, som hele tiden bliver klogere og mere konkurrencedygtig. I min optik er det ikke blot agil udvikling – men agil forretningsudvikling. Og det er grunden til, at jeg altid vil stemme for at udviklingsprojekter i moderne virksomheder skal gribes an som agile projekter.
Hvordan griber man det så an i praksis – og hvad er det vigtige i en sådan proces?
Man begynder med at afgrænse et produkt, et forretningsområde eller et andet udvalgt område, hvor man ønsker at skabe udvikling. Dernæst udpeger man en person (en forretningsejer/product owner) som har ansvaret for at sikre den højest mulige værdi for alle stakeholders samt, ikke mindst, er en der har indsigt i hvad der ønskes udviklet. Denne person udarbejder en backlog af ønsker, som alle har et formål og kan beskrives som et ”Potential shippable product”.
Til udvikling og implementering af disse ønsker skal man sikre sig et committed team, der indeholder alle de fornødne kompetencer til at udvikle forretningsejerens ”potential shipable product”. Det ville fx i en it-udviklingskontekst betyde kompetencer fra arkitektur til implementering.
Når teamet er på plads, er det tid til at planlægge et sprint. Først besluttes længden på sprintet, og herefter opprioriterer forretningsejeren de opgaver i backloggen, der vil give mest værdi til forretningen/produktet. På et sprint-planlægningsmøde beslutter forretningsejeren og teamet, hvor mange af disse opgaver man kan nå at udvikle og implementere i det valgte tidsrum – og derefter går udviklingsprocessen i gang. En proces, hvor forretningen/organisationen ved sprintets afslutning har udviklet de produkter, processer, tilpasninger (shippable products) etc., som forventes at give størst værdi for forretningen – hvilket i min optik er kernen i agil forretningsudvikling.
Hvis denne proces gentages igen og igen i mange iterationer vil man hele tiden tilføje værdi til organisationen og forretningen. Man prioriterer hele tiden, hvad der i en given situation vil kunne give mest værdi, og man sikrer hele tiden, at man tilpasser den agile udviklingsproces til netop den situation man befinder sig i på det givne tidspunkt.
Kun ved hele tiden at fokusere på formålet med al udvikling, prioritere det imellem andre ønsker og sikre korrekt og brugbar implementering, styrker man forretningen/organisationen og gør den mere konkurrencedygtig. Derfor er agil forretningsudvikling måden at opnå den største værdiskabelse på i en foranderlig verden.
Jeg håber, at disse tanker kan være brugbare for dig, når du og din organisation står over for jeres næste projekter. Og jeg håber ligeledes, at det kan sætte gang i en debat om, hvordan I sikrer den optimale udvikling internt i jeres organisation.
Leave a Reply