Agile

Veel organisaties denken dat ze al volledig agile zijn, maar vaak blijkt dan in de praktijk dat de transitie nog niet helemaal is afgerond. Waarom is het toch zo lastig om te veranderen? Met name het transformeren van hele afdelingen of organisaties vereist veel discipline en een lange adem. Agile werken betekent nieuwe gewoontes aanleren: consequent zijn en blijven in het toepassen van (agile) technieken. Met alleen de theorie kom je er niet. Het is een kwestie van doen!

In de komende weken beschrijf ik in een aantal blogs mijn eigen ervaringen op dit gebied. In deze eerste blog licht ik toe hoe er binnen de organisatie waar ik werkzaam was zowel agile elementen als aspecten van de waterval methode werden toegepast.

Wendbaar organiseren

Situatieschets: Als agile test engineer werk ik in een multidisciplinair team bij een klant van Bartosz. Het team ontwikkelt software, vaak voor een groot en complex enterprise informatiesysteem. Binnen de opdracht ben ik verantwoordelijk voor de user stories tot en met de uitrol naar een productie-achtige omgeving.

De visie van mijn opdrachtgever is om wendbaar te worden, zodat er in de toekomst flexibel op veranderingen ingespeeld kan worden. Als de inzet van IT hierbij een sleutelrol speelt, dan is agile werken en DevOps haast onvermijdelijk. Maar nu lijkt het erop alsof de organisatie bang is om te veranderen. De logheid van de organisatie, zoals de verschillende managementlagen en de vele formele procedures, stagneert de transitie naar de gewenste wendbaarheid. Ondanks dat zowel de organisatie als het specifieke team waarin ik werk, beweert reeds agile te zijn, ben ik van mening dat we nog een lange weg hebben te gaan.

Agile elementen binnen een waterval methode

In de omgeving waar ik werk zijn verschillende agile-facetten geïmplementeerd. Bijvoorbeeld het werken in iteraties bij het opleveren van software (scrum framework). Andere voorbeelden zijn de toepassing van een Kanbanbord, pair-programming, ATTD en Lean. Echter, de manier waarop we werken en zaken met elkaar afstemmen is niet zo agile. Zo worden voorgestelde verbeteringen na een retrospective wel opgepakt. Het monitoren van deze veranderingen, wat eigenlijk een continu proces zou moeten zijn, verdwijnt meestal al na een aantal sprints.

“Testen is geen fase maar een continu proces en dat probeer ik mijn team duidelijk te maken.”

Ook blijft het lastig om definitief afscheid te nemen van concepten uit het waterval tijdperk. Zo bestaat er een testbeleid dat op organisatieniveau geschreven is en dit beleid bevat bijvoorbeeld TMap NEXT onderdelen. Überhaupt past het schrijven van een ‘lijvig’ document niet bij de agile manier van werken. Maar ook binnen ons team zie ik waterval elementen terugkomen. Zo wordt er geregeld getest na het ontwikkelen van de software, terwijl je eigenlijk zoals bij pair-programming als test engineer tijdens het ontwikkelen wil meekijken met de developer. Om zo tot kwalitatief nog betere programma code te komen. Daarnaast komt het ook voor dat er veel te vroeg, maanden van te voren al, een user story gemaakt wordt. Op het moment dat het team deze user story wil oppakken, blijkt dan dat opeens de behoeften vanuit de business door nieuwe inzichten veranderd zijn. Een ander overblijfsel uit het waterval tijdperk is dat er grote hoeveelheden code van één user story ingecheckt worden. ‘Big-bang check-ins’ heb ik het genoemd. Zulke check-ins gaan gepaard met lange hersteltijden wanneer de CI-build dan breekt. Tot slot worden code reviews niet meteen opgepakt waardoor er onnodig vertraging komt in de procestijd en doorlooptijd. Hierdoor wordt de flow of work-in-progress van de betreffende user story benadeeld.

Niet denken maar doen!

Hoe zorg je er nou voor dat er meer ‘agility’ in het team komt? Om deze verandering in gang te zetten kun je het concept uit Lean inzetten, namelijk: werken zonder verspilling. Verder is het een kwestie van doen! Een verandering vindt niet plaats door elkaar te vertellen dat je kennis hebt van agile. Want als je de theorie kent wil niet zeggen dat je het kunt. Je moet het ook daadwerkelijk doen en toepassen.

In mijn volgende blog beschrijf ik drie concrete activiteiten die daadwerkelijk verandering teweeg brengen en zorgen voor meer efficiëntie en wendbaarheid in het team.

Poll

Is jouw organisatie volledig getransformeerd naar Agile werken?

Bekijk resultaten

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Bartosz_Header_004

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Bijtanken bij Bartosz

Gamification

Jan25

Software testen is geen handwerk maar keihard denkwerk. We maken een mentaal model van hetgeen we aan het testen zijn en aan de hand daarvan gaan we op zoek naar hoe we dat model kunnen kraken. Belangrijke skills die je hierbij nodig hebt zoals Critical Thinking en Problem Solving kun je ontwikkelen.

Ben je in staat om je analytische vaardigheden in te zetten om een puzzel op te lossen of een algoritme te kraken? Kun je onder woorden brengen wat de oplossing was? En wat was je aanpak was om de uitdaging aan te gaan?

Zo kennen we verschillende vormen van Gamification binnen het testvak. De eerste Bijtanken bij Bartosz van 2019 laat zien welke spelvormen we daarbij inzetten en waarom we daar zoveel waarde aan hechten. Maar we gaan vooral ook doen!

Mijn Paarsz