Mange teams kæmper med at levere værdi i vertikale slices af et produkt, som er under opbygning. I den fase af et udviklingsforløb, hvor vi har en god ide om hvad der skal bygges, men vi er langt fra at have noget færdigt. Typisk fordi vi har en masse grundlæggende teknik vi skal have på plads først. Denne fase kalder jeg “opbygningsfasen”. Det er i opbygningsfasen, at det kan føles nærmest umuligt at levere værdig tidligt.
Som en bruger vil jeg have det samme som jeg havde før med det formål at jeg kan komme videre med mit liv. Og så ringer i bare når i er færdige.
Opbygningsfasen ser jeg typisk i starten af større udviklingsprojekter, hvor udvikling starter fra scratch, og der skal bygges meget, inden produktet kan tages i brug. Det kan eksempelvis være, når vi skal bygge et nyt website, som skal erstatte et eksisterende. Vi kan ikke tage det gamle site ud af drift og lancere det nye, inden det er færdigbygget. Hvem gider have et halvt nyt website, når vi havde et helt gammelt i forvejen?
Hvilken værdi skulle vi dog kunne levere løbende, imens vi bygger en erstatning for noget, vi har i forvejen? Det agile manifest lader til at ignorere, at der skulle være nogen problemer i, at gå igennem en opbygningsfase. Her ere det første princip i manifestet:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
https://agilemanifesto.org/principles.html
En måde at komme omkring denne udfordring er, at forstå værdi som mere end noget slutbrugeren kan få konkret glæde af. Jeg deler værdi op i to grove kategorier, “forretningsværdi” og “empirisk værdi”.
Forretningsværdi
Den type af værdi som vi typisk arbejder på at levere er “forretningsværdi”. Hvad forretningsværdi nærmere er for dig, er meget afhængig af din forretningskontekst. Som Product Owner bør du have et godt begreb om, hvad forretningsværdi er for dig og dit team.
Klassiske eksempler på forretningsværdi i en salgsorganisation kan være “flere ordrer”, “større provenu”, “øget bundlinje”, “nye kunder”, “flere tilbagevende kunder”, “større markedsandel” mv.
Hvad end vi laver med vores teams, er det oftest med det formål, at kunne komme til at – eller blive ved med at kunne – levere forretningsværdi.
Empirisk værdi
I opbygningsfasen af et udviklingsforløb er det svært at levere forretningsværdi. Det er svært at få forretningsværdi ud af en ide, som slet ikke er begyndt at blive implementeret endnu.
Det er i denne fase af udviklingen, at vi typisk kommer til at smide vores agile principper ud. Vi forlænger sprintet, dropper Sprint Review og går i værkstedet og bygger løs, indtil vi har en version-ét-komma-nul. Og først derefter begynder vi at iterere over produktet, viser det frem til vores stakeholders og får nogle ægte brugere til at bruge det vi har lavet.
I opbygningsfasen må vi derfor jage en anden værdi, imens vi bygger på vores ide: Empiri.
With empirical process control we don’t fix the scope of the product nor the processes of how to build it. Instead in short cycles we create a small shippable slice of the product, inspect what and how we create it, and adapt the product and the way we build it, with built-in mechanisms for transparency to enable clear inspection.
https://less.works/less/principles/empirical-process-control
Vi skal bevare en eksperimenterende tilgang selv i opbygningsfasen, hvor vi har travlt med at bygge noget der overhovedet virker. Det arbejde vi laver – også i opbygningsfasen – baserer sig på en hel masse antagelser, som vi med fordel kan få valideret med det samme.
Nedbragt risiko som en empirisk værdi
Det kan være antagelser om at vores løsning vil kunne forbinde til databasen i produktionsmiljøet, antagelser om at produktionsmiljøet er hurtigere end test-miljøet hvor performance ser ud til at halte lidt. Antagelser om at vi nemt kan deploye løsningen fra vores udviklingsmiljø til produktion, antagelser om at websitet virker uden problemer på det rigtige domæne. Antagelser om at app’en bliver godkendt hurtigt i App Store, antagelser om at der ikke er en firewall der blokerer trafikken, en service bus konfiguration som er anderledes i driftsmiljøet eller at der er den rigtige version af et vigtigt modul på web serveren i produktion.
Vi kan målrettet gå efter at nedbringe risiko tidligt i opstartfasen, og begynde at levere empirisk værdi med det samme.
Ny viden som en empirisk værdi
Nogle gange er der bare ting, vi ikke ved når vi går i gang med at bygge. Vi kan med fordel kan opsøge viden så tidligt i forløbet det over hovedet kan lade sig gøre.
Ofte er der en masse ubesvarede spørgsmål, når et projekt startes og vi kan hente empirisk værdi, ved at sætte ud for at finde svar på spørgsmålene.
Sådan kan du levere værdi i hvert sprint
I den bedste af alle verdener kan et team levere begge typer af værdi løbende, sprint efter sprint, iteration efter iteration. Men det er langt fra altid muligt, og ofte er det svært at levere forretningsværdi i begyndelsen af en udviklingsproces. Derfor er det afgørende at teamet ved, at empirisk værdi kan være ligeså vigtigt – en ligeså værdifuld leverance.
En måde at hente den empiri vi er ude efter, er typisk at gøre det, der føles vanvittigt i starten af et udviklingsforløb: Byg små vertikale “slices” af løsningen, og sæt dem drift, så meget som det overhovedet er muligt. Også selvom vi slet ikke har en løsning endnu, som nogen brugere kan se. For der er masser af antagelser vi kan teste på vores løsninger, længe inden de er klar til at komme brug.
- Hvor meget “load” er der på den komponent vi bygger?
- Hvor mange forskellige brugere kommer til at besøge vores site?
- Hvilke betalingsmuligheder benytter vores kunder typisk?
- Hvilken arkitektur kan vi skabe buy in på hos kollegaerne?
- Er der features i det system som vi erstatter, som slet ikke bliver brugt og vi ikke behøver at bygge igen?
Her er et par eksempler på user stories, som vil kunne bringe empirisk værdi i opstartsfasen af et projekt.
Som site reliability engineer vil jeg kunne monitorere oppetiden på webitet og blive informeret ved varige nedbrud med det formål at kunne reagere hvis nedetiden er uacceptabel
Med en story som denne er teamet nød til at få et website helt produktion og træffe nogle nødvendige beslutninger om hvordan systemet skal overvåges og hvordan nogen skal adviseres, når der opstår problemer. Når du har implementeret denne story, får du løbende indsigt i, hvordan eksempelvis senere deployments i opstartsfasen påvirker systemets tilgængelighed.
Som udvikler vil jeg kunne sende kodeændringer fra en fælles kodebase i produktion via automatiseret deployments med det formål at opdateringer hurtigt og nemt kan komme i drift
Vi bygger en CI/CD pipeline, som kommer til at hjælpe os til at finde problemer i vores løsninger hurtigt, når det teamet laver automatisk kommer i produktionsmiljøet. I produktionsmiljøet det kan blive set virke, sammen med alle de andre komponenter, som også er i produktion.
Som udvikler
vil jeg have vores site til at køre på flere nodes
med det formål at kunne sætte ny kode i drift hyppigt, uden at forsage nedetid på sitet
På denne måde kan vi tidligt få etableret vores løsning på flere nodes, hvilket gør at vi tidligt opdager hvis den slags hosting giver os tekniske problemer.
En gevinst for samarbejdet i teamet
User stories som dem herover går på kompromis med et klassisk dogme: at de skal skrives med kunden eller brugeren som repræsentant for behovet. Det får vi svært ved at gøre med mange stories i opstartsfasen af et udviklingsforløb. Alligevel vil jeg anbefale at du bruger denne slags stories, som hjælper med at realisere empirisk værdi i dit produkt. De kan bruges som udgangspunkt for nogle rigtig gode snakke med dit team om, hvor der reelt ligger risiko gemt i jeres projekt. De kan – og bør – laves helt færdige og følge en Definition Of Done hvor ændringerne bringes helt til produktionsmiljøet og tages i brug. Og det bringer dig som Product Owner tilbage til bordet, hvor du kan hjælpe teamet med at foretage prioriteringer i et forløb, der ellers typisk er forbeholdt udviklerne i teamet at råde over.