DIY

How to Unleash the Data in your DevOps Tools to Drive Continuous Improvement

Andreas Prins
dog-running-through-leaves-150x150

Where are the weak spots in your software delivery chain? How are they affecting the value of the applications your company delivers? If you can’t answer these questions, you may be limiting revenue opportunities for your organization.

That’s because for most companies today, software delivery is the key source from which their value stream flows. So, continuously improving the end-to-end delivery process must be IT’s number one priority. The question is where do you start?

Maturity Models for Continuous Improvement

A quick Google search on “Agile Maturity Model” yields lots of results for how to drive continuous improvement. Some of them are based on educated guesses (but guesses nonetheless). The better ones are founded on questionnaires from a sampling of organizations, but rarely are they based on real data. These models will offer some insight in how to drive continuous improvement of your software process, but their effectiveness is limited, mainly because they’re not specific to your organization. For that you need real data about your own delivery process.

The good news is, if you’ve entered the era of continuous integration, deployment, and delivery, the data is probably already at your fingertips. You just need to know how to unleash it.

Read the full and original post at blog.XebiaLabs.com.

Een fantastische Agile Coach Lab Meetup vol met coachingstechnieken

Andreas Prins
coachlab
Wat een fantastische Coach Lab was dat. Het was een optelsom van leuke dingen. Een mooie locatie, de zon, inspirerende mensen, een nieuw netwerk en een geweldig onderwerp vormden de ingrediënten van een cocktail vol inspiratie.

Het was alweer even geleden dat ik een meetup had bezocht maar deze donderdagavond 11 mei was het dubbel en dwars waard. Met zo’n 20 (aspirant) coaches hebben we een avond kunnen oefenen met elkaar. Ik deel graag 4 lessen van deze Coach Lab die mij weer even op scherp zetten.

coachlab

Les 1: Rollenspellen zijn brilliant

Wat is het heerlijk om je even te laten gaan. Even die gefrustreerde manager te spelen die je altijd verstopt. Die Dev Engineer die het liefste maar wil programmeren of thuis wil werken. Een team dat geen team is en een coach die zelf harder werkt dan het object van de coaching. Een rollenspel is brilliant.

Continue reading →

Hoe je van een “acceptance phase” een “acceptance feest” kunt maken

Andreas Prins
Acceptance Feest
Of ik het wilde horen of dat ik verkeerd stond afgesteld weet ik niet, een engineer had het onlangs over een acceptance feest. Nadat ik het verifieerde, bleek dat hij het over een “acceptance phase” had. Een periode na de sprint van de DevOps teams waar de acceptant aan de slag gaat. In die phase gebeurt er veel maar het wordt nooit een feestje. Waar gaat het mis?

Waarom die fase alle feestvreugde weghaalt

Hier een aantal redenen waarom het volledig mis gaat bij een acceptatie (test) fase van de software nadat je al klaar bent.
  • De acceptanten beginnen pas na te denken over wat ze willen nadat ze iets krijgen. Het gevolg is dat eindeloze aanpassingen nodig zijn in de volgende sprint.
  • Mensen die bij de demo de acceptatie hebben uitgevoerd, worden overschreeuwt door de mensen die werkelijk accepteren. Het mandaat en pikorde blijken totaal anders te lopen.
  • In de magere jaren waarin software van mindere kwaliteit werd opgeleverd, was een acceptatie test van dagen, zo niet weken, broodnodig om goede software naar productie te krijgen. Dit patroon is nog niet doorbroken.
  • Er is geen verbinding tussen wat in de sprint is gebeurd en wat daarna gebeurt tijdens de acceptatie testen. Dit heeft enorm veel dubbel werk tot gevolg.
  • Er ontbreken duidelijke acceptatie criteria waar naar toe gewerkt kan worden. Het programmeren wordt daarmee bijna een “wild guess”.

Een dubbele domper

Je snapt wel hoeveel frustratie dit bij de engineers oplevert. Deze frustratie is echter geheel wederzijds.
Opmerkingen van de acceptant zoals de volgende zullen met grote regelmaat zijn uitgesproken.
  • Ze snappen me toch niet,
  • krijg ik weer niet wat ik echt nodig heb,
  • waarom heeft dit zolang moeten duren,
  • hoe kan het toch dat ik elke keer weer moet aangeven wat ik echt wil hebben,
  • waarschijnlijk zullen er toch wel weer fouten inzitten.

Suggesties ter verbetering om er een feestje van te maken

Het is eigenlijk vrij eenvoudig om er een acceptatie feest van te maken. Daarbij moet je de fase achteraf wel durven los te laten. Hier een paar kleine suggesties om er een feestje van te maken.
  • Werk aan een wederzijdse overtuiging en drive om het daadwerkelijk anders en beter te gaan doen. Dit is van groot belang om een mini transformatie als deze door te maken.
  • Plaats de acceptant in het team zodat hij kan werken aan de acceptatie criteria voor de user stories in de volgende sprint.
  • Gebruik een testing tool als Concordion of een framework als Cucumber om de Acceptance Test Driven Development mogelijk te maken.
  • Doe de acceptatie tijdens de demo aan het einde van de sprint en daarmee en daarna gewoon door productie. De kwaliteit is goed en afwijkingen detecteer je met monitoring.
  • Creëer een continue groter wordende set aan automatische regressietesten op alle niveaus, van unit testen tot en met GUI testen.

Waarom Agile-Scrum zo eenvoudig lijkt en zo moeilijk is

Andreas Prins
ruimte in je agenda

Wie de scrum guide heeft gelezen en het examen heeft gedaan zal hebben ontdekt dat scrum relatief eenvoudig is. Er zijn wat rituelen en principes die je moet kennen en je kunt aan de slag. Wie echter aan de slag gaat en het echt in de praktijk wil brengen ontdekt al snel dat de realiteit weerbarstiger is. Alleen met een hele hoge discipline gaan teams en organisaties vooruit op weg naar een altijd hoger wordende wendbaarheid.

En daar wringt te schoen, dat ene principe “een hoge discipline” is echt killing. Hoe vaak slipt de discipline er even bij in. Hoewel ik een blog heb geschreven over time management en het vrijmaken van je agenda zijn er perioden waar dit haast onmogelijk lijkt. Aandacht voor je werk, de teams en je collega’s schieten er bij in. In deze post een aantal zaken die er bij mij met grote regelmaat bij inschieten, en wat ik er aan probeer te doen. Ik ben benieuwd naar de dingen die er bij jou wel eens bij inschieten en of oplossingen om dit te voorkomen.

Blik naar buiten gericht om het binnen beter te maken

Intern verbeteren kan enorm worden versterkt door naar buiten gericht te zijn. Seminars volgen, netwerken en bedrijven of andere afdelingen bezoeken zijn ideaal om nieuwe ideeën op te doen en je eigen inzichten aan te scherpen. Je leert hoe andere organisaties bijvoorbeeld continuous improvement aanpakken of hoe ze omgaan met visueel management. Deze beide aspecten zijn van cruciaal belang om te groeien in je wendbaarheid.

Door allerlei interne zaken die ook belangrijk zijn schiet dit er echter nog wel eens bij in. Risk, budget en architectuur roadmaps zijn belangrijke zaken die je op orde moet hebben. Als je hierin achterloopt kost dit veel te veel tijd en energie.

Mijn suggestie is dan ook dat je gewoon tijd reserveert om naar buiten gericht te blijven. Verlaag desnoods de frequentie naar 1x per 2 maanden maar af en toe ergens op bezoek gaan als is het een uurtje is uitermate nuttig en leerzaam om te versnellen.

Continue reading →

3 Belangrijkste ingrediënten voor Continuous Compliance

Andreas Prins
Cruciaal bij Continuous Delivery

Het is al weer even geleden dat ik 5 redenen voor Continuous Compliance deelde, en de introductie gaf op dit onderwerp. Het jaar is inmiddels 8 maanden verder en zo ook de visie en inrichting van dit onderwerp.

In dit blog delen we met veel plezier de 3 belangrijkste ingrediënten voor Continuous Compliance.

  1. Maak gebruik van Build Breakers in de pipeline
  2. Zorg voor een goede segregatie van rechten
  3. Zet monitoring bovenop je pipeline

Een eerlijke onthulling

Persoonlijk ben ik het met nummer 1 volledig eens, nummer 2 en 3 vindt ik wat over de top. Ben je echter werkzaam binnen een omgeving waar Sox, audits en compliancy behoren tot de woordenschat van je bedrijf dan zul je er niet aan ontkomen om ze op te zetten. Als je dat doet, doe het dan goed en zo veel als mogelijk geautomatiseerd. Het ultieme doel is dat je er nauwelijks het omkijken naar hebt.

Maak gebruik van Build Breakers in de pipeline

Dit is echt een van de belangrijkste componenten om een veilige pipeline te hebben. Maar niet alleen veilige maar ook een pipeline die kwalitatief hoogwaardige software moet opleveren. Build Breakers zijn punten in je pipeline die ervoor zorgen dat de software niet wordt neergezet op omgevingen (Test en Acceptatie) verder in je pipeline als je niet voldoet aan bepaalde kwaliteitscriteria.

