Niels Bering Larsen bloghoved

Agil forretningsudvikling

Af 5

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.

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Bent Myllerup

Tak for et godt blogindlæg, Niels.

Jeg er helt enig med dig i at det er vigtigt at lægge vægt på agil forretningsudvikling fordi dette skaber en øget opmærksomhed på værdiskabelse fremfor blot effektivitet. Med Scrum opnår vi at teamet er i stand til at producere mere ved en normal arbejdsindsats, men udbyttet af denne forøgede produktivitet kan være ligemeget hvis ikke også der er de rigtige resultater som teamet producerer. Et stærkt produktejerskab er derfor vigtigt sammen med et godt samarbejde mellem forretning og udvikling. Agile er mere end blot noget som de gør i udviklingsafdelingen.

Netop samarbejdet mellem forretning og udvikling er også en vigtig del i forbindelse med etablering af Product Backlog. Det er rigtigt at Product Owner'en er ansvarlig for backloggen, men den bør udarbejdes gennem samarbejde med interessenter og team. Derved sikres det at de rette informationer er til stede, samt at teamet kan forpligte sig fordi de har haft indflydelse og fået en dybere indsigt i forretningbehovene. Ofte ser jeg også at disse behov bliver indfriet med lavere omkostninger fordi man gennem samarbejdet omkring udarbejdelsen af backloggen finder alternativer som ingen af partnerne selvstændigt kunne have fundet på.

Endeligt er det vigtigt at huske på at backloggen er et levende dokument som løbende bliver opdateret under projektets gennemførsel, efterhånden som vi bliver klogere. Værdiskabelsen kommer ved at kunden til slut får det som han har behov for fremfor (når det går bedst med traditionelle metoder) dét som vi troede var behovet da projektet startede.

  • 0
  • 0
#2 Stefan Bertram

Tak for indlæget, Niels.

Ja, SCRUM terminologien arbejder med udviklingsprocessen af produkt/services. Det er en måde at drive sine projekter på.

Når overskriften lyder "forretningsudvikling" læser jeg: Hvad skal vores forretning beskæftige sig med, og hvordan udvikler vi vores forretning med produkter der gør os i stand til at løse verdens elendighed og/eller tjene styrtende med penge? Jeg tænker på ord som entreprenørskab og innovation. Er helt enig i at man også kan bruge agile metoder her, men det springende punkt er "kontinuerligt at skabe værdi i forretningen og organisationen" – hvad er det som skaber værdi?

Mange vil i dag sige: Tal med kunderne.

Til dem med interesse for mere: Bogen "The Lean Startup" har ét bud: Tilbud et "minimum viable product", test om kunder er villige til at betale for det, og mål nu i forhold til tidligere fx: - Hvor mange nye kunder køber? - Hvor mange køber 2. gang? - Hvor mange fortæller deres venner og får dem til at købe?

Altså i princippet en simpel læringscirkel, hvor man (agilt): 1. Tilbyder et minimalt produkt (ikke et avanceret færdigt produkt, en demo kan næsten gøre det) 2. Måler impact (fx betyder ændringen overhovedet noget for kunderne?) 3. Tuning af produktet, eller forkastelse og fuldstændig ændring.

  • 0
  • 0
#3 Hans Peter Bech

Det er den vej vi skal!

Siden Eric Reis udgav "The lean startup i 2011", er der kommet mange bidrag til denne skole. Steve Blank har udviklet sin "Customer Discovery" tilgang yderligere og har inkluderet Osterwalder's business model framework i sin seneste bog "The Startup Owners' Manual" (som bestemt ikke kun er for startups!). Google's Alberto Savoia forsøger med sin "pretotyping" metode at få foretaget et "sanity tjek" inden man har kodet en linje.

Steve Blank kører for tiden et spændende projekt på UCSF indenfor life sciences. Projektet er godt dokumenteret her: http://steveblank.com/category/national-science-foundation/

(Hvis man som forretningsudvikler ikke kender Steve Blank og Eric Reis, bør man have et rap over fingrene :-))

  • 0
  • 0
#4 Niels Bering Larsen

Tak for de spændende input på mit blogindlæg

Det centrale i den agile tilgangsvinkel til forretningsudvikling er netop de iterative og samarbejdende processer. Processer der løbende styres ud fra ønsket om den højeste værdiskabelse samt inddragelse af viden fra de forskellige perspektiver der deltager i projektet/processen.

Om det er en startup (som behandles i Lean StartUp) ellen nye produkter/services i en eksisterende organisation er for mig underordnet, blot man i udviklingsprocessen søger for at have en proces der hele tiden implementerer forbedringer samt evaluerer om der er noget der kan forbedres endnu mere.

Dette skal dog ikke forstås som om, at man ikke kan lave en overordnet strategi hvor man udsætter klar mål og tidspunkter på hvornår man gerne vil være på et nyt stadie. Gevinsten ved at lade sin forretningsudvikling implementere agilt er, at man arbejder med de aktiviteter der giver højst værdi i den første række af sprints - Fordelen er så, at man oftest opnår de vigtige strategiske initiativer tidligere i forløbet. Hvis verden skulle være ændret efter indfrielsen af de første strategiske initiativer - så kan man åbent lade strategien følge med, og man undgår at strategien falder i baggrunden (og ud af bevistheden), men at man aktivt tager stilling til i hvilken retning det skal gå nu. En vision som en del af strategien for et agilt forretningsudviklingsprojekt er derfor vigtig, da den kan guide beslutninger og retning for den videre implementering af projektet.

En strategi og vision inden for et nyt produktområde kommer selvfølgelig bedst til verden ved tæt samarbejde imellem brugere, kunder, udviklingsteamet samt ikke mindst Product Owneren. PO'en har så ansvaret for at skabe alignment imellem interessenterne samt tage beslutning af hvad det endelig resultat skal blive.

  • 0
  • 0
#5 Jette Sønderskov

Tak for dit spændende indlæg Niels Bering Larsen, om agil forretningsudvikling. Agil forretningsudvikling er en meget velegnet metode til mange forretningsudviklingsprojekter. Men desværre ikke i alle tilfælde, som du ellers anbefaler. Der findes en række forskellige værktøjer, du kan bruge til at vurdere, hvornår du skal bruge agil frem for traditionelle metoder. Jeg kan bl.a. henvise dig til Cockburns "Iron-triangle model", Staceys matrix og Boehm &Turners "søstjerne-model". Det er alle værktøjer, som kan bruges til at afklare hvilke forretningsudviklingsprojekter, man med fordel kan køre som agile. Du finder dem bl.a. i bogen "I am agile" af Claus Nielsen (2013).

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen