Wat krijg je met een ruimte vol met managers die op weg zijn naar een wendbare organisatie? Juist ja vooral leuke gesprekken en interessante vragen die een ander licht schijnen op de situatie. Maandag 18 april had ik het enorme voorrecht een gastcollege te mogen geven op de Nyenrode Masterclass. Een aantal van de vragen van de deelnemers zijn blijven hangen en niet volledig beantwoord. In deze blog beantwoord ik 4 vragen uit de Masterclass Agile voor managers en sluit ik af met een schema van mijn deel van de inhoud van de masterclass.
Vraag 1: kan DevOps helpen kritische projecten weer vlot te trekken
Als je echte Agile of DevOps believers hoort spreken dan zou je de illusie kunnen krijgen dat DevOps en automation het antwoord is op al je IT problemen. Mijn mening is dat ook DevOps inrichten en met automation aan het werk gaan keihard werken is. Een aantal gedachten bij de vraag.
- Als je onder projecten tijdelijke werkzaamheden verstaat die er op gericht zijn een “change” op te leveren is DevOps niet zo geschikt. Vaak breng je in deze situatie de mensen naar het werk (ipv werk naar een vast team) en is er weinig tijd en aandacht om iets herhaalbaar en met onderhoud in gedachten op te zetten.
- Als je onder projecten werkzaamheden verstaat die uiteindelijk in het team/organisatie landen die ze ook initieel bouwt is het een zeer geschikte manier om aan de slag te gaan. Je bouwt vanaf de start aan goede herhaalbare processen en automatisering hiervan. En je maakt iets nieuws met het beheer in mind. Doen dus!
- Als je in staat bent in dit project in kleine iteraties op te leveren aan een gebruikersgroep of de klant moet je het direct doen. Daarmee kun je in snelle iteraties feedback ophalen op de kwaliteit, de waarde van het product en de manier van werken.
Vraag 2: Wat doe je met de auditor in DevOps omgeving?
In de vraag kun je een aantal aannames lezen. “De auditor is maar lastig in deze omgeving” of “de auditor heeft geen grip meer in een DevOps omgeving”. In veranderende organisaties moet je vooral in gesprek gaan met een partij als de auditor. Door ze vroeg te betrekken kun je samen optrekken naar een beter, meer betrouwbaar en een proces dat eenvoudiger te onderwerpen is aan audits. Een aantal gedachten bij de vraag.
- Betrek de auditeur vroeg in je transformatie en wees open. Mijn ervaring is door in gesprek te gaan kun je tot de wortel komen van bepaalde controles. Daarna kun je samen concluderen dat ze op een andere manier zijn in te richten of vervallen omdat ze overbodig zijn geworden.
- Streef naar vergaande automation van dit proces. In mijn blogs (1, 2) over continuous compliance ga ik hier op in.
- Maak het iets van de teams en niet van de manager of 1 of 2 experts binnen je afdeling. De DevOps teams zijn ook vanuit een “risico perspectief” verantwoordelijk. Soms gaat dit even mis maar sta die learning toe. End-2-End verantwoordelijk zeiden we dapper tegen elkaar? Falen is niet fout, soms wel kostbaar.
Vraag 3: Kun je wel DevOps doen zonder Agile te zijn?
Dit is nu echte een bijna humoristische vraag. Een discussie hierover gaat al snel alle kanten op. Alsof ze voorwaardelijk zijn aan elkaar. De echte believers zullen zeggen dat het niet kan. De taalpurist zal schermen met moeilijke volzinnen die aantonen dat het wel of niet kan. De filosoof zal zich verschuilen achter het argument dat het een reis is waarvan je het doel nooit zal bereiken. In mijn optiek maakt het niet zo gek veel uit. Het is een reis en afhankelijk van de gekozen definitie past het goed of minder goed. Een aantal gedachten bij de vraag.
- Automation van werkzaamheden zal in bijna elk team en elke situatie helpen. Als je dit onder DevOps verstaat begin er dan snel mee.
- Samenwerking levert in bijna elke situatie resultaten op. Als muurtjes worden afgebroken door DevOps laat ze dan vooral niet staan.
- Een duidelijk doel voor ogen hebben en daar gezamenlijk naar streven past prima onder DevOps en ook onder Agile. Doen dus!
- Aan de slag met focus op proces en product verbetering past onder DevOps en Agile so why not?
Mijn afdronk: does it matter?
En een andere vraag, ben je DevOps of doe je DevOps?
Vraag 4: Wil je elke dag wel releasen naar productie?
Een echte fan zal zeggen ja dat wil je, daar moet je naar streven. Er zijn tal van goede argumenten te bedenken om dit te willen. Ik zou ze kunnen opsommen. Een belangrijkere vraag in mijn optiek die we ons moeten stellen: is dit het doel? Ik denk dat het elke dag releasen nooit HET doel moet zijn. Hooguit een resultaat.
Naar mijn idee is het wel een resultaat van veel teams die met continuous improvement aan de slag gaan.
Elke dag releasen kan namelijk een leuk effect zijn van:
- de drive naar korte feedback cycles op het delivery proces
- de drive naar korte feedback cycles op het product door het uit te zetten in kleine geselecteerde gebruikersgroepen
- feedback op de kwaliteit van het product
- het eigenlijk niet weten wat je nu wilt ontwikkelen en daarom elke keer maar snel iets naar productie brengt om te leren
Een kort overzicht van de masterclass Agile voor Managers
De twee onderstaande afbeeldingen geven een overzicht van de onderwerpen die besproken tijdens deze avond.
Afbeelding 1 schetst de ontwikkeling van Scrum teams naar DevOps teams. Opgevolgd door een deel van de organisatie naar Squads, Chapters en Tribes. Dit hele verhaal is perfect samengevat in een prachtige video.
Afbeelding 2 en deel 2 schetst drie lijnen waarmee ik denk dat wij onze ambitie kunnen realiseren. Ze bevatten zoals je zult begrijpen slechts een deel van alle inspanning die we leveren om meer klantwaarde te leveren.
Hieronder heel in het kort de onderdelen die zijn langsgekomen.
Feedback Cycles
A: Stop met rapporteren, het is bijna allemaal waste
B: Richt een goede Obeyaa in om zo communicatie in je MT te laten verlopen
C: Maak transparante teamborden waarin je in 1 oogopslag kunt zien hoe de vlag er voor hangt
D: Monitor, Monitor, Monitor, leer, voel, ervaar en voorkom.
Continuous Improvement
A: Span je in om elke medewerker in je organisatie te laten ontwikkelen, persoonlijke coaching is hier een krachtig instrument
B: Span je in om elk team voortdurend te laten verbeteren, retrospectives, hackatons en andere instrumenten zijn hierbij een perfect hulpmiddel
C: Span je in om de systemen waarin je bijna bent vervlochten elke keer opnieuw te challengen. Laat niet los voordat je een kleine verbetering aan het systeem het aangebracht.
Continuous Delivery
A: Maar voor continuous delivery gebruik van een MVP approach
B: Ruimte voor experimenten, het kiezen voor een tool of framework en weer afscheidnemen is goud waard!
C: Het uitgangspunt van 1 van de teams is No Ops, No incidents. Positief uitgedrukt: automatiseren wat kan en quality first
D: Een inzicht in een continuous delivery pipeline voor Java development.
Wil je een WhatsApp bericht ontvangen bij een nieuwe blog?
Stuur dan even een berichtje naar +31645112490