For et stykke tid siden havde jeg en diskussion med en Scrum master omkring det med roller i det agile team, mere specifikt konceptet omkring ”whole team” og ”cross functional team”, eller på dansk det tværfunktionelle team. Vores diskussion drejede sig blandt om hvad begrebet tværfunktionelt team egentlig betød. Mine efterfølgende refleksioner giver mig anledning til at prøve at sætte ord på, hvordan jeg forstår de to koncepter i praksis. Og nu tænker du måske; Det er da helt grundlæggende agilt, det er sidste års diskussion… eller forrige. Men virkeligheden er bare, at rigtig mange teams i rigtig mange organisationer stadig kæmper med dette og har brug for hjælp til at få etableret disse cross functional teams.
Inden jeg selv forsøger at konkludere på mine egne tanker, så vil jeg gerne til en afveksling smide lidt rundt med en flok citater fra nogen der burde have ret godt forstand på det her, nemlig henholdsvis Mike Cohen og SCRUM Guiden skrevet af Jeff Sutherland og Ken Schwaber.
Lad os starte med ”whole team” begrebet. Det er egentlig ikke så svært…. I teorien i hvert fald. Mindsettet omkring whole team formuleres ret godt af Mike Cohen:
At etablere en ”whole team” tankegang er et vigtigt mål for ethvert team der ønsker at performe på det højest mulige niveau. Dette betyder ikke, at folk kan udskiftes, eller at alle lærer, hvordan man gør alle andres job. Men det betyder, at alle på teamet tænker først på, hvordan man kan nå holdets mål i stedet for hver enkelt persons individuelle mål.
Her har SCRUM guiden også en god pointe:
Medlemmer af individuelt development team kan have specialiserede færdigheder og fokusområder, men ansvarlighed hører under teamet som helhed.
Hvis vi ser på begrebet tværfunktionelt team, så har Mike Cohen også en holdning til det, et andet sted siger han nemlig;
“Et tværfunktionelt team har medlemmer med en række forskellige færdigheder, men det betyder ikke, at hvert medlem har alle færdighederne.”
Dette stemmer faktisk ret godt overens med hvad scrum-guiden siger om et development team:
”development teams er tværfunktionelle med alle de færdigheder som et team, der er nødvendigt for at skabe et produkt inkrement”
Og hvad er det så jeg gerne vil frem til, jo; reelt så er der altså tale om et kollektiv der TIL SAMMEN har alle kompetencer der er nødvendige for at kunne, analysere, designe, kode, integrere, teste, dokumentere og levere ”working software”. Alle skal ikke kunne kode, alle skal ikke kunne teste, alle skal ikke kunne designe god UX – kollektivet skal til sammen have kompetencerne.
Nu tænker du nok; ahh endnu en tester der bare vil advokere for at der skal være dedikerede testere i teamet, men det er faktisk ikke det jeg vil frem til ? Jeg vil frem til at ”Nogen” skal have kompetencen til at kunne teste – og med det mener jeg teste godt; vide hvad de forskellige typer test er, hvornår man bruger hvad, lave effektiv og tilstrækkeligt dækkende test, adressere de produktrisici teamet har identificeret for en story, en feature eller systemet som helhed. Det er sådan set ok med mig at der ikke er en person med titlen TESTER i teamet, men testkompetencen skal være der.
Profilerne i teamet kan sagtens have dybe specialer men de skal OGSÅ have noget i bredden, så udvikleren skal også have en vis indsigt i andre ting end at kunne designe og kode løsningen; måske noget UX, måske viden om testautomatisering, måske er han scrum master også …? Og det samme gælder testeren; det nytter ikke at vi ”kun” kan teste, vi skal også kunne give værdi til teamet i bredere forstand; hjælpe med at lave de gode user stories, sikring af testbare acceptkriterer (eller endnu bedre, supportere brugen af ATDD, specification by example eller BDD) for at sikre at grundlaget er godt. Måske er du scrum master? Måske er du teknisk og kan supportere jeres CI/CD pipeline?
Det kan godt være Iikke skal have en TESTER i teamet, men I skal sikre at der TESTES i teamet hele vejen gennem livscyklus – fra idé til produktion. Og testes godt og effektivt vel at mærke, test er ikke bare at tjekke at kravene er opfyldt eller at forretningen tjekker at deres arbejdsgange virker, der er så meget mere til god test.
Og det er lidt her jeg ser filmen knække for en del teams, kompetencen er ikke til stede i teamet – og hvordan kan I som team så tage det fulde ansvar for det I leverer? Hvordan kan I sikre at I ikke har for meget tilbageløb senere i livscyklus, når der kommer nye hænder på systemet, enten ved den sidste test som forretningen laver inden de går i produktion – eller når I er gået i produktion og de første fatale fejl opstår? Alt sammen noget der kommer til at ramme jer i næste sprint… eller næste igen. Hvordan kan I så undgå at kompromittere et par af de grundlæggende agile principper:
Vores højeste prioritet er at stille kunden tilfreds gennem tidlige og løbende afleveringer af værdifuld software
Løbende levering af velfungerende software, jo hyppigere des bedre.
Fungerende software er den primære måde at måle fremdrift på.
Så vær sikker på at dit agile team er klædt på til at tage det fulde ansvar for løsningens kvalitet, gerne med en kombination af at have en dedikeret agil tester i teamet og sikring af at teamet er klædt ordentlig på til at teste.
- Introduktion til hele teamet i
- Teststrategi for projekt/produkt/agilt release train
- Agil test
- Testdesignteknikker
- Exploratory test
- Fokus på testbarhed når I definerer user stories
- Fokus på god og effektiv unit test
- Automatisering af acceptance test, fundamentet for god regressionstest
- Exploratory test af de enkelte stories
Kilder:
https://www.mountaingoatsoftware.com/blog/cross-functional-doesnt-mean-everyone-can-do-everything
https://www.scrumguides.org/scrum-guide.html#team
http://agilemanifesto.org/iso/dk/principles.html
Hvis du gerne vil høre mere om test i det tværfunktionelle team og hvordan vi kan hjælpe dig, så ring til Margit Sejerkilde på 49408060.