Author: Andreas Prins

Keynote Open Techday 2017

Andreas Prins
onstage

21 April had ik de eer om een keynote presentatie te mogen geven op de Open Techday. Een nieuwe conferentie gericht op het delen van kennis en informatie rondom het onderwerp Open. Open Source -data -organizations -future zijn zomaar wat topics die deze dag centraal stonden. Met meer dan 550 bezoekers een top event.

De moraal van mijn verhaal op deze dag “You can have great technology available but if you can’t change the behaviour of your organisation it’s worthless.” In de keynote kwamen een aantal lessen langs van organisatie transformatie. Lessen die we hebben geleerd in de journey van de afgelopen jaren.

Hieronder de slides, wat statements uit de speakers notes en wat reacties van een aantal bezoekers.

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.

Dag manager, welkom parttime leider

Andreas Prins
managers_leiders_small
Zijn managers nog nodig als je bouwt aan autonome teams die veel keuzes zelf nemen? Moet er nog veel worden gemanaged als de teams het zelf kunnen?

In een organisatie transformatie waarbij je echt wilt verbeteren neemt het aantal managers af en het aantal leiders toe. Als ik zeg leiders heb ik het niet over een semantische vervanging van het woord managers. De rol verandert en de vraag is of jij een leider wordt.

parttime leiders

Eerst twee concrete voorbeelden om te ontdekken waarom managers afnemen en de leiders toenemen.

Managen van out of control naar leiden in control

Als ik terug denk aan hoe de status van ons “control framework” een jaar of 3 geleden was dan scoorden we in excel netjes groen. Onder de motorkap moest je niet altijd willen kijken. Het hing van geaccepteerde risico’s aan elkaar. Een geaccepteerd risico lost natuurlijk niets op.

Twee jaar geleden vonden we dit niet langer acceptabel en zijn we de dingen echt gaan oplossen. We deden dit met regelmaat nog wel te laat maar de geaccepteerde risico’s werden opgelost.

Hoe meer we de teams verantwoordelijk maakten hoe dieper in de systemen de problemen echt werden opgelost. Vorig jaar scoorden we bijna alles groen en werden risico’s items op tijd gesloten en ook nog eens echt opgelost. We zijn daadwerkelijk veiliger geworden in plaats van dat we de risico’s managen.

Van de positie in control zijn is de volgende stap in control blijven en nog verder verbeteren. Als leider dit vooruitzicht schetsen en doelen duidelijk maken helpt de teams het beter te begrijpen en daar actief aan bij te dragen. Een dagelijkse coördinatie en aansturing is niet langer nodig.

Het managen van het verleden is daarmee niet meer nodig en slechts het schetsen van de toekomst is voldoende om vooruit te gaan.

Managen van voortgangsrapportages voor vandaag naar leiden van de feature planning voor morgen

Hoeveel tijd besteed jij nog aan het opstellen of lezen van voortgangsrapportages om eens wat te noemen? Geloof me dit is echt een verspilling van ieders waardevolle tijd. Je kunt beter werken aan de voorspelbaarheid van je teams op korte en langere termijn. Als je daarnaast ook nog eens vaker het gesprek aan gaat met alle mensen om je heen wat nu werkelijk waarde heeft kun je starten met de feature planning. Continue reading →

Transforming an organization at scale, introducing the D.O.T. Model

Andreas Prins
deep organisational transformation

Many great books are available describing organisational transformation. Each of them has a particular focus from culture, way of working, Continuous Delivery towards waste reduction. Some of them focus on Agile, Scrum, Lean Startup or at the Spotify Model (as some people have named them).

Transforming an organisation at scale is not a simple task. It requires leadership, perseverance and a continual focus on improvement. Not for a month, not even a year, but many years in order to achieve success. Transforming an organisation is like driving on route 66; you have a clear focus but it seems a never-ending road with a lot of dangerous situations throughout the ride.

Many of these changes start with a focus on Scrum, Continuous Delivery or frameworks to slice and prioritise work across multiple teams. The questions I get from time to time are how are all these instruments or hypes are related to each other. What is of value in transforming your organisation? I’ve summarised the most important elements in the D.O.T. Model, a model that gives instruments for Deep Organisational Transformation.

The Deep Organisational Transformation Model

