Drie kernwaarden van agile beheer

Ik zoek altijd naar de essentie van zaken. Hoe meer overbodige dingen je wegschaaft, des te makkelijker wordt de rest – en ik houd van makkelijk. Daarom ging ik op zoek naar de essentie van agile beheer. Wat definieert agile beheer nu precies? Uiteindelijk kwam ik uit op drie kernwaarden.

1. We zijn mensen

De allerbelangrijkste kernwaarde: we zijn mensen. Het wordt makkelijk vergeten, maar achter elk schakeltje in het proces, op elke plaats waar FTE staat en achter elke functie-omschrijving zit een mens van vlees en bloed. Een mens met dromen, verlangens, slechte dagen, goede dagen, negatieve kwaliteiten, positieve kwaliteiten en een unieke kijk op de wereld. Binnen agile beheer beseffen we dat we allemaal mensen zijn, en we behandelen elkaar dan ook als zodanig.

2. We werken met elkaar als partners

Stel je eens voor dat ieder stel dat trouwt, een SLA met elkaar zou afsluiten. Hoe zou zo’n relatie er dan uitzien?

‘Maar in versie 3 van de SLA staat dat je op woensdagen het eten hebt gekookt als ik thuis kom.’
‘Weet je wat jij kan met je SLA?’
‘Ik ga de boeteclausule effectueren!’

In liefdesrelaties werkt een SLA niet (hoewel Sheldon in ‘the Big Bang Theory’ het wel probeert) en is het hooguit een bron voor grappige verhalen. Waarom zou dit in werkrelaties dan wel de oplossing zijn? Heb je dan opeens met robots te maken, in plaats van met mensen?

Binnen agile beheer werken we samen als partners. Dat is echt iets anders dan opdrachtgevers en opdrachtnemers die volgens een SLA communiceren. Uiteraard spreek je als partners wel uit wat je verwachtingen, wensen, allergieën en belangen zijn. Hoe kan je anders samen werken?

3. We bieden flexibiliteit én stabiliteit

Anders dan in een ontwikkeltraject, is er in beheer al een applicatie die door gebruikers wordt gebruikt. Deze gebruikers vinden twee dingen heel irritant: als het systeem het niet doet en als het systeem niet doet wat ze willen. Gelukkig springt agile beheer hier op in, door te streven naar flexibiliteit (zodat het systeem doet wat de gebruiker wil) en stabiliteit (zodat het systeem het überhaupt doet).

 

Agile, DevOps, Scrum en Kanban kort beschreven

Update: naar aanleiding van de vele vragen en opmerkingen die op dit artikel kwamen, heb ik een artikel geschreven hoe Kanban in de beheer-praktijk zou werken. Dit artikel staat hier: Kanban in de beheer-praktijk.

Het is makkelijk om door alle technieken, denkwijzen en methodieken het zicht op het bos een beetje kwijt te raken. In dit artikel geef ik een korte beschrijving van Agile, DevOps, Scrum en  Kanban. Dit om het overzicht te scheppen tussen deze termen die vaak door, over en naast elkaar lopen.

Agile

De kern van het agile denken is het agile manifesto zoals dat in 2001 is opgesteld door een aantal software-ontwikkelaars die vonden dan software-ontwikkeling beter kon. Het document geeft de volgende vier hoofdpunten:

  •  Mensen en hun onderlinge interactie boven processen and tools
  • Werkende software boven allesomvattende documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  •  Inspelen op verandering boven het volgen van een plan

