Van agile naar high performance software team in 5 stappen

Waardecreatie en verminderen van waste in softwareontwikkeling

Hoe creëer je meer waarde met software?

Waar je in elk goed recept waarschijnlijk zout en peper nodig hebt, is het creëren van waarde voor de eindgebruiker ofwel het verminderen van waste in software ontwikkeling essentieel.

Laten we eerst eens kijken naar hoe je meer waarde creëert met software. Maak, voordat je start met het bouwen van een functionaliteit, duidelijk wat het doel van de functionaliteit is of welk probleem het oplost. Probeer daarnaast te valideren met een prototype of het de investering van het bouwen waard is. Teams die zich continu afvragen waarmee zij de klant of de gebruiker het beste kunnen helpen of wat het meeste oplevert, maken betere beslissingen dan teams die alleen doen wat de product owner of (interne) klant wil.

Wat is waste in softwareontwikkeling?

Vaak zie ik dat bij de start van een nieuw project er veel meer requirements worden opgesteld dan noodzakelijk zijn om waarde toe te voegen. Vaak omdat je het perfecte product of de perfecte functionaliteit wil ontwikkelen. Maar is perfect wel echt perfect? We noemen dit ook wel feature creep of scope creep. Van deze requirements is niet altijd duidelijk wat ze uiteindelijk opleveren voor de eindgebruiker en of er überhaupt wel behoefte aan is.

Wanneer dit gebeurt ontstaat er waste, oftewel verspilling. Waste is alle activiteit die geen waarde oplevert voor de klant of eindgebruiker. Er bestaan 7 vormen van waste:

• Onafgerond werk
• Onnodige functionaliteiten
• Overdracht tussen collega’s
• Te laat fouten opsporen
• Switchen tussen taken
• Verdwijnen van kennis

Als het je lukt om waste te verminderen dan:

• gaat de productiviteit van software teams omhoog
• wordt het bouwen van features of volledige producten waar een eindgebruiker niets aan heeft voorkomen
• wordt complexiteit van het gebouwde product verminderd
• kost je project minder tijd en geld
• Maar nog belangrijker: je zorgt voor een kleinere kans dat een IT project faalt.

Voor meer over waste en hoe je waste kan verminderen raad ik je aan om eens het boek Lean software development: An Agile Toolkit te lezen (boekentip!).

Kenmerken van een high performance software team

Zijn agile teams high performance teams?

Een agile team kan vaak het verschil maken in een organisatie. Deze cross-functionele, zelfsturende en flexibele teams maken het mogelijk om sneller software te ontwikkelen en te implementeren. Echter, een agile team staat niet garant voor creëren van waarde. Een high performing team is echter wel een team dat snel waarde kan leveren. Ze zorgen voor een hogere conversie, een betere online journey en minder vragen aan de klantenservice.

Maar dat gebeurt natuurlijk niet op dag 1 en kan alleen als je team:

• gemotiveerd is
• duidelijk weet waarom en waarvoor de software wordt ontwikkelt
• in een omgeving werkt waarin er voldoende ruimte, tijd en resources aanwezig zijn.
• ervaring heeft om hoge kwaliteit te leveren op een efficiënte manier
• alle benodigde rollen en vaardigheden aan boord heeft om impact te kunnen maken, zoals analisten, tech leads, UX designers, engineers en delivery managers

High performing teams barsten van de energie, hebben echt zin in de opdracht en hebben een duidelijk doel voor ogen. Ze werken zelfstandig en leren elke dag bij. Naar collega’s buiten het team, de opdrachtgever en het management weten ze helder te communiceren waar ze aan werken en wat ze willen bereiken.

Hoe ontwikkel je een high performance team in 5 stappen?

Stap 1: Zorg voor een T-shaped team

T-shaped medewerkers hebben een eigen expertise, maar kunnen ook andere taken effectief uitvoeren. Naast technische vaardigheden, zoals programmeren of design, bezitten deze collega’s ook emotionele intelligentie en creativiteit. Op volle kracht heeft een high performance software team expertise aan boord op gebied van UX en Design, Engineering, Infrastructuur, Testing en Security. Met een T-shaped team zorg je daarnaast voor een betere samenwerking, omdat ze elkaar kunnen helpen.

Wil je weten of jouw team alle benodigde competenties heeft? Dan is het DASA DevOps competence Model een goede tool. In dit model wordt gekeken naar vaardigheden en kennis van teamleden. Idealiter zit jouw gehele team op niveau 3 en zijn er uitschieters binnen het team naar het expert- of masterniveau op de verschillende deelgebieden die je op de afbeelding ziet.

Bron: https://www.devopsagileskills.org/dasa-competence-model/

Stap 2: Start met een duidelijk doel