This model does not hold any new instrument but combines existing instruments in a framework of 4 layers, which describe the total scope of an organisation. I’ve learned that if you want to change an organisation, it’s not only the teams that should change. Everyone should bring sacrifices, processes should be simplified and waste must be removed. Only if this is applied from the individual employee all the way to the deep roots of your large company can an organisation can change.


 

Each of the 4 layers require a different focus

The model describes 4 layers:

  • The individual employee
  • The teams with +/- 8 employees
  • The domain with +/- 1200 employees
    The organisation with 1200+ employees.

As you can imagine, each layer has its own focus area. Focusing on simplicity, flow, experimentation and autonomy are some of them. To transform your organisation these are areas you need to constantly focus on. The focus areas are closely related to one another. The items that should be reduced on each level have an enormous impact on the things that you want achieve.

A set of instruments that really matter by transforming your organisation

There are so many buzzwords out there in the Agile world, and also a lot of instruments. If you really want to change your organisation, some of them matter more than others.

On the D.O.T. model, each layer is given 3 of the most important instruments for your transformation. When applying these you’ll discover a slow but steady change of your organisation.

If you need more information about this model, please have a look at the Slideshare above.

Purpose of the D.O.T. model is to give an overview

The purpose of the deck is not to be exhaustively in all the items that are involved in an Agile transformation. It is also not the aim of this blog or the slides to describe a complete transformation. The simple purpose is to give a clear overview of all items that matter during a transformation.

Normally I do publish in Dutch but this time I choose English to reach more people. Other posts will be in Dutch again.

whatsapp meDo you want to receive a WhatsApp message if a new post is published? 
Please send me a message to +31645112490

Veilige software in productie dit is wat je moet doen

Andreas Prins
security_framework_total

Het is erg gemakkelijk gezegd tegen teams dat ze veilige software moeten opleveren veel moeilijker is de uitvoering van deze opdracht. Het opleveren van veilige software is in grote organisaties of organisaties die aan allerlei wet en regelgeving vallen soms een worsteling.

Teams in mijn omgeving zie ik ook worstelen met de vraag wat veilige software dan eigenlijk is. Als je streeft naar autonome teams zul je ze ook maximaal verantwoordelijk moeten maken voor de veiligheid van hun software en omgeving. Maar hoe kun je ze verantwoordelijk maken als je niet eens weet wat er allemaal speelt of als je niet weet hoe alle driecijferige afkortingen gerelateerd zijn aan elkaar. Ik maakte een eenvoudig overzicht van de meest belangrijke zaken.

veilige software bouwen

Creating the software

Het maken van software is een proces waar veiligheid een cruciale rol speelt. Het 4-ogen principe voordat je code merged naar je master branch en Static Code Analysis gericht op secure code zijn twee belangrijke aspecten. Ik heb hierover diverse blogs geschreven (1.Drie belangrijke ingrediënten 2.Vijf reden voor Continuous Compliance)

Running the software and the environment

Als de software eenmaal in productie draait is het zaak dat je dit ook continu controleert. Een pentest gericht op je applicatie, database, middleware en infrastructuur kunnen je hier elk half jaar in ondersteunen. Continue je omgeving scannen met een vulnerability scanning geeft je inzicht in mogelijk zwakheden. (overigens moeten teams hier ook hun footprint proberen te minimaliseren, wat je niet gebruikt zet je uit).

Security Event Monitoring en Technical State Compliancy Monitoring zorgen ervoor dat je weet wie wat wijzigt en geen oneigenlijke wijzigingen worden doorgevoerd. De integriteit en betrouwbaarheid worden hierdoor gewaarborgd.

Continue reading →

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 →

7 suggesties voor een schaalbare continuous delivery pipeline

Andreas Prins
cd_pipeline

Een Continuous Delivery Pipeline als onderdeel van een Agile transformatie is gelijk aan de kruiden in een smaakvol gerecht. Bij ontbreken er van is het waardeloos en smaakt het naar niets. Is het aanwezig dan smaakt het naar meer, werkt het als stimulans en geeft het energie. Het is echter niet eenvoudig om de juiste kruiden bij het juiste gerecht te vinden.

Een basis van peper en zout is er nagenoeg altijd echter kun je niet altijd kurkuma, steranijs, gember of koriander inzetten om de boost te geven. Je moet met zorg een combinatie selecteren om je gerecht echt smaakvol te maken. Zo is het ook bij de tools die je onderdeel wilt maken van je continuous delivery pipeline.

