Development

Dit is een bijdrage van Tricentis
Governance
Verandering begint aan de top

Innovatie bewerkstelligen met vereenvoudigde verandering

Faal snel, verbeter snel.

7 september 2022
Door: Tricentis, partner

Faal snel, verbeter snel.

Wat is uw eerste gedachte als u de term ‘rollout’ hoort? Roept het woord meteen een gevoel van angst op? U bent de enige. Rollout betekent dat er verandering op komst is. Een nieuw ontwikkelingsproject of softwarelancering staat voor de deur. Velen van ons hebben een natuurlijke afkeer van verandering. We zetten onze hakken in het zand en grijpen naar alle bezwaren om te voorkomen dat het gebeurt.

Maar verandering is een dwingende vereiste als een bedrijf wil schalen en groeien. Verandering introduceert innovatie in een organisatie. Het zorgt voor rollouts die modernere producten opleveren die beter aansluiten bij de huidige behoeften van de klant.

Dus, hoe krijgt een onderneming haar teams aan boord met verandering? Het lijkt misschien een beetje tegen-intuïtief, maar organisaties zouden de frequentie van veranderingen moeten opvoeren - totdat ze onmerkbaar worden.

Net als het proces van opgroeien, moeten we een ‘waar is de tijd gebleven’ mentaliteit naar de software delivery ervaring brengen. Dit betekent niet dat we elke keer perfecte releases moeten opleveren, maar het betekent wel een vereenvoudigde veranderingsaanpak voor het opleveren van software die een cultuur van snel falen en snel verbeteren mogelijk maakt.

Stapsgewijze veranderingen in evenwicht brengen

Ouders hebben de neiging de dagelijkse groei van hun kind niet op te merken. Maar bezoekende familieleden die het kind niet regelmatig zien, zijn vaak vol ongeloof over de groeispurten.

We kunnen ons niet bewust zijn van verandering als we een regelmatige, actieve deelnemer zijn.

Overweeg dezelfde denkwijze toe te passen op teams die misschien weerstand hebben tegen verandering. Hoe sneller u met vertrouwen kunt releasen, hoe minder merkbaar de reis naar het grotere initiatief wordt.

Natuurlijk is er een drempel waarboven een verandering te omslachtig wordt voor eindgebruikers. Om te voorkomen dat de veranderingstolerantie het point-of-no-return bereikt, kunt u de oplevering opdelen in kleinere stappen van driemaandelijks, maandelijks, wekelijks of zelfs dagelijks, om ervoor te zorgen dat er niet te veel wordt geïntroduceerd in een enkele release.

Deze methode vereist metriek die de hoeveelheid voorgestelde verandering binnen elke release beoordeelt en de impact op het productiesysteem meet. Zo zullen bijvoorbeeld snellere releasetijden nodig zijn voor toepassingen die meer veranderingen ondergaan.

Er is een unieke strategie die u kunt gebruiken om het juiste evenwicht te vinden tussen de incrementele veranderingen versus de kosten van implementatie om de juiste mijlpalen te halen. Het basisprincipe is dat hoe groter de reikwijdte en hoe breder de impact, hoe meer planning, communicatie, enablement, testen, enz. vereist zullen zijn. Het kan meer tijd kosten om deze discrete activiteiten te orkestreren.

Het grootste risico schuilt in de testinspanning en de daaropvolgende ontwikkelingsactiviteiten om de gevonden problemen op te lossen. Wanneer het herwerken de beoogde deliverable overschrijdt, wordt een release uitgesteld tot het volgende implementatie window, wat de impact van de daaropvolgende productieverandering vergroot en de gebruikershinder vergroot. Het succes van het halen van een beoogde release datum hangt af van de snelheid van deze feedback loops.

Verandering die niet evenredig verdeeld is over de software ontwikkelingscyclus zorgt voor een grote verschuiving in de dagelijkse ervaring van een gebruiker. Het verhoogt de kosten van hypercare om de adoptie te ondersteunen, leidt tot meer productiesupport cases om te onderzoeken, overspoelt support resources met change management tickets, en vertraagt de oplostijden voor technische problemen.

Hoewel ondersteuning van releases nog steeds nodig is, kan het volume van verandering sterk worden verminderd door de snelheid van levering, waardoor minder middelen nodig zijn. De relatieve hoeveelheid verandering en continue levering leiden tot minder verstoring en dus minder vragen om hypercare.

Als verandering fout gaat

Verandering wordt moeilijker als er negatieve gevolgen aan verbonden zijn.

Laten we bijvoorbeeld eens kijken wat er gebeurt als er fouten in de code zitten. De vuistregel is ongeveer 15 tot 50 fouten per 1.000 regels geleverde code. Het volume van codewijzigingen correleert met het aantal potentiële defecten.

Veel van deze defecten zullen worden ontdekt in verschillende stadia van het testen en aangepakt voorafgaand aan een release. Afhankelijk van de hoeveelheid en de kwaliteit van de code, kan deze onderneming resulteren in een aanzienlijke hoeveelheid herbewerking en een nooit eindigende loop van defect management. De verstoring kan de eindgebruiker ervan weerhouden de waarde van de nieuwe functionaliteit in te zien.