Door op deze manier te werken is er een garantie dat alles wat naar productie gaat ook daadwerkelijk de testen heeft doorstaan. Voor de auditors is dit echt een cruciaal punt. Deze manier van werken heeft twee grote bijkomende voordelen, de beslissing of iets naar productie kan gaan is in verre mate te automatiseren en het levert enorm snelle feedback cycles op voor iedereen in het proces.

4 Voorbeelden van build breakers:

  • Elke rode of oranje bevinding uit je static secure code analysis (op te zetten met Fortify SCA)
  • Een code coverage onder bijvoorbeeld 85% (op te zetten met SonarQube)
  • Een (API) regressie test die faalt (op te zetten met bijvoorbeeld Concordian)
  • Een performance daling van een stuk functionaliteit (op te zetten in Gatling)

Zorg voor een goede segregatie van rechten in je pipeline

Dit deel is eenvoudig en vanzelfsprekend. Een goede segregatie van rechten is een een hoog gereguleerde omgeving van cruciaal belang. Het komt er kortweg op neer dat je pipeline moet kunnen aantonen dat de persoon die de code maakt of aanpast niet de persoon is die de release naar productie kan aanzetten.

Continue reading →

Schalen van Agile is gelijk aan reduceren van complexiteit

Andreas Prins
reduceren complexiteit
Veel organisaties worstelen met het vraagstuk van Scaling Agile. Diverse frameworks zijn er op de markt om je ondersteunen in het schalen. Ze beloven je te helpen in de groei naar een Agile Enterprise. Frameworks vol met buzz-words en technieken om de complexiteit nog eenvoudiger te managen.

Als jij je organisatie echt wilt transformeren moet je complexiteit niet managen je moet het oplossen.

Ik zal heel eerlijk zijn, ik heb niet zoveel op met een aantal van deze frameworks. Mijn samenvatting: “Scaling Agile: You do not get LeSS if you play it SAFE“.

Een organisatie echter die in de transformatie elke keer opnieuw aandacht besteed aan het oplossen van complexiteit zal uiteindelijk de organisatie zijn die de hoogste wendbaarheid gaat behalen.

Laten we eerlijk zij naar elkaar, Agility is een buzz-word, omarmt door veel organisaties en een worsteling tijdens de executie.

Oplossen van complexiteit is cruciaal

Tijdens een workshop met een IT management team een paar weken geleden over de transitie naar een wendbare organisatie kwamen de diverse aspecten van complexiteit aan bod. De natuurlijke neiging van ons allemaal is om elke keer nieuwe processen te maken, piketpaaltjes te slaan en direct beschermende maatregelen te nemen als er ook maar iets mis gaat. Dit maakt het geheel er zeker minder wendbaar op.

Continue reading →

Als het leren je vergaat: te weinig tijd en toch willen verbeteren

Andreas Prins
analytical-and-creative-brain_23-2147506845

Een organisatie die vooruit wil, is een organisatie die bestaat uit individuen die zich blijven verbeteren. Als coach Agile coach adviseerde ik er lustig op los: maak tijd en ruimte anders verbeter je nooit.

Nu na bijna 2 jaar manager te zijn merk ik dat de praktijk lastiger is. Het leren vergaat ons bijna, zeker nu het einde van het jaar weer nadert ontstaan er allerlei andere prioriteiten.

Deze ontwikkeling is raar: het leren zou ons niet en nooit mogen vergaan!

Herken jij dit? Alle verbetering die je wil doen sneeuwt onder omdat er belangrijkere dingen zijn. En dan toch, mijn advies, plan het maar gewoon, ga het doen het komt er anders niet van. Juist daarover gaat deze blog.

Verbetering op het niveau van het team en individu

Voor teams die groeien in hun autonomie en een organisatie die meer een organisch geheel gaat worden blijft verbeteren en leren van groot belang.

Teams zullen zich altijd moeten aanpassen en ontwikkelen. Aanpassen aan de veranderende wereld om hen heen. Eisen vanuit wet- en regelgeving veranderen, werkzaamheden en verantwoordelijkheden nemen toe.  De roep om hogere efficiency die gevoed wordt door technologische ontwikkeling vraagt om ontwikkeling van activiteiten en vaardigheden van een team.

