Dag manager, welkom parttime leider

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

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