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.