Dit artikel is gepubliceerd in de najaarsspecial van TestNet nieuws (https://www.testnet.org/testnet/download/testnet-nieuws/tnn18_nj_v1.1.pdf)
Niemand is perfect, maar een team kan dat wel zijn. Een écht goed team functioneert als een geoliede machine en kan uitzonderlijke resultaten behalen. Denk aan een formule 1 pit crew. Zij moeten snel een probleem evalueren, een oplossing vinden, er naar handelen en tegelijkertijd bewust zijn van eventuele externe omstandigheden die de oplossing kunnen belemmeren. En dat telkens weer. Dit worden High Performance Teams (HPT) genoemd. High Performance Scrum Teams kunnen een productiviteit behalen die maar liefst 400% hoger ligt dan die van gemiddelde watervalteams [1]. Op basis van bestaande studies en mijn eigen visie zal ik in dit artikel uitleggen wat de kenmerken van HPT binnen Scrum zijn, welke metrics gebruikt worden en hoe tools ondersteuning kunnen bieden.
Samen meer presteren
Er zijn genoeg voorbeelden te vinden van academische en professionele studies over de relatie tussen IT projecten en productiviteit. Ook over HPT circuleren diverse artikelen (en meningen). Een eenduidig definitie ontbreekt echter, omdat het contextafhankelijk is. In feite zet een HPT verrassende resultaten neer door een speciale manier van samenwerking. Hierdoor halen de teamleden het beste uit zichzelf en heeft iedereen aan een half woord genoeg.
Is er één formule voor succes? Nee! Immers, elke organisatie en elk team is uniek. Om te begrijpen hoe teams optimaal functioneren en wat de principes achter HPT zijn, helpt het om bewust te worden van wat zowel positieve als negatieve invloeden zijn op de (team)prestaties. Aan de hand van twee modellen zal ik dit verder toelichten.
The 5 dysfunctions of a team van Patrick Lencioni
Het model van Lencioni [2] beschrijft de vijf frustraties die de samenwerking in teams saboteren. De volgende afbeelding geeft dit weer.
De opsomming geeft weer in welke volgorde de frustraties, die gerelateerd zijn aan elkaar, overwonnen moeten worden. Dus afwezigheid van vertrouwen leidt tot angst voor confrontatie en conflict, et cetera. Relaterend aan het Scrum proces, zou het betekenen dat vertrouwen naar de Product Owner en tussen de teamleden onderling de absolute basis is. Dit klinkt eenvoudig, maar doorgaans is dit het lastigste gedeelte bij teamontwikkeling. Het vergt onder andere dat men zich kwetsbaar durft op te stellen. Dat gaat niet vanzelf en dit kun je niet opeisen. Een teken van onvoldoende vertrouwen is bijvoorbeeld als teamleden zich niet durven uit te spreken bij Scrum meetings, maar wel op de wandelgang klagen over het werk of over elkaar. Goede feedback durven geven is cruciaal voor het functioneren van een team. Management Guru Ken Blanchard zegt niet voor niets “feedback is the breakfast of champions”.
Stephan Covey’s “The 7 habits of highly effective people”.
Het model van Covey [3] omschrijft zeven eigenschappen van persoonlijk leiderschap en effectiviteit. Hoewel dit model gefocust is op het individu, vind ik dat de eigenschappen ook toepasbaar zijn voor een Scrum Team. Zie daarvoor de volgende tabel.
| Eigenschap | Vertaling naar Scrum |
|
Scrum Teams zijn volledig zelf organiserend en spelen zelf in op veranderende omstandigheden (bijv. gewijzigde prioriteit, scope). |
|
Scrum Teams hebben het doel helder voor ogen door specifieke hulpmiddelen te gebruiken, zoals: product vision/statement, release plan, sprint plan. |
|
Een geprioriteerde product backlog zorgt ervoor dat het Scrum Team werkt aan items met de hoogste waarde. Intensieve samenwerking tussen de Product Owner, Scrum Master en Scrum Team is nodig. |
|
Niet alleen de prioriteit is belangrijk, maar ook een juiste balans van diverse items. Bijv. proces verbeteringen, wegwerken technische schuld, optimalisatie test automatisering, refactoring). Zo wordt iedereen gediend (klant, architect, team, …) |
|
Dé top-focus van het team is om waarde te leveren aan de klant. In de ideaalsituatie wordt direct nauw samengewerkt met de eindklant om het product volledig te begrijpen. Zodra het team dit begrip heeft en heeft bewezen dat het snel waarde kan leveren, dan wordt optimaal vertrouwen opgebouwd voor de verdere interactie met klanten. |
|
De sleutel voor goede synergie in een Scrum Team ontstaat bij een volledig empowered team en gezonde transparante samenwerking. Het team is multidisciplinair en complementair: niet alleen qua skills maar ook qua persoonlijkheid. Ze kennen elkaars specifieke sterkten en zwakten en houden hier rekening mee. |
|
Er heerst een cultuur waarbij continue verbeteren mogelijk is. Bijvoorbeeld door naast de retrospectives de individuen de mogelijkheid te geven zich te verdiepen in bepaalde (nieuwe) technologieën / tools / onderwerpen |
Met de bewustwording van beide modellen is een eerste stap gezet in de juiste richting. Vervolgens moet zeer hard gewerkt worden. Want een HPT worden vergt een flinke dosis inzet, ook van het management. Dit moet men niet onderschatten: de theorie is makkelijk te leren, maar het beheersen ervan is een kunst.
Van meten naar weten
Een HPT worden is lastig. Nog lastiger is wellicht om een stabiel HPT te blijven en continue te verbeteren. Zicht en grip krijgen op de prestaties van je team is dus van belang. Zoals eerder beschreven bestaat er geen eenduidige formule om succesvol hierin te zijn. Er zijn echter wel hulpmiddelen die een duwtje in de rug kunnen geven. Hieronder zal ik er vier beschrijven.
- Agile Maturity Assessment
Ten eerste heeft Kumar [4] een handzame manier bedacht om een team assessment uit te voeren. Dit wordt gedaan op basis van de twaalf principes uit het Agile Manifesto. De Product Owner, Scrum Master en teamleden kunnen op elk van de items een score geven; hoe hoger hoe beter. Door per principe te middelen, ontstaat een totaalbeeld van het Agile volwassenheidsniveau.
Zo’n assessment moet in elke sprint worden gefaciliteerd waarbij levendige discussies gevoerd worden. Extra aandacht moet hierbij besteed worden aan scores die ver uiteen liggen.
- RoboScrum
Een andere benadering is die van Sutherland en Downey [1]. Zij beschrijven een (samenhangende) set van verschillende metrics. Het gaat te ver om in dit artikel al deze metrics in detail te behandelen, maar onderstaande tabel geeft een goed beeld van het nut.
| Metric | Used to answer… | Formula |
| Velocity | How much value can the team plan and achieved to the Product Owner’s satisfaction in a sprint? | ∑ Original Estimates of All Approved Cards |
| Work Capacity | How much effort can the Team expend in a sprint? | ∑ All Work Reported During the Sprint |
| Total Commitment | How much work did the Team ultimately commit to achieve in the Sprint, including Adopted Work pulled forward after the Planning Meeting? | ∑ Original Estimates for All User Stories |
| Focus Factor | What percentage of the Team’s total energy expenditure results in requested-and-approved value? | Velocity ÷ Work Capacity |
| Adopted Work | As a percentage of the Original Commitment, how much additional work did the Team need to pull forward before the end of the Sprint in order to stay engaged? | (∑ Original Estimates for Work Pulled Forward) ÷ Original Commitment |
| Found Work | As a percentage of the Original Commitment, how much unexpected complexity did the Team discover mid-Sprint on the work they had already committed to do? | (∑ Work Reported per Card – ∑ Original Estimates) ÷ Original Commitment |
| Targeted Value Contribution Increase |
How much change has there been in the Team’s Velocity over time, since the initial Sprint? (Initial Sprint can be selected on the Setup tab if Team structure changes) | Current Sprint’s Velocity ÷ Original Velocity |
| Accuracy of Estimation | How accurate are the Story Point estimates that the Team provides for their Work? | 1 – (Estimate Delta ÷ Total Commit) |
| Accuracy of Commitment | When the Team commits to work, how accurate are they in biting off a block that will keep them busy, at a sustainable pace and be delivered by the end of the Sprint? | (∑Original Estimates) ÷ (∑Original Estimates + ∑Adopted Estimates + ∑Found Work) |
Via een excel tool genaamd RoboScrum [5] kunnen teamprestaties objectief worden gemeten in plaats van op basis van een onderbuik gevoel. Als de gegevens correct worden ingevoerd, wordt automatisch weergegeven of het team op de juiste koers zit qua HPT. Deze metrics kunnen het management helpen om de performance van teams te vergelijken.
Hoewel deze metrics nuttig kunnen zijn, denk ik dat het enkel weggelegd is voor zeer ervaren Scrum Teams die zich al (bijna) High Performing mogen noemen.
- Happyness Metric
In de volksmond wordt wel eens gezegd dat tevreden medewerkers beter presteren. Recentelijk is dit nog onderschreven door een studie van de Universiteit van Warwick [6]. Misschien ook wel logisch, want geluk en tevredenheid zorgen er mijn inziens voor dat je, even gechargeerd, “fluitend” naar je werk gaat. Hierop verder causaal redenerend zal dit resulteren in een beter werkklimaat en uiteindelijk in betere eindresultaten. Betere eindresultaten zorgt voor tevreden klanten. En als klanten tevreden zijn kan dit weer leiden tot bijvoorbeeld hogere toekenning van budgetten om nieuwe producten te realiseren, of een betere reputatie wat weer kan leiden tot de inzet van andere professionals.
Het meten van medewerkerstevredenheid in je team is daarom belangrijk. Volgens Sutherland [7] is het een van de beste metrics omdat het een zogenaamde voorspellende indicator is. De uitvoering hiervan kan vrij laagdrempelig zijn door teamleden hun gevoelens te laten uiten op een schaal van 1 t/m 5. Uiteraard is dit afhankelijk van de context, maar te denken valt aan: “hoe tevreden ben je met je organisatie/project?” en “hoe tevreden ben je met je rol?”. Dit kan periodiek bijgehouden worden in een simpele spreadsheet. Wanneer duidelijke verschillen in de gemiddelde waarden optreden, moet ingegrepen worden door interactie en discussie om de tevredenheid van het team te vergroten.
- Team Morale Metrics
Een stap verder is het meten van het moraal van het team. Christiaan Verwijs [8] propageert dat de ‘happyness metric’ te subjectief is en heeft een alternatief bedacht: de ‘Team Morale Metrics’. Hiermee wordt meer feitelijk en objectief gemeten wat het welzijn van het team is in algemene zin. In onderstaande tabel worden de karaktereigenschappen samengevat van een hoog/laag teammoraal:
| Hoog moraal | Laag moraal |
| Teamleden zijn behulpzaam naar elkaar, ongeacht de taak | Teamleden doen niet mee aan (fun) team-activiteiten |
| Teamleden zijn trots op hun team en het werk dat ze doen | Teamleden schamen zich soms voor hun team |
| Teamleden doen nét even wat meer, ook al betekent dat incidenteel extra werk moeten verzetten | Teamleden hebben een “9 tot 5” mentaliteit |
| Teamleden bezwijken niet onder hoge druk of lastig situaties | Teamleden geven makkelijk op als problemen zich voordoen |
Via een online tool [9] kan eenvoudig een vragenlijst worden ingevuld en de resultaten kunnen direct worden ingezien. Tevens kan het individuele moraal vergeleken worden met het (gemiddelde) teammoraal.
Aanvullende aandachtsgebieden
Vanuit mijn ervaring heb ik nog aanvullende aandachtspunten die minstens zo belangrijk zijn als het volgen van de juiste processtappen, namelijk:
Practice what you preach
Wees een voorbeeld voor anderen: doe waar je voor staat en draag je vakmanschap uit. Als testprofessional kun je je opgedane kennis en ervaring delen met je teamleden en vice versa. Zo reserveer ik periodiek tijd om free-format met software ontwikkelaars en business analisten te sparren over actuele zaken met software kwaliteit als rode draad. Zo ontstaan soms nieuwe inzichten die normaliter niet zo gauw zouden ontstaan. Probeer hierin uit je comfortzone te komen en stimuleer kennisontwikkeling, want dit is essentieel voor innovatie [10].
Word dronken met je team
Rini van Solingen [11] deed ooit een uitspraak die me bijgebleven is. Vrij vertaald: “een groep mensen is geen team tenzij ze ooit tegelijkertijd dronken zijn geweest op dezelfde locatie”. Met andere woorden: om je collega’s écht goed te leren kennen is het aan te bevelen om soms een avondje uit te gaan. Niet per se dronken worden, maar in een informele setting te praten over werk en privé is doorgaans goed voor de verstandhouding. Zo kan het nuttige met het aangename gecombineerd worden. Want het ontwikkelen en testen van software kan worden beschouwd als een creatief beroep. Afgezien van kennis, ervaring en inzicht is de output van het proces sterk afhankelijk van de creativiteit en het oplossingsvermogen van de persoon. Goede ideeën en efficiënte oplossingen komen vaak juist ten tijde van ontspanning en rust. Door het team onder druk te zetten wordt zowel de creativiteit als zelfontplooiing beperkt en neemt de kans op softwarefouten toe. Vandaar dat het team af en toe ‘stoom moet afblazen’.
Netwerken
In de sportwereld is een perfect team niet altijd een groep mensen met sterspelers. Vaak zijn het spelers die individueel veel verschillende én complementaire skills en ervaringen hebben. Als Scrum Team zou je idealiter ook een dergelijke bemensing willen hebben. Uiteindelijk, een team dat goed ingespeeld is op elkaar en kort op de bal zit, is voorbereid op de toekomst. Dat wil zeggen, als er problemen optreden dan kunnen deze adequaat opgelost worden. Als teamlid heb je weliswaar niet direct invloed op de bemensing van je team. Maar als je niet allemaal ‘schapen met vijf poten’ hebt in je team, dan is het van belang dat je professionele netwerk in orde is en je weet waar je de kennis vandaan moet halen. Ik ken genoeg voorbeelden waarbij de analyse van een probleem onnodig veel tijd kostte omdat het team niet snel genoeg elders hulp ging vragen (mede omdat niet duidelijk was waar de specifieke kennis te vinden was). Teamleden moeten dus niet alleen goed intern communiceren, maar ze moeten ook contacten onderhouden met andere teams.
De zwakste schakel
Als je Scrum Team onderdeel is van een groter geheel, dan kan het zomaar zijn dat jouw team uitstekend presteert, maar dat anderen waarvan je afhankelijk bent in de ketenomgeving dat niet doen. Écht succesvol ben je pas als de principes van een HPT volledig zijn geïntegreerd in (alle teams van) de organisatie. Pas dan is een volgende stap om de organisatie high performance te maken. Diverse initiatieven kunnen hier handen en voeten aan geven, zoals: SAFe (Scaled Agile Framework), DAD (Disciplined Agile Delivery), Enterprise Scrum en DevOps.
Gebruik het juiste gereedschap
Het lijkt vaak een cliché, maar de inzet van het juiste gereedschap wordt wel eens onderschat. High Performing zijn, betekent snellere feedback loops, betere voorspelbaarheid en hogere softwarekwaliteit dan een “gewoon goed team”. De inzet van Continuous Integration en testautomatisering is daarmee onmisbaar geworden. Zorg dat het kennisniveau binnen het team up-to-date is met betrekking tot relevante methoden, technieken en aanverwante tooling. Als Agile testprofessional is het een must om thema’s zoals (A)TDD en BDD te vertalen naar de werkvloer. Denk hierbij aan FitNesse, Selenium en Cucumber. In het verlengde van DevOps is kennis over ALM (Application Lifecycle Management) een absolute pré. Want ALM is immers van toepassing tijdens het gehele softwareontwikkelproces: van idee naar eindproduct tot en met uitfasering van de software.
Conclusie
In de inleiding staat dat High Performance Scrum Teams een productiviteit behalen die maar liefst 400% hoger ligt dan die van gemiddelde watervalteams. Ik ben van mening dat zo’n percentage daadwerkelijk gerealiseerd kan worden mits aan álle randvoorwaarden voldaan is, de steun van het management aanwezig is en er objectief gemeten wordt. Echter, of je dit zou willen is een andere kwestie. Want je zou het even kort-door-de-bocht kunnen vergelijken met CMMI en/of TMMi level 5. Niet iedereen is hiervoor geschikt en niet iedereen is geschikt om dit vol te houden.
Ik vind dat als een Scrum Team de waarden en principes uit het Agile Manifesto (én de regels van Scrum) respecteert en naleeft, er een goed fundament aanwezig is voor een goed presterend team. De beschreven modellen en metrics zijn handzaam om van een (goed presterend) team een nog beter presterend team te maken. De stap naar het beste team, namelijk High Performing, is dan niet zo groot meer. Het is ook sterk afhankelijk van welke doelen men stelt om een HPT te worden, oftewel welke metrics er gekozen worden.
Al met al geeft dit artikel diverse concrete handvaten ter bewustwording en ter verbetering van je individuele prestaties en teamprestaties.
Referenties
[1] Downey, S., Sutherland, J., “Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft,” hicss, pp.4870-4878, 2013 46th Hawaii International Conference on System Sciences (HICSS), 2013
[2] Lencioni, P., The Five Dysfunctions of a Team, Jossey-Bass, 2002
[3] Covey, S. R., The 7 Habits of Highly Effective People: Restoring the Character Ethic, New York: Free Press, 2004
[4] Kumar, M.P., “Maturity Assessment Model for Scrum Teams”, http://www.scrumalliance.org/community/articles/2014/july/maturity-assessment-model-for-the-scrum-teams
[5] http://www.rapidscrum.com/RoboScrum
[6] Oswald A.J., Proto, E., Sgroi, D., “Happiness and Productivity”, University of Warwick, UK, and IZA Bonn, Germany JOLE 3rd Version, 2014
[7] Sutherland, J., Harrisson, N, Riddle, J., “Teams that Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams”, HICSS 2014: 4722-4728
[8] Verwijs C., “Agile Teams: Don’t use happiness metrics, measure Team Morale” http://www.christiaanverwijs.nl/post/2012/07/24/Agile-Teams-Dont-use-happiness-metrics-measure-Team-Morale.aspx
[9] http://teammetrics.apphb.com
[10] Nonaka, I., “The Knowledge-Creating Company”, Harvard Business Review, 1991.