Gör du DevOps på rätt sätt?

Ett av de vanligaste misstagen i en DevOps-transformation är att se den enbart som en teknisk övning. När fokus är så snävt kan det leda till att man utvecklar förmågor som bara är utformade för att få ut driftsättningar så snabbt som möjligt. Tyvärr innebär en hög driftsättningstakt inte automatiskt att du driver strategi eller skapar värde för intressenterna. Ibland är det enda du gör att röra dig snabbare och effektivare mot ingenstans.

Vad krävs för att skapa mjukvara av hög kvalitet?

Hur vet vi om mjukvaran vi släpper faktiskt skapar värde för kunderna? Design thinkings modell Desirability, Feasibility & Viability ger en mycket bra grund för att bedöma om du sannolikt kommer att skapa värde. Och det bästa med modellen är att den är väldigt enkel.

De tre typiska fallgroparna är:

• Tjänsten löser inte användarens problem eller är för krånglig att använda, vilket leder till låg användning bland slutanvändare – bristande desirability

• Tjänsten skulle uppfylla alla behov, men är inte möjlig att genomföra eftersom utvecklingsinsatsen är orealistisk eller processförändringarna inte går att genomföra – bristande feasibility

• Tjänsten uppfyller användarnas behov och går att genomföra, men skulle inte skapa tillräckligt med affärsvärde för organisationen – bristande viability

Att skynda framåt är inte tillräckligt lean

Under det senaste decenniet har lean produktutveckling blivit populärt som en oändlig cykel av ”bygg – mät – lär”. Detta arbetssätt kan leda till en kultur där koncept inte valideras innan de skickas vidare till utveckling. Då kan utvecklingsinsatsen läggas på arbete där den enda validerade lärdomen är att konceptet inte fungerade. I värsta fall går större delen av utvecklingsinsatsen till slöseri – raka motsatsen till att arbeta lean.

Mjukvaruutveckling är ofta flaskhalsen som avgör hur snabbt organisationen kan utveckla sina tjänster. Det är viktigt att utveckla förmågan att släppa ofta, men det är minst lika viktigt att utveckla hur tjänster konceptualiseras och hur krav definieras. Den goda nyheten är att du inte behöver införa ett Agilt ramverk för hela organisationen för att komma i gång. Faktum är att du kan göra stor skillnad genom att följa dessa tre arbetssätt.

Kontinuerlig validering ger stor effekt

Först och främst: validera före utveckling. Punkt. Vanligtvis krävs det inte många fingrar för att räkna antalet arbetsdagar som behövs för validering. På feature-nivå kan du spara månader av arbete, men för koncept kan det handla om år.

Du sparar mycket onödigt arbete och frustration om ni har en kultur där det är självklart att validera tjänstekoncept innan ni går vidare. Ni bör också kontinuerligt validera features innan de hamnar i utvecklingssprintar.

I sin enklaste form kan kontinuerlig validering vara:

• Viability: Ser viktiga intressenter, inklusive partners och kanaler, att featuren skapar värde, och är den förändring som krävs hanterbar?

• Desirability: Vad visar användartestningen av prototypen? Är den tilltalande, funktionell och relevant för användarna? Med andra ord: fick vi ett ”wow” eller ett ”va?”

• Feasibility: Håller de kritiska delarna i arkitekturplanen vid ett tekniskt proof of concept, och går tjänsten att implementera med en rimlig insats?

Hur grundligt du bör validera features kräver balans och lite övning. Hur noga behöver du till exempel validera olika varianter av användarflöden för mindre features? Det krävs en del experimenterande, eftersom valideringsprinciper som fungerar för någon annan inte alltid är tillämpbara för dig.

Tvärfunktionella arbetssätt

Det enklaste sättet att säkerställa desirability, viability och feasibility är att låta design, verksamhet och utveckling arbeta tillsammans. Det bästa sättet att börja utforma en feature är till exempel att samla produktägaren, designern och utvecklaren framför en whiteboard eller i en workshop på distans.

Alla som arbetar med tjänsten bör förstå hur deras arbete hänger ihop med det andra gör. Metoder och verktyg som gör samarbete effektivt, till exempel en design sprint, bör användas där det behövs. Samarbete minskar inte bara mängden slöseri, utan förbättrar också kvaliteten på era idéer – eftersom ni får direkt återkoppling på desirability, viability och feasibility.

Kom ihåg att involvera design, verksamhet och utveckling i varje fas av projektet för att ge er själva bästa möjliga förutsättningar att lyckas. Det är inte heller särskilt svårt att börja förbättra era processer och arbetssätt (läs mer om vår Digital Product Building Toolkit).

IT måste flytta längre åt vänster

Shift left innebär att förebygga problem och förbättra kvaliteten genom att utföra fler uppgifter tidigt i värdekedjan. Inom DevOps har det traditionellt inneburit fokus på kvaliteten i acceptanstester eller att möjliggöra kontinuerlig driftsättning. Detta är mycket viktigt, men IT måste flytta ännu längre åt vänster.

Det är avgörande att designers, verksamheten och utvecklare samarbetar effektivt genom hela värdekedjan och under hela kravet livscykel. Det räcker inte att IT enbart fokuserar på att ”hantera krav” – IT måste delta i den konceptuella utforskningen och utformningen av features.

När du börjar validera kontinuerligt och förbättra tvärfunktionella arbetssätt för konceptutforskning, design och utveckling är du på god väg att skapa mer värde samtidigt som du minskar slöseri och frustration. Du får också bättre möjligheter att styra om dina insatser inom design och utveckling, eller till och med ändra hela roadmapen.

Gör du DevOps på rätt sätt?

Så, gör du verkligen DevOps på rätt sätt eller automatiserar du bara processer som är ineffektiva redan från början? Om du fortfarande försöker utvärdera hur väl du lyckas med DevOps finns här fyra tecken på att du är på rätt väg. Känner du igen dessa tecken är du förmodligen i ett bra läge. Om inte behöver du troligen ett Design Thinking-perspektiv.

• Du behandlar inte affärsutveckling, design och utveckling som separata processer, utan fokuserar på att få hela värdekedjan att fungera.

• Alla förstår hur deras arbete hänger ihop med vad andra gör, och samarbete minskar antalet överlämningar.

• Du fokuserar inte bara på de validerade lärdomarna från ”build – measure – learn”, utan validerar också kontinuerligt före utveckling.

• Er kultur uppmuntrar till experiment, och kostnaden för misslyckanden minskar eftersom kontinuerlig validering gör att ni kan misslyckas snabbt.