Een continuous delivery pipeline is niet zomaar iets, het kan geen verzameling van tools zijn zoals de kruidenla in je keuken. Afhankelijk van de doelen die een team heeft kies je bepaalde tools wel en niet. In deze post deel ik 7 suggesties met je om een echte chef te worden.

  1. Voorkom de creatie van een monoliet
  2. Balanceer tussen verplichte en vrijwillige componenten
  3. Benader een CD pipeline niet als een verzameling tech tools maar als een value stream
  4. Gebruik de MVP approach in de opbouw van je pipeline
  5. Omarm een model waarin experimenten eenvoudig te realiseren zijn
  6. Limiteer het bouwen van eigen oplossingen, er is zo veel goeds op de markt
  7. Richt je CD pipeline in alsof het de meest kritische software is

Suggestie 1: Voorkom de creatie van een monoliet

Applicaties als monolieten zijn mogelijk ergens achterin je IT landschap nog best wel hanteerbaar. Hoe meer je naar de voorkant gaat en interactie zoekt met je klanten hoe meer last je krijgt van die grote monolieten in je landschap. Ze kunnen je wendbaarheid soms lastig in de weg zitten.

Ga je aan de slag met het maken van een CD pipeline bedenk dan goed dat deze pipeline misschien wel DE omgeving is die het hardste gaat veranderen in de komende tijd. Tools komen en gaan, frameworks dwingen je om je aan te passen en compliancy zit niet alleen meer bij een afdeling maar is als zuurstof voor je organisatie geworden. Een monoliet is maar weinig wendbaar weten we uit het verleden. Voorkom dus de creatie van een CD Pipeline als monoliet.

Continue reading →

Hypothese: elk team heeft een conjunctuur! Herkenbaar?

Andreas Prins
conjunctuurcyclus
Na 3 jaar met en naast ttcrum/DevOps teams te hebben gewerkt weet ik het zeker, teams hebben een conjunctuur. Teams gaan lekker en dan na een paar maanden gaat het weer even wat minder, ze zakken terug in hun performance, focus en discipline. Hoe kan dit, waar komt het door, is het erg en wat kan je er aan doen.

Ik heb hierover 3 vragen voor je:

  • Herken je dit?
  • Wat zouden mogelijke oorzaken hier van zijn?
  • Wat kun je doen om op een hoogtepunt weer een nieuwe groei in te zetten?

Voorbij: Forming – Storming – Norming – Performing

Bruce Tuckman publiceerde al in 1965 een model met 4 stadia waar een team door heen gaat als ze een team gaan worden. Voor mij is dit model nog steeds een valide model. Een team moet er zwaar en diep doorheen als ze helemaal nieuw zijn. Maar ook elke keer bij een wissel van een teamlid zul je even moeten wennen aan elkaar. Een nieuw lid brengt immers weer even verwarring in de pikorde.

Grood beschrijft dit in zijn boekje “Agile in de echte wereld, starten met scrum” (link) een model waarin teams doorheen moeten aan de start. Hierin is een dip nadat de euforie voor scrum is doodgeslagen door de naakte waarheid van de organisatie (systeem) waar dit team onderdeel van is. Ik heb het nadrukkelijk niet over deze eerste dip maar over de golven die daarna komen.

Het vreemde is echter dat de conjunctuur die ik zie plaatsvind na de Performing fase. Gewoon na een paar maanden of paar jaar als een team lekker aan het werk is. Ik heb het dan over stabiele teams die voor langere tijd met elkaar samenwerken. Waarom en waardoor vindt dit plaats?

De conjunctuurgolf van het team

Het lijkt wel alsof elk team zijn vaste conjunctuur heeft met zo’n twee hoogte punten per jaar. Een hele golf duurt dus ongeveer 5-7 maanden. Richting de piek van de golf zit de flow en spirit er goed in. Het team levert veel, zit vol energie en heeft een hoge voorspelbaarheid. Richting een dal is de geest uit de fles, worstelen ze met delivery en is de voorspelbaarheid erg laag en is dit zichtbaar op het teambord met veel werk tegelijk onderhanden en pairen, dat doen ze bij de koffiebar.
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 →