(Bron: http://agilemanifesto.org/iso/nl/)

Het agile manifesto geeft daarnaast aan dat ‘Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.’ Ofwel, als we naar het eerste punt kijken dan hebben processen en tools ook waarde maar mensen en hun onderlinge interactie worden als belangrijker beschouwd. Ook belangrijk om te onthouden is dat Agile een denkwijze is en geen methodiek.

DevOps

Het woord DevOps is gevormd uit development en operations. Zoals ze zelf zeggen is het doel van DevOps: ‘helping to finish what agile development started’.  DevOps streeft naar multi-disciplinaire teams die samenwerken aan het bereiken van een resultaat. In deze teams werken in ieder geval de ontwikkelaars en de beheerders samen. In een ideale situatie streeft DevOps naar een multi-disciplinair team waarin alle project-rollen zijn vertegenwoordigd.

Daarnaast is een doel van DevOps is het sneller doorvoeren van wijzigingen door invoering van continuous delivery. Continuous delivery is het continu doorvoeren van kleine veranderingen aan een informatievoorziening. Dit in tegenstelling tot een situatie waarin heel veel changes tegelijk worden doorgevoerd. Om deze continious delivery te bewerkstelligen en flexibiliteit te bewaren, is continious integration nodig.

Continuous integration houdt in dat elke wijziging gelijk wordt geïntegreerd en getest in het geheel. Een vereiste voor continuous integration is dat de werking de applicatie worden geverifieerd. Hoe sneller deze verificatie loopt, des te sneller de wijziging live zal kunnen worden gezet.

Het vooruitstrevende aan DevOps is dat beheer een integraal onderdeel wordt van het team. Doordat beheer een integraal onderdeel is, kunnen wijzigingen in een vroeg stadium worden afgestemd. En nog beter: beheer heeft inspraak in wat er op hen afkomt.

Scrum

Scrum is een wijze van agile werken. Een erg goed introductie-filmpje waar ik ooit tegenaan ben gelopen, is de volgende: http://www.youtube.com/watch?v=XU0llRltyFM. De officiële scrum-gids kan worden gedownload van https://www.scrum.org/Scrum-Guides. Een aantal termen uit de Scrum-wereld zal ik hieronder beschrijven. Hoewel het er veel lijken, zijn het er nog een stuk minder dan in Prince2:

  •  Product backlog – De product backlog is een geordende lijst van alles dat mogelijk nodig is in een product. De product owner is verantwoordelijk voor de inhoud, beschikbaarheid en ordening van het product backlog. Veelal worden in de product backlog user stories opgenomen. Dit zijn eisen in de vorm van als x wil ik y zodat z. Als voorbeeld van een user story: als functioneel beheerder wil ik verwijderde gebruikers terug kunnen zetten zodat ik foutief verwijderde gebruikers kan terugzetten. De product backlog wordt aangepast als dat nodig is en is dus niet statisch.
  • Definition of done – Bij de items in de product backlog wordt ook opgenomen wanneer de item als afgerond kan worden beschouwd. De criteria die hieraan worden gesteld worden de definition of done genoemd.
  • Product owner – De product owner is de persoon die de stakeholders vertegenwoordigt. Daarbij zorgt de product owner ervoor dat het ontwikkelteam zijn werk kan blijven doen en is hij verantwoordelijk voor het product backlog. Dit is verreweg de meest veeleisende rol in Scrum.
  • Scrum master –  De scrum master begeleidt de teams in het agile werken, hij vervult de rol van coach. Daarnaast zorgt ervoor dat alles wat het team zou kunnen remmen, wordt weg genomen.
  • Ontwikkelteam –  Het ontwikkelteam bevat de teamleden die daadwerkelijk ontwikkelen.
  • Sprint – Een sprint is een vastgestelde hoeveelheid tijd (meestal ergens tussen de 1 en 4 weken) waarin een aantal items van de product backlog worden geïmplementeerd.
  • Sprint backlog – De items die in een bepaalde sprint worden afgehandeld, worden in de sprint backlog opgenomen.
  • Stakeholder – Een ieder die een belang heeft in het project, is een stakeholder. De belangen van de stakeholders worden vertegenwoordigd door de product owner.
  • Sprint meeting – Tijdens de sprint-meeting wordt bepaald welke items in de sprint worden opgepakt. Een ieder die hier een zinvolle bijdrage aan kan leveren, is aanwezig bij deze sprint meeting.
  • Sprint Review – Een sprint review wordt gehouden aan het einde van de sprint om het gedane werk teinspecteren en de product backlog te actualiseren. Dit is expliciet geen status-overleg of iets dergelijks. Het is een overleg om met elkaar in gesprek te komen.
  • Daily stand-up – Elk lid van het ontwikkelteam geeft in de daily stand-up aan wat hij gisteren heeft gedaan en wat hij vandaag gaat doen. Daarbij wordt aangegeven of er nog problemen zijn waar tegenaan wordt gelopen.
  • Retrospective – Aan het einde van elke sprint kan er met het hele team worden teruggekeken of er dingen anders en beter kunnen. Dit gebeurt tijdens de retrospective.

Dat is een hele lijst maar uiteindelijk werkt het vrij simpel. Uitgaand van een product backlog met daarop een aantal items:

  1.  De sprint begint met een sprint meeting waar een aantal items uit het product backlog in de sprint backlog worden gezet. Tijdensdeze meeting is een ieder die input kan leveren aanwezig. De items worden in samenspraak met het ontwikkelteam geselecteerd. Vervolgens start de sprint.
  2. Tijdens de sprint is er de daily stand-up. Voor vragen gaat het ontwikkelteam bij de product owner ten rade. De scrum master houdt in de gaten dat iedereen in zijn rol blijft.
  3. Aan het eind van de sprint volgt de sprint review waarin iedereen samen komt en wordt gekeken hoe alles is gegaan. Hier worden dan ook aanpassingen in het product backlog doorgevoerd.
  4. Er is een retrospective om te kijken wat er binnen het team beter kan.
  5. Ga weer terug naar stap 1

Kanban

Kanban is een Japanse term en vertaalt in het Nederlands naar visueel (kan) kaart/bord (ban). Kanban is een signalerings-systeem dat kaarten gebruikt om aan te geven dat iets moet gebeuren. We kunnen het product backlog en sprint backlog uit Scrum bijvoorbeeld weergeven op deze manier. Als we dat doen, maken we een storyboard. Dit ziet er dan als volgt uit:

sprint-storyboard

In de linkerkolom staat de product backlog, daarnaast staat de sprint backlog, in de laatste kolom kunnen alle kaarten worden gezet die afgerond zijn. Door dit overzicht voor het hele team zichtbaar te maken, is te allen tijde duidelijk welke kaarten nu in behandeling zijn en welke al gedaan zijn. Zodoende heeft iedereen inzicht in de status van de sprint.

Uiteraard kan een visueel kaartensysteem op heel veel manier worden ingezet. Met een andere indeling van de kolommen kan het ook op een servicedesk worden gebruikt om snel inzicht te krijgen in het aantal openstaande calls.

En nu?

In dit artikel is een korte beschrijving gegeven van Agile, DevOps, Scrum en Kanban. Deze korte beschrijving doet vanzelfsprekend geen recht aan de vele nuances die bij Agile, DevOps, Scrum en Kanban horen. Maar deze beschrijving geeft wel de basis om de artikelen die over agile beheer worden geschreven op hun waarde te kunnen schatten.

Feedback op dit artikel is zeer welkom en kan via de contact-pagina of via onderstaande mogelijkheid.

Wat is agile beheer?

Er is helaas geen comité dat heeft vastgesteld wat de officiële definitie van agile beheer is. Zelf omschrijf ik agile beheer simpelweg als “de standpunten uit het manifest voor agile softwareontwikkeling toepassen op beheer”. Het agile manifest stelt dat goede software ontstaat door te kiezen voor:

  1. Mensen en hun onderlinge interactie boven processen and tools
  2. Werkende software boven allesomvattende documentatie
  3. Samenwerking met de klant boven contractonderhandelingen
  4. Inspelen op verandering boven het volgen van een plan

(Bron: http://agilemanifesto.org/iso/nl/)

Vertaling naar de beheer-praktijk

Wat betekenen de vier punten uit het agile manifest nu voor de beheer praktijk?

Mensen en hun onderlinge interactie boven processen and tools

Stel je even deze situatie voor. Je hebt een ‘request for change’ ingediend en wacht al wekenlang totdat je verzoek wordt gehonoreerd. Uiteindelijk, na vier maanden, krijg je je verzoekje terug. In plaats van een bevestiging dat de aanpassingen doorgevoerd zijn, krijg je te horen dat de change-manager heeft vastgesteld dat veld 4b niet correct is ingevuld. Of je dit even opnieuw wil doen.

Herkenbaar? Hoe vaak gebeurt het niet, dat iets stukloopt of vertraagt op een formaliteit. Terwijl, als ze je gewoon even hadden gebeld, dan had je het kunnen uitleggen, toch?

Agile beheer stelt de communicatie tussen mensen centraal. Uiteraard zijn er wel processen, ze zijn alleen geen doel op zich. De processen bij agile beheer ondersteunen de mensen en hun interactie, in plaats van ze tegen te werken.

Werkende software boven allesomvattende documentatie

Als een applicatie in beheer wordt genomen, zijn er stapels documentatie vereist. Of de documentatie op dat moment ook echt klopt, weet niemand. Sterker nog: of de applicatie écht doet wat hij moet doen, lijkt van ondergeschikt belang. Daarna moet elke wijziging in drievoud in meerdere dossiers worden opgenomen, om vervolgens nooit meer bekeken te worden.

In agile beheer is het belangrijker dat de applicatie functioneert, dan dat hij uitputtend is gedocumenteerd. Logisch ook; waarom zou je documentatie onderhouden die ongelezen blijft en chronisch achterhaald is? Agile beheer documenteert wat minimaal nodig is en niets meer.

Samenwerking met de klant boven contractonderhandelingen
Zeg ‘klantcontact’ en meteen doemt het beeld van de mythische SLA op. De SLA kan nachtmerrie-achtige taferelen opleveren; verhitte discussies over of iets nou wel of niet erin staat, klanten en beheerders die ruziënd over elkaar heen buitelen en elkaar uiteindelijk niet meer kunnen zien of luchten. Met samenwerking heeft het allemaal niets meer te maken, en met mensen al helemaal niet. Bij veel bedrijven is de SLA een doel op zichzelf geworden, in plaats van een middel om samenwerking te stroomlijnen. Zo wordt de mythische SLA een veelkoppig monster dat alleen maar slachtoffers maakt.

Binnen agile beheer is men van mening dat een goede samenwerking zinvoller is dan het vastleggen van alle activiteiten in een contract. Communicatie tussen de klant en de beheerorganisatie is essentieel. Hoe komen ze anders ooit tot samenwerken? De mythische SLA wordt tot onschuldige proporties teruggebracht en is geen monsterlijk doel op zich meer, maar slechts een hulpmiddel in de communicatie.

Inspelen op verandering boven het volgen van een plan

Wijzigingen op een beheerde applicatie moeten meestal maanden van tevoren worden aangegeven en gespecificeerd. Als er dan onverhoopt in de tussentijd nog iets verandert aan de wijziging, moet het implementatie-plan worden aangepast, wat ook weer zeer tijdrovend is. Dit alles maakt het snel inspelen op veranderingen haast onmogelijk.

Wensen en eisen volgen elkaar tegenwoordig steeds sneller op. Binnen agile beheer is verandering de norm, en draait alles om het snel en goed getest doorvoeren van wijzigingen. Uiteindelijk wordt een beheer-organisatie immers zowel op stabiliteit als flexibiliteit afgerekend.

Agile beheer is een denkwijze

Agile beheer is geen vastomlijnde set processen, protocollen of procedures. Het is een denkwijze die bij de beheer-organisatie én de klant moet leven, en die “verandering” beschouwt als een constante factor.

Eén stabiele beheerde eindsituatie is niet meer het ultieme doel. Het is een achterhaalde gedachte dat een organisatie gebaat is bij een volledig dichtgetimmerde (software) omgeving. De samenleving is in toenemende mate geflexibiliseerd, waarom zou dit dan niet hoeven gelden voor het software-beheer? Een stabiele eindsituatie is niet relevant voor een organisatie die steeds in verandering is, en daarom gaat binnen agile beheer de beheerde omgeving steeds weer van de ene stabiele staat naar de volgende stabiele staat. Geen rechtstreekse treinreis meer naar een ver eindstation, waarvandaan de treinen terug bovendien slechts eens per maand rijden, maar een rondreis langs allerlei mooie, goed onderhouden treinstations die op verschillende afstanden van elkaar liggen. Soms ben je snel op een nieuwe plek, soms duurt het wat langer, maar overal is het mooi en omdat je een open ticket hebt, kan je zo lang en zo ver reizen als je wilt.

Zo werkt agile beheer. De klant en de beheer-organisatie werken samen in wederzijds vertrouwen en met open communicatie. Bovendien hebben beide partijen in deze wereld steeds begrip voor elkaars situatie. Natuurlijk gaat dat niet altijd meteen even makkelijk, maar met elkaar komen we er wel.

Feedback op dit artikel is zeer welkom, direct hieronder of via de contact-pagina.