Fokus på kvalitet – nyckeln till framgång
Våra organisationer kan betraktas som levande organismer, som ständigt utvecklas för att anpassa sig till sin miljö. Vare sig vi gillar det eller ej så är marknaden mer kaotisk idag och förutsättningarna förändras radikalt, oftare än vi någonsin upplevt tidigare.
Så, om vår organisation kan betraktas som en levande organism, borde själva IT-landskapet utgöra själva nervsystemet för denna organism. Du kan inte uppnå agilitet för affären och organisationen utan att också bygga upp den tekniska agiliteten. Hela systemet måste fungera smidigt tillsammans för att kunna leverera på kundernas krav.
SAFe påminner oss ständigt om vikten av att förnya våra produkter och tjänster och förmågan att kunna skala upp snabbt när en affärsmöjlighet uppstår. Detta är fortfarande en stor utmaning för de flesta organisationer.
Produktledningens förmåga att välja ut rätt saker och värdeströmsteamens möjlighet att bygga saker på rätt sätt är nyckeln till att åstadkomma nöjda kunder. Att leverera produktvärde både snabbare och oftare, samtidigt som ett kontinuerligt fokus på kvalitet bibehålls, är helt avgörande för att säkerställa och bibehålla kundvärde.
Teamen bör kontinuerligt bygga in kvalitet i produkten men också i produktutvecklingsprocessen. Det innebär att vi kan minska fokus på mer traditionella kvalitetskontroller, eftersom dessa ofta tenderar att göra flödet långsammare.
Grundläggande agila kvalitetsmetoder
Några grundläggande agila kvalitetsmetoder lyfts fram i SAFe 6.0, som omfattar både agilitet för affären, organisationen och fokus på teamen och deras förmåga att bidra med teknisk agilitet:
Skifta lärandet ”till vänster ” Denna praxis bygger på att man behärskar arbetssättet med kortare planerings- och genomförandecykler, säkerställer snabb återkoppling och därigenom erhåller en snabbare inlärningsprocess. Om vi får insikt om ett problem tidigare kan vi vidta åtgärder med mindre insats. Detta är en grundläggande del i att bygga organisationens team och dess tekniska agilitet. ”Shift left” som koncept har sitt ursprung från DevOps-rörelsen, som uppmuntrar oss att bygga s.k. ”DevOps-pipelines”, där vi genomför testning, kvalitet- och prestandautvärdering betydligt tidigare i utvecklingsprocessen, ofta redan innan någon kod skrivs.
Men vi kan också anpassa detta tankesätt till att gälla för en organisations förmåga att vara flexibla avseende sin affärsutveckling. Om vi spenderar tillräckligt med tid på att förfina våra produkt-backlogs för att identifiera rätt MVP:er och MMF:er (ungefär ”minsta livskraftiga produkt” och ”minsta säljbara funktion”) så skapar vi möjlighet att få feedback från kunden betydligt tidigare och lär oss då att snabbare och mer löpande anpassa våra produkter och tjänster till marknaden.
Jobba i par – Denna praxis handlar mycket om samarbete, helt enkelt dra nytta av att få in fler perspektiv på ett problem, men bidrar även till kunskapsdelning inom ett team. Den klassiska uppsättningen av att jobba i par för att höja den tekniska förmågan är att två programmerare sitter tillsammans, en skriver kod och en navigerar bland krav och granskar resultatet. En annan uppsättning av konceptet ”pairing” är att två testare tillsammans granskar en planerad testansats utifrån gällande teststrategier eller att en utvecklare och en testare tillsammans diskuterar hur man optimerar framtagandet av loggar, för att säkra ett effektivt testflöde.
Att jobba i uppsättningen verksamhetsexpert och teknisk expert är också kraftfullt. T ex kan produktägaren ta hjälp av en testare för att skriva tydligare användningsfall. Eller att produktägaren sitter ihop med en programmerare, vilket är mycket effektivt när kraven är komplexa eller kanske något vaga. Det kan också handla om två produktägare som tillsammans analyserar affärsmöjligheter inom en viss affärsdomän. Endast din fantasi sätter gränserna för ökad samverkan i teamen. Det innebär en extra investering men i slutändan ökar det fokus på kvalitet och värdeskapande.
Kollektivt ansvar och ”T-formade” färdigheter – Denna praxis är relaterad till teamets kollektiva intelligens, inklusive kulturen att hjälpa varandra – att hålla sig målfokuserad framför att vara uppgiftsfokuserad. För det första handlar det om att ta kollektivt ansvar – om alla känner ägarskap för att produktens lösning fungerar fullt ut, finns en god grund för att åstadkomma inbyggd kvalitet. Alla personer i teamet ska kunna ta initiativ till att omstrukturera kod, förbättra designen, åtgärda fel och lägga till ny funktionalitet.
Roller i ett värdeströmsteam (även kallat Stream-Aligned Team i SAFe & Team Topologies) överlappar på ett sätt, en testare behöver ha en viss bredd, och känna till vissa utvecklarprinciper samtidigt som utvecklaren måste känna till grunderna för testning. En testare är ofta mycket skicklig på att skriva både affärsmässiga och tekniska krav. En utvecklare bör inte bara enhetstesta utan också göra andra former av kontroller och granskningar innan koden distribueras. En utvecklare bör ha bredden att förstå hur driftteknikern jobbar för att installera kod, övervaka, och skapa insikter baserat på olika mätningar i driftmiljön.
Tänk affärsmässig agilitet och teknisk agilitet även här. Hur kan vi bredda kunskapen i teamet och undvika personberoenden. Detta mer flexibla sätt att arbeta och samverka bidrar i hög grad till teamets inbyggda kvalitetstänk. Att proaktivt fokusera på bredare (T-formade) färdigheter i teamet bidrar inte bara till ett effektivare flöde och minskar antalet flaskhalsar. Det kommer också att underlätta eventuella behov av att omgruppera team, som kan uppstå när man ständigt behöver mobilisera och anpassa sig till en föränderlig värld.
Tydliggör standarder och leveransens färdigkriterier – Att tydliggöra en produkts standarder och kvalitetsattribut, som en grundläggande beskrivning av dess egenskaper, utgör en förutsättning för att kunna säkerställa att en arbetsuppgift är komplett och korrekt. Om du inte kan beskriva en förändring, hur ska du då kunna genomföra den! Att beskriva en produkts egenskaper, affärsmässigt och tekniskt är högst relevant även vid agil utveckling. Men du gör det i kortare cykler och teamen bör alltid ha fokus på att designa lösningar som är lätta att anpassa till nya behov.
Det kan handla om att produktledningen behöver tydliggöra viktiga affärsmässiga artefakter, såsom olika produktegenskaper, affärsregler, kundinteraktioner eller definitioner av masterdata, som i slutändan kan ha stor påverkan på en lösningsdesign. Att sedan under det agila utvecklingsarbetet säkerställa att den kontinuerliga anpassningen av en lösning överensstämmer med intentionen med ett system och den övergripande arkitekturen, inklusive grundläggande tekniska artefakter, utgör en viktig bas för att skapa inbyggd kvalitet. Det kan handla om tekniska standarder för API:er, konfiguration av containers, interaktioner mellan mikrotjänster eller att tydliggöra andra viktiga kvalitetsattribut uttryckta som icke-funktionella krav (kring t ex säkerhet, användbarhet eller stabilitet).
Att tidigt uttrycka acceptanskriterier minskar risker och bör därför tillämpas för att klargöra förväntningarna på en funktion, gärna utifrån flera olika intressenters perspektiv av lösningen – till exempel produktägare, systemarkitekter, testare, drift och andra aktörer. Att uttryckligen ta sig tid att skriva ned en definition på när arbetsuppgifter är klara hjälper team, releasetåg och hela organisationen att tydliggöra sina förväntningar på kommande leveranser.
Automatisera arbetsflöden – Överlämningar och flera olika manuella steg i utvecklingsarbetet bör undvikas för att förhindra kvalitetsbrister, som lätt uppstår pga mänskliga misstag. Automatisering av arbetsflöden minskar kostnader och ökar möjligheten att efterleva standarder. Testautomatisering av repetitiva och komplexa testuppgifter samt releaseautomatisering för att paketera och installera kod är två typiska exempel på arbetsflöden som bör automatiseras för att öka teamens tekniska förmåga.
När det gäller affärsagilitet är implementeringen av ett modernt lean-baserat QMS (kvalitetsledningssystem) som använder digitala verktyg för att skapa organisatorisk flexibilitet ett sätt att automatisera kvalitetshanteringsprocessen. Ett lean-baserat QMS ger stöd för att bygga lösningar och regulatoriska krav inkrementellt, vilket därmed hjälper till att uppnå flexibilitet och transparens.
Jag hoppas att detta blogginlägg gav dig lite mer input kring några grundläggande kvalitetspraxis som lyfts i ramverket, SAFe 6.0.
Underskatta aldrig den faktiska tid som behöver sättas av i teamet för att säkra ett kontinuerligt lärande kring inbyggd kvalitet (utbildning, reflektion, åtgärder osv.). Detta för att fullt ut kunna behärska ovanstående beskrivna agila kvalitetsmetoder. Det är det som i slutändan avgör om du har förmågan att maximera effektiviteten i utvecklingsarbetet och därmed åstadkomma den mest optimala produktkvaliteten.
Läs mer om inbyggd kvalitet i den här artikeln: https://scaledagileframework.com/built-In-quality/
