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

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

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

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

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?

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

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

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

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

Explorer Maps, een krachtig instrument van strategie naar executie

Weet jij wat de (IT) strategie van je bedrijf is? Wat merk je van de realisatie hiervan op de plek waar je werkt? Explorer Maps zijn het instrument dat we sinds driekwart jaar gebruiken om de theoretische strategie daadwerkelijk uit te voeren.

Je herkent de worsteling misschien wel die ik ook zie bij leiderschapsteams om de strategie daadwerkelijk uit te voeren. Er zijn zoveel andere zaken die de aandacht vragen dat de uitvoering van de grootse plannen er nog wel eens bij in schiet.

Wij zijn trots op hoe het ons steeds beter lukt om de strategie met onze Explorer Maps tot leven te laten komen. Al het materiaal is Open Source beschikbaar en delen we graag met je.

Het concept van de Explorer Maps

Explorer Maps zijn in essentie heel eenvoudig. Het gaat er vanuit dat je een duidelijke visie hebt en nog niet exact weet hoe je die zou moeten realiseren. Is dit niet het geval bij bijna elke strategie als je heel eerlijk bent? Je hebt een Big Goal die verder in de tijd staat. Om hier te komen gaan we ontdekken welke Actions we moeten uitvoeren. Onderweg kom je Next Goals tegen dit zijn doelen die je behaalt op weg naar de Big Goal.

Door kleine acties en volgende doelen te definiëren ontdek je stap voor stap wat nodig om bij het grote doel uit te komen. Het gaat er vanuit dat we niet alle kennis hebben om te bepalen hoe we ons doel behalen. We hebben te maken met een “knowledge threshold“. En dat vindt ik een geweldig principe.

Laten we eerlijk zijn naar elkaar, een strategie is gaaf op papier maar als je niet in staat bent deze te realiseren is het weggegooid geld.

Tegelijkertijd is dit zeker niet het excuus om maar wat aan te modderen. Het gebruik van de Explorer Maps vraagt om enorme discipline. Elk kwartaal kijken we terug op wat gerealiseerd is en wat niet en daaruit plannen we nieuwe Goals en Actions. Elke week opnieuw voer je nieuwe acties uit om zo de strategie tot leven te laten komen.

In het hele denkproces breng je ook in kaart wat de obstacles zijn die je tegenhouden om acties uit te voeren of doelen te bereiken. Deze kun je stoïcijns negeren en doen alsof ze er niet zijn maar dat brengt je niet verder. Je kunt ze beter als eerste aanpakken en oplossen.

In de uitvoering kun je met een marker “Today” aangeven waar je in het proces van uitvoering bent. Je ziet daarbij soms pijnlijk hoe moeilijk het is om de strategie daadwerkelijk tot leven te laten komen.

explorer-maps

5 Aspecten waar een Explorer Map zijn toegevoegde waarde heeft

  • Actions en Next Goals helpen je om grote strategische doelen naar concrete, kleine stappen te vertalen. Het helpt je om wekelijks nieuwe stapjes te zetten.
  • Je strategie en de executie hiervan is visueel geworden. De strategie hangt in je kamer (zie mijn Obeya post) en de uitvoering er van kun je eenvoudig bijhouden in dezelfde map.
  • Het is een prachtig instrument om de teams door de strategie te praten en ook daadwerkelijk tot leven te laten komen voor ze.
  • Als team oefen je kwartaal na kwartaal in het nog beter concretiseren van de plannen die je hebt. Je bouwt een “feedback loop” in op je strategie zoals teams dat hebben met een retrospective. Daarmee zijn we ook steeds beter in staat om de transformatie te leiden en te bepalen wat we moeten doen om te verbeteren.
  • Het feit dat het in je kamer hangt dwingt je week in week uit om het over je strategie te hebben. Open en eerlijke gesprekken leggen soms pijnlijk bloot waar nu daadwerkelijk de knelpunten zitten. Met een team dat elkaar echt vertrouwd is dit een geweldige ervaring om samen te groeien.

Continue reading