Efter en del eftertanke har jeg i det følgende forsøgt at liste min top 10 for test og kvalitetsmæssige udfordringer i forbindelse med SAFe transformation. I den kommende tid vil jeg forsøge at dykke ned i nogen af disse for at uddybe yderligere.
- Ikke tilstrækkelig forståelse af det agile mindset: Hvis ikke teamet, toget og ikke mindst forretningen har en forståelse af de grundlæggende værdier og principper så er det svært at forstå og ikke mindst udføre de aktiviteter der er en fundamental del af agil udvikling.
- Manglende forståelse for test:” vi skærer lige ind til kernen når vi definerer denne SAFe model, så vi har skåret test fra… det tager vi senere”. Dette er desværre ikke en sætning jeg har opfundet til lejligheden men en jeg faktisk har fået præsenteret i 3-4 forskellige kontekster.
- Ingen fælles strategi for test i toget: SAFe rammeværket nævner ikke en testmanager, men en eller anden skal sikre at der er en retning – en strategi for hvordan der testes. Og nej – bare fordi vi er agile, og teams er selvorganiserede betyder ikke at alt kan håndteres indviduelt i de enkelte teams.
- Manglende forståelse for ”why”, når man definerer features: Det har været en tilbagevendende problemstilling at man meget hurtigt får fokus på hvad og hvordan – hvad er det vi konkret skal implementere og hvordan skal vi implementere det. Men hvad er det for en forretningværdi det skal give, hvad er det for et problem, I er ved at løse?.
- Udfordringer med nedbrydning i user stories; ”Vores system er anderledes, så vi kan ikke bryde features ned i userstories.” Den hører jeg jævnligt, men jeg tror, det er MEGET få features der ikke kan brydes ned i mindre bidder når det kommer til stykket – men det kræver måske hjælp at komme igang.
- Ingen test kompetencer I teamet: Test bliver i nogen tilfælde stadig behandlet som en reaktiv aktivitet vi foretager sammen med forretningen når al udvikling er færdig. en svær tilgang i forhold til at kunne give hurtig feedback, og kunne rette fejlene tæt på hvor de bliver introduceret – og i forhold til DONE.
- Manglende “whole team” mindset: Power of three, crossfunctional teams, slut med silo-fagligheder er grundlæggende for at få hele kvalitetsmindsettet … og det agile mindset i teamet.
- Ikke styr på afhængigheder for test på tværs af teams – og trains: Ofte er fokus på team niveau på individuelle stories og features, på arbejdet der skal ske inde i teamet. Men ikke altid med klart billede af hvordan der koordinerers på tværs af teams og trains – også på test. I følge modellen ligger en del af end-to-end og system integrationstest hos system teamet… men det er ikke alle der har sådan et.
- ikke tilstrækkelig fokus på at få etableret CI/CD pipeline: Et er at få rammeværket på plads, den rent tekniske pipeline. Men hvad er tilgangen til test? Der står godt nok noget om TDD og BDD i modellen, men der er langt imellem jeg møder det i praksis. Hvordan sikrer vi at det er det rigtige vi automatiserer? At vi ikke skaber en mastodont på lerfødder der ikke er agil?
- Vi starter ikke fra nul – vi kommer med ”bagage” Der er med de senere versioner af SAFe kommet mere fokus på test og kvalitetssikring selvom der er et stykke vej endnu, men der er desværre stadig en tendens til at ”man” glemmer at det ikke er en transformation fra ”green field”, der er potentielt masser af bagage med i form af store manuelle… og dårligt vedligholdte regressionstests, manglende erfaring med agil test mv. Og så nytter det ikke at pege på “Build-in quality” ikonet på tegningen og sige at det kommer helt af sig selv når man bare gør det – så skal der mere til.
Det var ti overvejelser over hvad der kunne udfordre dig og din organisation i forbindelse med en transformation mod en skaleret agil udviklingsmodel set med test og kvalitetsbrillerne på. Og husk; lige her skriver jeg i forhold til SAFe(r) men mit gæt er at du vil kunne genfinde disse i alle de skalerede modeller, det er skaleringen der er udfordringen – ikke om den hedder SAFe, LESS, Scrum@Scale.