Skip to main content

Categorie: Agile

Met continue verbetering is niets onmogelijk

Geschreven door Andre Boeters op . Gepost in Agile, Scrum.

Processen en software kunnen continu verbeterd worden. Maar heb je wel eens nagedacht over hoe je zelf continu beter kan worden? Het principe van iedere dag een stapje beter zorgt uiteindelijk voor grote resultaten. Dezelfde aanpak kan zowel worden toegepast op je eigen verbetering als op werkproces verbeteringen.

Continue verbetering stamt uit de oosterse filosofie. Door iedere dag een klein beetje beter te worden kun je uiteindelijk grote resultaten behalen.

Kaizen

Een veelgebruikte implementatie van continue verbetering in het bedrijfsleven is kaizen. Dit Japanse woord betekent positieve verandering. Het hangt sterk samen met de organisatorische aanpak lean. Bij een lean manier van werken worden alle mensen in de organisatie gestimuleerd om op zoek te gaan naar een manier om het werken te verbeteren en moeilijkheden en drempels voor succes weg te halen. Men gaat hierbij op zoek naar wat “waste” genoemd wordt. Waste zijn alle dingen die productiviteit in de weg kunnen staan. Een manier om lean te werken in de softwareontwikkeling is agile in een scrumteam.

De kaizen gedachte van de continue verbetering stroomt door al deze frameworks heen. Er horen een aantal principes bij:

  • Als je iedere dag verbetert haal je grote resultaten
  • Iedereen is verantwoordelijk voor verbetering
  • Analyse is belangrijk om te meten wat er verbeterd is

Lean (manufacturing) komt van oorsprong uit de productie industrie. Het is vooral ontwikkeld bij Toyota. In zo’n fabriek ligt het voor de hand dat je grote winst kunt behalen door kleine verbeteringen in een proces dat zich heel vaak herhaalt. Als je het proces verbeterd van het maken van een onderdeel dat je 100.000 keer maakt dan zal de winst aanzienlijk zijn. In een serviceorganisatie waar software gemaakt wordt werkt dat misschien anders. Via het werken in een scrumteam zal je toch ook veel verschillende keren hetzelfde doen in de vorm van user story’s of product backlog items. De inhoud zal veranderen maar de vorm is hetzelfde. Er wordt binnen het scrum framework, maar bijvoorbeeld ook binnen het scaled agile framework toegewerkt naar backlog items die qua grootte en complexiteit vergelijkbaar zijn, zodat de verbeteringsprocessen hier vat op kunnen hebben.

Kwaliteiteitscyclus van Deming

Zoals je het werken in een team en oppakken en afronden van product backlog items kunt verbeteren, zo kun je je eigen gedrag ook verbeteren. Hiervoor kunnen we terug gaan naar de originele cyclus van Deming die beschrijft hoe je processen kan verbeteren in plan-do-check-act.

continue verbetering

Plannen bestaat uit het identificeren van een situatie die verbeterd kan worden. Bij Do implementeer je het plan. Dan check je de resultaten en bij Act kun je blijven bijsturen. Dit kun je ook in je eigen leven gebruiken wanneer je bijvoorbeeld een taal wilt leren, wilt stoppen met roken of snoozen of beter wilt leren koken.

Bij de ontwikkeling van een kind zit het continu verbeteren automatisch ingebakken. Iedere dag worden er nieuwe dingen geleerd. Eerst met observaties en daarna met veel oefenen. En letterlijk met vallen en opstaan.

Het uitvoeren van verbeteringen

Soms is het erg makkelijk om een plan te bedenken, maar is de uitvoer ervan nog niet zo makkelijk. Er zijn ontelbare to-do lijstjes volgeschreven met taken die nooit zijn uitgevoerd. Een manier om dit uitstelgedrag aan te pakken nadat je een plan hebt gemaakt is door je ideeën in kleine stukjes te hakken en het vervolgens in zogenaamde pomodoro’s uit te voeren. Hierbij werk je 25 minuten en neem je dan 5 minuten pauze.