Start aan het begin van elk project met een probleemanalyse. Dat betekent dat je niet alle rollen zoals benoemd in stap 1 direct nodig hebt. Het is belangrijk om je te realiseren dat er altijd dingen veranderlijk zijn. Je begrip van ‘wat’ je precies gaat bouwen verandert, door het proces van ontwerpen, valideren, bouwen, testen en releasen. In elke stap leer je als team meer en wil je bijsturen. Echter blijft het ‘waarom’ en ‘voor wie’ vrij stabiel. Dat kan je dus vooraf met een kleiner team goed vaststellen, zodat je kostbare tijd van andere teamleden kan besparen.

Zorg dat het team in het begin, zonder dat je hier te lang in blijft hangen, de probleemanalyse goed uitvoert.

• Wie bedienen we?
• Wie zijn de belangrijkste stakeholders?
• Wanneer zijn we succesvol?

Alleen dan kan je het team goed briefen. In mijn ervaring worden ook de meest succesvolle teams onrustig als de ‘waarom’ niet duidelijk is. Een tip is om tussen de probleemanalyse en de start van een team een sprint 0 in te bouwen. Hiermee zorg je ervoor dat alle randvoorwaarden zijn geregeld: denk aan de infrastructuur, de release pipeline, de initiële software architectuur en het uitwerken van de backlog. Je kunt daarna super-efficient gaan sprinten, wat momentum opbouwt en vertrouwen geeft bij alle betrokkenen. Wat is er mooier dan snel resultaat zien aan het begin van een project?

Stap 3: Ontwikkel en release software in korte cycli

Het releasen van software moet voor de teams totaal niet spannend zijn, gewoon een druk op de knop. De aanpak, waarbij teams software in korte cycli kunnen produceren en zonder problemen geautomatiseerd kunnen releasen, heet Continuous Delivery. Continuous Delivery richt zich op het sneller en frequenter bouwen, testen en vrijgeven van software. Bovendien kan de software worden bijgewerkt zonder dat gebruikers daar hinder van ondervinden.

Voor veel organisaties en het management betekent het werken in korte cycli dat het eindproduct bij de start van het project vaak nog niet helemaal duidelijk is. Dat vraagt iets van jouw leiderschap, namelijk het geven van autonomie en vertrouwen aan het ontwikkelteam en vooral niet zelf vooraf willen bepalen wat de exacte uitkomst moet zijn. Hierin moet je vertrouwen dat het team op basis van de probleemanalyse en een duidelijk ‘waarom’ met alle expertise aan boord de juiste keuzes zal maken. In mijn ervaring zijn de meest succesvolle projecten de projecten waarbij een hoogwaardig team een heldere richting en daarna de vrijheid en het vertrouwen krijgt om het werk te doen waarvoor ze zijn samengebracht.

Stap 4: Meet performance om het proces te optimaliseren

Door de performance van een team te meten op basis van elementen die volledig binnen de invloedsfeer van het team liggen, kan je het proces optimaliseren. High performance teams zullen eerder waarde aantonen, maar tot dat moment heb je een methodiek nodig om te zien waar je als team staat. Wij doen dat door software delivery performance te meten aan de hand van de 4-key metrics.

De 4-key metrics zijn:

• Deployment Frequency: frequentie waarmee nieuwe releases live gaan
• Lead Time For Changes: benodigde tijd om een feature live te zetten
• Mean Time To Restore: benodigde tijd om een probleem op te lossen in live applicatie of website.
• Change Fail Rate: verhouding tussen succesvolle implementaties en niet-succesvolle implementaties die leiden tot problemen.

Door deze metrics te meten en te monitoren krijg je na een tijdje inzicht in mogelijke verbeteringen in het proces en kan het team op basis van deze inzichten zelf gaan bijsturen.

Stap 5: Breng wendbaarheid en snelheid in de teams

De uitdaging voor management is in veel gevallen tweeledig: kan ik loslaten dat ik de exacte uitkomst van een project niet kan bepalen en is het ook voldoende als we iets lanceren wat nog niet helemaal perfect is?

Het is logisch dat je iets wilt lanceren waar anderen van onder de indruk zijn. Maar wat als je indruk kan maken met de snelheid waarmee jouw team kan lanceren? De snelheid waarmee je het product verbeterd? Dat men onder de indruk is van jouw manier van feedback toepassen? Dat levert misschien wel meer op bij collega's en klanten. Probeer verder te kijken dan de lancering, je bespaart jezelf veel risico door al eerder live te gaan. Zelfs als de reactie dan is “is dat alles?”. Een paar releases en weken of dagen verder heb jij je doel bereikt - waar andere teams die groot willen lanceren hun doel wellicht voorbij schieten.

Bij Worth bouwen we al 20 jaar teams en weten we hoe een goed en high performing software team eruit ziet. We weten wat het betekent om ook in grotere ontwikkelprojecten zo vroeg mogelijk te lanceren. We werken soms met verschillende teams parallel aan elkaar, met 50 man in totaal, aan projecten en programma’s voor commerciële bedrijven en overheden. En weten inmiddels goed hoe je daarvoor continuous delivery kan inrichten. We combineren software en technologie én de business om samen te bepalen welke waarde voor jouw organisatie kunnen creëren. In één team brengen we strategie en pragmatisme bij elkaar.