Een team dat stilstaat in zijn verbetering, gaat achteruit op de loopband die tijd heet.
De ontwikkeling op team niveau is mogelijk nog veel belangrijker. Neem bijvoorbeeld Dev Engineers, niet alleen de titel is gewijzigd van programmeur naar Dev Engineer maar ook het onderliggende takenpakket. We vragen en verwachten dat ze zich ontwikkelen op allerlei verschillende aspecten.
Dev engineers moeten uitgroeien tot Zwitserse zakmessen van Zwitserse kwaliteit.

En deze ontwikkeling kost tijd, maar waar vindt je die als je bordje met werkzaamheden ook al helemaal vol ligt.

Makkelijk gezegd, moeilijk gedaan

Het advies van HR, een senior manager, je Agile Coach of een loopbaanbegeleider is gemakkelijk gezegd en o zo moeilijk gedaan. De worsteling over te gaan tot executie en echt tijd vrij te maken kan soms zwaar drukken. Je wil wel ontwikkelen maar je ervaart de druk van de Product Owner of je (project) manager om te blijven leveren. Je snapt van nature dat als je als team of individu niet ontwikkelt je niet veel verder zult komen.

Continue reading →

Van “Fail Fast” naar “Learn Fast, Learn Often” om echt te verbeteren

Andreas Prins
Knowledge Empowers You Acronym

“Fail Fast” is een populair begrip geworden voor managers en DevOps teams. De belangrijke vraag is of “Fail Fast” nu daadwerkelijk waarde toevoegt. Of is Fail Fast een hol begrip geworden en gaat het ten diepste om hele andere zaken?

Om het nog persoonlijker te maken ik krijg de kriebels van mensen die “Fail Fast” als motto hebben gekozen om van tijd tot tijd te inspireren en te laten zien dat ze fan zijn van autonome teams.

“Fail Fast” wordt misbruikt om maar wat te proberen

Hoor jij het vaak om je heen “Fail Fast”? Het is zo een hip begrip wat te pas en te onpas wordt ingezet. Fouten worden daarmee goed gepraat en slechts weinig geleerd.

“Fail Fast” is een hol begrip geworden omdat het doorgronden waar het nu daadwerkelijk om gaat ontbreekt. Uiteindelijk gaat het helemaal niet om het feit dat je snelt moet falen. Waar mogelijk moet je falen voorkomen om je doelen zo efficiënt als mogelijk te behalen.

Het begrip “Fail Fast” zonder verdere kaders staat gelijk aan “Burn Fast”. Het verbranden van je waardevolle capaciteit en creativiteit.

“Learn Fast, Learn Often” is daadwerkelijk van belang om te groeien

Het is van groter belang om vooral snel, vroeg en vaak te leren. Wil je daadwerkelijk groeien dan zul je de experimenten die je doet heel bewust en zorgvuldig moeten uitvoeren. Niet zomaar wat proberen en dan zien wat er van terecht gaat komen. Continue reading →

Ik ben een stoorzender! Jij toch niet?

Andreas Prins
meeting_manager

BAM, die titel heb ik even nodig als reflectie op de lessen die ik leerde uit de TED talk van Jason Fried: Why work doesn’t happen at work.

In een talk van 15 minuten gaat Jason in op het feit waarom thuiswerken super effectief kan zijn. Hij komt hier tot de pijnlijke les dat M&M’s de belangrijkste stoorzender zijn. Managers en Meetings zorgen voor actieve verstoringen en die zijn er thuis simpelweg niet.

Het verschil tussen actieve verstoringen en gekozen momenten

Jason gaat in zijn talk in op de plekken waar je lekker, ongestoord kan werken. Verrassend beantwoorden de meeste mensen dit met thuis, in het vliegtuig of ze komen met een tijdsaanduiding zoals “zaterdagmorgen in alle vroegte”.

Het grote verschil met kantoor en de genoemde plekken is dat we op kantoor actief gestoord kunnen worden. Op alle andere plekken heb je dat zelf in de hand. Je kiest zelf om naar de koelkast te lopen op het moment dat het je uitkomt.

De actieve verstoringen op het werk komen van de manager of van meetings. Vragen van je manager even iets op te pakken en af te maken, of dat overleg al is het maar 30 minuten verstoord je werkzaamheden.

Zelf gekozen breaks op momenten dat ze effectief zijn

Op het eerste moment dacht ik ja-maar soms zijn deze zaken toch nodig. Hoe nodig sommige ook zijn ze halen anderen uit hun flow. Het werk van vandaag de dag vraagt met grote regelmaat tijd om na te denken. De puzzel op te lossen voordat je de tekening maakt, de nieuwe code schrijft of een tekst uit je vingers vloeit. Continue reading →