De methodologische verschuiving van waterval naar Agile werd verondersteld de impact van deze verstoringen te verminderen. De korte duur van de ontwikkelingssprints beperkte het aantal afgeleverde regels code. Theoretisch zou de Agile-methodologie de omvang van het testen moeten hebben beperkt door de beperking van de veranderingen. De snelheid waarmee testen worden uitgevoerd is echter vaak onvoldoende in verhouding tot de deadlines van Agile-sprints.

Uiteindelijk zullen veel Agile praktijken een hybride model aannemen met verschillende ontwikkelingssprints die plaatsvinden voorafgaand aan een enkele iteratie van testen. Dit brengt het paradigma alleen maar terug naar een hoger niveau van defecten als gevolg van de regels code die worden opgeleverd voorafgaand aan het testen.

Het komt erop neer dat hoe langer het ontwikkelingsvenster is, hoe meer veranderingen er zijn tussen kwaliteitsbeoordelingen in en dus hoe meer kans op defecten - wat leidt tot een grotere herkenning van veranderingen door eindgebruikers binnen het softwareleveringsproces.

Aandacht voor gebreken

Hoewel het misschien niet mogelijk is om alle defecten te beperken, moet het risicoprofiel van het testen voldoende zijn om een significante impact op de bedrijfsactiviteiten te vermijden. Maar zelfs niet-kritieke defecten kunnen nog steeds een negatieve impact hebben op gebruikers en de algemene perceptie van de release. Hoewel er voor deze defecten werkoplossingen bestaan, zorgen ze vaak voor een ongemakkelijke gebruikerservaring of zijn ze specifiek voor een kleine groep gebruikers.

Wanneer de verandering vereenvoudigd is en snel opeenvolgend wordt opgeleverd, worden defecten snel aangepakt vanwege de snelle opeenvolging van releases. Wanneer de verandering vertraagt, kunnen ook de verwachte oplostijden afnemen. De verbeteringen in de features zullen minimaal zijn in vergelijking met de oplostijd van een defect als de release windows te ver uit elkaar liggen. Bovendien kan het aantal vrijgegeven defecten een directe impact hebben op de release kadans.

Zodra het herstelwerk om defecten op te vangen de in-sprint feature ontwikkeling overstijgt, kunnen de release plannen in een impasse geraken. Om de kwaliteit van de applicatie te herstellen, moeten alle defecten worden aangepakt, wat resulteert in een grotere investering met minimale winst. Daarom is het noodzakelijk om ervoor te zorgen dat uw kwaliteitsproces centraal staat in de kadans van releases.

Agile leiders mondiger maken

Verandering begint aan de top en sijpelt door naar de teams. Hoe deze veranderingen in de initiatieven van een bedrijf worden gecommuniceerd, maakt een verschil voor hoe ze worden ontvangen.

Het is van cruciaal belang ervoor te zorgen dat er een collectieve afstemming is op de doelstelling van de totale verandering. Het helpt om grote software rollouts op te splitsen in een beheersbare set van specifieke deliverables in plaats van brede initiatieven. Dit geeft managers en individuele medewerkers een richtpunt om hun deliverables tegen te beheren en produceert een proces van kleine incrementele veranderingen.

Leidinggevenden moeten in staat zijn de punten te verbinden tussen de stapsgewijze veranderingen en het grotere geheel. Het is vergelijkbaar met hoe een plaatje op een legpuzzeldoos wordt gebruikt om de locatie van een specifiek puzzelstukje te oriënteren. Hoe meer kwaliteit rond het plaatje, hoe minder vage veronderstellingen over de individuele deliverables en een gevoel van minder inherent risico.

Het afstemmen van vereenvoudigde verandering op effectieve technologiedoelstellingen kan duidelijkheid scheppen voor de organisatie. De ideeën van het stimuleren van concurrentievoordeel, groeiende zakelijke betrokkenheid en het opnieuw uitdenken van activiteiten zouden aan de basis moeten liggen van alle IT-uitkomsten. De uitvoerende initiatieven worden dan afgestemd op het resultaat, de directeuren oriënteren de projecten op de initiatieven, en de managers creëren de actie-items.

Om deze visie van vereenvoudigde verandering mogelijk te maken, begint u met de middelen in handen te geven om buiten de strikte richtlijnen te treden. Laat hen acties ontdekken en uitvoeren die in lijn liggen met het resultaat dat zij moeten leveren.

Om vereenvoudigde verandering te bereiken, ontwikkelt u de kwaliteit van uw technologie-levering terwijl u de afstemming op een kernset van uitvoerende resultaten handhaaft. Deze veranderingen moeten snel worden doorgevoerd om verstoring van de eindgebruikers tot een minimum te beperken en bescherming te bieden tegen het risico van een defect dat een bedrijfsstoring kan veroorzaken.

De aanvaarding van niet-kritieke defecten zal aanvaardbaarder zijn wanneer de oplossingstijd in de volgende release kan worden bereikt. Ervoor zorgen dat werklasten niet worden overspoeld met defecten is een must om de orkestratie van vereenvoudigde verandering te beschermen.

Door kwaliteit centraal te stellen en veranderingen snel en stapsgewijs door te voeren, zullen uw gebruikers wellicht positiever staan tegenover het woord uitrol.

Reactie toevoegen