Volg de Deming cyclus als volgt. Breng in kaart wat je zou willen verbeteren en hoe je dat kunt verbeteren (plan). Bijvoorbeeld wil je je te laat komen voor vergaderingen aanpakken. Je kunt je gedrag aanpassen door bijvoorbeeld op tijd een alarm te laten klinken voor een volgende vergadering (do). Houdt bij hoe vaak je nog te laat komt voor vergadering (check). Het is dan ook handig om vooraf een meting gedaan te hebben. Stel je doelen SMART op zodat je ook weet of je ze bereikt hebt. Wil je bijvoorbeeld 100% op tijd zijn, of misschien wel 5 minuten van tevoren? Of wil je alleen een verbetering zien. Als laatste stap kun je nog bijsturen als je je doelen niet behaald hebt (act). Het is opgebouwd als cyclus omdat je altijd wel iets kunt verbeteren. Je kunt dus weer een nieuw verbeterplan opstellen.

Een valkuil van deze manier van verbeteren is dat het gericht is op kleine stapjes. Het is ook belangrijk om af en toe een stapje uit te zoomen en out-of-the-box te denken. Misschien is het in ons voorbeeld ook wel slim om naar het aantal vergaderingen in je agenda te kijken of andere maatregelen te treffen.

Dit principe kun je natuurlijk voor allerlei activiteiten in je leven toepassen. De belangrijkste tips zijn:

  • Met kleine stapjes kun je grote resultaten halen
  • Maak een plan en meet of je het behaald hebt
  • Er is altijd iets nieuws te verbeteren

 

Agile Testen

Geschreven door Andre Boeters op . Gepost in Agile, Scrum.

Door een verschuiving van traditionele watervalmethoden naar een Agile benadering bij softwareontwikkeling, verandert ook de rol van de tester. Waar de watervalmethode gericht is op aparte afdelingen, een rigide blauwdrukplanning en volledige documentatie is Agile gericht op het mengen van expertises, het geven van vertrouwen en het verzorgen van kennisborging bij de teams. Deze ontwikkeling maakt het leven testers interessanter en zorgt ervoor dat testers van alle markten thuis moeten zijn.

Agile betekent letterlijk behendig. Software wordt ontwikkeld in korte perioden die dezelfde structuur hebben. In elke periode (sprint) wordt een werkend deel van de software afgeleverd. Dit wordt incrementeel en iteratief genoemd. Deze manier van ontwikkelen zorgt ervoor dat de business goed in kan spelen op de veranderende wensen van de consumenten en technologische ontwikkelingen.

Testers zijn bij Agile onderdeel geworden van Scrum teams. Dit zijn teams van minimaal drie tot maximaal negen leden bestaande uit een Scrum Master, een product owner en developers. Bij watervalmethoden waren testers ondergebracht in een aparte kwaliteitsafdeling, wat vaak leidde tot communicatieproblemen. Ook vond het testen later in het ontwikkelingsproces plaats waardoor herstelkosten opliepen. Bij Agile wordt er vanaf de eerste sprint getest.

Deze aanpak van ontwikkeling heeft implicaties voor de werkzaamheden van een tester. Ten eerste is de kennis van hoe software gemaakt wordt belangrijk. Voorheen hadden testers over het algemeen beperkte kennis van hoe programmeurs software maakten. Doordat programmeurs en testers bij Scrum in dezelfde teams ondergebracht zijn en dus ook developers worden genoemd, kunnen zij van elkaar leren. De tester leert code, de programmeur leert kritisch testen.

Ten tweede is kennis van businessprocessen voor de tester belangrijk geworden. Doordat de Scrum teams direct gekoppeld zijn aan de business, zal een tester ook verstand moeten hebben van businessprocessen. Zo kan de tester de eisen van een productowner beter begrijpen. De kans dat een product gemaakt wordt waar ook vraag naar is wordt daardoor veel groter.

Ten derde is automatiseringskennis van belang. Omdat Scrum incrementeel van aard is, moeten testers hun testen kunnen automatiseren. Na elke sprint wordt immers een stukje werkende software opgeleverd. Omdat deze software invloed kan hebben op andere delen van het systeem moeten de testen die initieel zijn uitgevoerd herhaald worden. Hier zijn regressietesten voor nodig die een groot deel van het systeem dekken. Het kost teveel tijd om dit handmatig te doen en het is geestdodend.

Samenvattend: De Agile ontwikkelingsfilosofie heeft ertoe geleid dat het werk van een tester interessanter is geworden. Testers worden van begin af aan bij ontwikkeling betrokken als developer. Hierdoor is er naast het uitoefenen van het testvak de kans om wat te leren over programmeren en over de business. Kortom, de tester wordt ook behendig.