Kanban in de beheer-praktijk

Een poos terug heb ik een introductie geschreven over DevOps, Scrum en Kanban, deze is te vinden op: Devops, scrum en Kanban. De vraag die regelmatig binnenkomt, is hoe Kanban in de praktijk kan worden gebruikt. Mijn korte antwoord is dan meestal: op elke manier die visueel zichtbaar maakt waar een team bezig is aangezien Kanban een communicatiemiddel is. Aangezien ik ook wel eens van de langere antwoorden ben, beschrijf ik in dit artikel het bord, de indeling, de kaartjes en de werkwijze.

Het bord

De eerste vraag die opkomt, is waar je het bord gaat maken. Wordt het een fysiek bord of een virtueel bord? Mijn voorkeur heeft het fysieke bord omdat het altijd zichtbaar is en het fijn is om briefjes te verhangen van de ene naar de andere kolom (over de indeling later meer). Een fysiek bord kan alles zijn waar je strepen op kan maken (met stift, tape of iets anders), op kan schrijven en briefjes op kan plakken. Ik heb ze gezien op muren, whiteboards, speciale magnetische borden en nog veel meer mogelijkheden. Kijk eens rond wat er eventueel zou kunnen. Zoals altijd: wees niet bang, er kan altijd meer dan je denkt.

Uiteraard zijn er omgevingen waar het niet mogelijk is om een fysiek bord te maken dus dan wordt een digitaal bord (zoals bijvoorbeeld met Trello een goed alternatief. Voor de wat verder uitgewerkte workflow is Jira van Atlassian aan te raden. Belangrijk om te weten is dat Trello gratis is, Jira kost als je het voor je het team gaat gebruiken wel geld.

De meest aantrekkelijke variant is om de voordelen van een fysiek bord te combineren met een digitaal bord. Denk hierbij aan grote touchscreens of monitoren die altijd in de buurt aan staan. Dit is wel eens wat lastiger te regelen bij sommige organisaties…

De indeling van het bord

Als je eenmaal een medium hebt om je bord op weer te geven, wordt het tijd voor de indeling van het bord. Het meest eenvoudig is om te beginnen met drie kolommen, te weten ‘to do’, ‘doing’ en done. Dat is een indeling die heel erg intuïtief is. Wat ook helpt is om om horizontale strepen te zetten (en zo swimlanes te maken, zoals ze worden genoemd) en bijvoorbeeld de bovenste urgent te labelen, die daar onder belangrijk en die daar onder gewoon. Op het Internet zijn erg veel voorbeelden te vinden, ik zal er hier naar een paar linken:

Overigens, ik haal deze uit het volgende artikel: Organize your tasks using kanban boards, een erg leesbaar artikel.

De kaartjes

Wat is er nou te vertellen over de kaartjes zal je je misschien afvragen. Het zijn toch gewoon post-its? Ja, dat is vaak waar maar er valt wel wat te vertellen over de kaartjes. Ten eerste, de omschrijving die je op het kaartje zet, is heel erg belangrijk. De omschrijving die je er op zet, moet namelijk voor het hele team duidelijk zijn. Binnen sommige teams is een tweeletterige afkorting genoeg om te weten wat er speelt, meestal is er meer voor nodig.

Het tweede wat opkomt, is hoe je weet wie met een bepaald kaartje bezig is. Hetgeen je hierbij moet afwegen, is of het nodig is om dit bij te houden. Voegt dit echt iets toe of is het een reflex van het oude denken waarin controle de boventoon voerde? Kan je bijvoorbeeld ook volstaan met het gewoon even rond te roepen? Als het echt waarde toevoegt, zijn er een paar oplossingen. Een van die oplossing zijn gekleurde post-its. Je kan hier de naam opschrijven van de persoon of gewoon kleuren toekennen. Uiteraard kan je ook gewoon ‘normale’ post-its opknippen en hier namen op schrijven. Maar blijf er scherp op of het echt waarde toevoegt.

De werkwijze

Om te beginnen, is het zaak om met het hele team een basale inrichting van het bord te maken en een ieder de kans geven om zijn kaartjes op het bord te plakken. Daarna is het handig om elke dag even met zijn allen bij het bord te staan en een rondje te maken waarbij iedereen de volgende vragen beantwoordt: ‘wat heb je gisteren gedaan, wat ga je vandaag doen en waar loop je tegenaan?’. Uiteraard is dit ook het moment om kaartjes te verhangen als deze nog niet verhangen zijn. Gedurende de dag kunnen kaartjes worden verhangen, mensen worden toegekend aan aan kaartjes en het bord gewoon worden gebruikt. Na een week is het tijd voor een evaluatie waarbij kolommen worden toegevoegd, verwijderd of anders ingedeeld. Deze evaluatie (waar ook het waarde toevoegende van het bord ter discussie staat) is iets wat regelmatig moet terugkomen. Zo blijft het bord fris, scherp en niet een plichtmatig iets wat tot de cultuur is gaan behoren.

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

Flexibel, stabiel en gratis

Van de gemiddelde beheerorganisatie worden flexibiliteit, stabililiteit en geen rekeningen verwacht. En dat alles bij een groeiende hoeveelheid te beheren systemen die ook nog steeds complexer worden. Misschien is het ook de reden dat je op deze site terecht bent gekomen. Gaat agile beheer hier een oplossing voor bieden? Nee, is mijn korte antwoord. Het gaat wel helpen, is mijn iets langere antwoord. Want één van de belangrijke zaken waar agile beheer bij kan helpen, is de betrokkenheid van de opdrachtgever vergroten.

Nu ontstaat daardoor geen opdrachtgever die alle wensen plots laat varen máár er ontstaat wel begrip voor elkaars leefwereld. Let wel, ik schrijf hier heel bewust ‘elkaars leefwereld’. Want het gaat twee kanten op. Ook vanuit de beheershoek moet begrip ontstaan voor de opdrachtgever. Deze heeft het ook niet makkelijk, moet op zijn niveau allerlei beslissingen uitleggen en heeft dan ook nog een onwillige beheersafdeling die maar niet doet wat hij wil. Hoe moeilijk kan het nou zijn om gewoon een nieuwe versie van Dropbox te installeren? Thuis is het toch ook zo snel gedaan? En hij heeft al zoveel gezeik met alles wat niet lukt.

Terugkomend op het begrip wat wederzijds moet groeien. Het is onmogelijk om te haten dat wat je begrijpt, las ik ooit ergens en ik geloof ook wel dat het waar is. Op het moment dat er begrip ontstaat, ontstaat er ook ruimte voor dialoog. Ja, wederom gaat agile beheer richting het zweverige, hoezeer ik het ook probeer te voorkomen met mijn bèta-inslag. Maar in die dialoog kan in gezamenlijkheid een afweging worden gemaakt tussen flexibel, stabiel en gratis. Misschien geeft het zelfs ruimte om een paar van die kleine problemen die elke dag voorbij komen op te lossen. Ik weet het niet, misschien geeft het zelfs ruimte om er samen iets moois van te maken. Maar dan ook weer, ik droom wel eens meer.

Het belang van cultuurverandering

Is agile beheer het invoeren van Scrum als werkproces? Of het trots ophangen van een Kanban-bord? Of het hebben van een daily stand up? Uiteraard niet: het invoeren van agile beheer behelst het veranderen van cultuur. Juist deze component wordt zo vaak onderschat of vergeten. Alsof met het invoeren van een nieuwe methodiek een ieder vanzelf verandert. In dit korte artikel zal ik drie handige handvatten geven voor het veranderen van cultuur.

1. Choose your battles wisely

Je kan niet alles veranderen en zeker niet alles tegelijk. Kies kleine stukjes waarop je strijd wil voeren en laat de andere even gaan. Een mooie manier om prioriteiten te kiezen, is voor je veranderingsproces ook een backlog aan te leggen en hieruit te kiezen wat je als eerste oppakt. Zorg ook dat je als team een gedeeld beeld hebt van de verandering. Dit maakt het makkelijker om iets uit te dragen.

2. Geef aandacht aan wat goed gaat

Alles waar je aandacht aan geeft, wordt versterkt. Als je ervoor kiest om je heel erg te focussen op wat fout gaat, krijgt dat meer aandacht dan de dingen die gewoon goed gaan. Wees dus wijs en geef hier je aandacht aan. Zelf vond ik dit trouwens wel de meest tegen-intuïiteve houding. Waarom zou je aandacht geven aan wat toch al goed gaat? Maar in de praktijk blijkt het een sterk hulpmiddel om een verandering vaart te geven.

3. Sta fouten toe én leer er van

Als je een verandering introduceert, gaan er geheid dingen mis. Zo is het leven nou eenmaal. Schep een omgeving waarin fouten worden toegestaan en waar er van wordt geleerd. Sterker nog, draag ook uit dat er fouten gemaakt mogen worden zolang er maar van wordt geleerd. Alleen zo kom je ook in een cultuur die verandering omarmt en steeds beter wordt.

Doen we het goed?

Als je al een poosje bezig bent met agile beheer, steekt de vraag de kop op ‘doen we het goed?’ De oude manier van bepalen of je het goed doet, is het (op één of andere manier) invullen van een Excel-sheet. Als de juiste drempelwaardes worden bereikt, kleurt het vakje ‘groen’ en is het blijkbaar goed. Een pijnlijk voorbeeld, dat vast niemand zal herkennen, is het instellen van een maatstaf dat 90% van de calls binnen drie dagen afgesloten moeten zijn. Dit leidt tot het afsluiten en heropenen van een call om de maatstaf te halen. En iedereen is trevreden. Nou ja, iedereen… In ieder geval iedereen die geen klant is.

Uiteraard komt bij sommige organisaties ook het inzicht dat dit niet de goede manier is om kwaliteitsbewaking te doen. Dus huren ze een adviseur in die een nieuwe manier van kwaliteitsbewaking moet verzinnen. Als de adviseur aan zijn werk begint, is deze nog vol goede moed. Hij zoekt op Internet, spreekt met mensen die het al eerder hebben gedaan en nodigt klanten uit om eens te praten over de gang van zaken.

De klanten zijn blij om gehoord te worden en het nieuwe model lijkt een succes te worden. Maar stukje bij beetje wordt de klant uit het oog verloren. Het is alsof hij steeds iets minder interessant wordt. Was het eerst nog essentieel dat hij elke drie maanden werd gesproken, nu is eens per jaar ook voldoende. En uiteindelijk wordt duidelijk dat het ook zonder klant kan, we weten het zelf wel. Op zo een manier komen we uit op een vergevorderde manier van Excel-sheets invullen die steeds verder van de werkelijkheid afstaat.

Hoe dan wel?

Hoe onwaarschijnlijk ook, als je wilt weten of je klant tevreden over je is, kan je het hem gewoon vragen. Met vragen bedoel ik uiteraard niet een vragenlijst die moet worden ingevuld zodat er aan het management kan worden gerapporteerd. Nee, met vragen bedoel ik echt vragen. En luisteren om te snappen wat de klant nou écht wil. Waar wordt hij gelukkig van?

Op het moment dat je naar de wensen van de klant luistert, kan je ook uitleggen hoe het werkt aan jouw kant. Wat zijn de problemen waar jij tegen aan loopt? Op deze manier wordt de klant betrokken in jouw wereld en kan je hier ook begrip voor kweken. Het gevolg hiervan is dat zowel jouw klant als jij gaan streven naar een gezamelijk doel in plaats van streven naar een succesvolle opdrachtgever/opdrachtnemer-relatie.

Zeker de eerste keer is dit gesprek spannend. Er heerst toch altijd een gevoel van ‘met de billen bloot moeten’. Maar het is een noodzakelijk gesprek en het maakt het werkende leven uiteindelijk een stuk leuker. En leuk werken is één van de belangrijke zaken binnen agile beheer.

Creatief beheer

Als een project wordt uitgevoerd, is het voor iedereen duidelijk dat er creativiteit nodig is. Problemen komen plots op, mensen vallen uit, wensen veranderen en voor dat alles moet in de context een oplossing worden gevonden. Daar is duidelijk creativiteit voor nodig en dat is dan ook het soort mensen dat in de projecten wordt gezocht. Als het project vervolgens overgaat naar beheer, wordt er iets anders verwacht van de mensen. Vanaf dat moment is er geen creativiteit meer nodig, vanaf dat moment is het beheer opeens zo simpel als het uitvoeren van wat goed ingerichte processen. Het is niets meer dan productiewerk en daar is geen creativiteit voor nodig.

Althans dat denkt men…

Wat mensen vergeten is dat beheer een uitermate creatief beroep is. Was er in het project nog wat ruimte voor veranderingen en aanpassingen, als het in beheer is, is het in productie. De oplossingen die je als beheerder moet verzinnen, krijgen nog een extra complexiteit. Vind in die kluwen maar eens oplossing die alle partijen tevreden houdt. Daar is een enorme dosis creativiteit voor nodig.

Een tussenweg

Wat je ook vaak in organisaties tegenkomt, is een tweedeling. Het simpele beheer (de productieprocessen) en de ontwikkeling (de creatieve mensen) worden dan gesplitst. De afdeling krijgt dan een naam als ‘beheer’ en ‘vernieuwing’. En als de vernieuwing is doorgevoerd, wordt deze overgedragen aan het beheer. Maar die overdracht gaat natuurlijk niet altijd soepel want de beheerafdeling is niet gehoord in het proces. Of er wordt weer een papieren proces opgetuigd zodat de beheerafdeling wel is gehoord. Uiteraard niet herkenbaar voor degenen die dit lezen.

Op naar één

Het moge duidelijk zijn na het lezen van deze korte blog. Splits vernieuwing en beheer niet maar centraliseer ze rond één applicatie. Uiteraard neemt dit niet weg dat iedereen zijn eigen rol vervult in beheer. Het maakt alleen duidelijk dat je doel niet vernieuwing of beheer is. Je doel is om een applicatie aan te bieden waar de klant iets aan heeft.

En dan dit…

Observaties

  • Medewerkers met expert-kennis krijgen het minst betaald, tenzij ze worden ingehuurd.
  • Iedereen wil graag waten wat de wensen zijn die over zes maanden plots opkomen.
  • Een wens om ‘in control te zijn’ geeft aan dat de klant op de tweede plek komt.
  • We struikelen altijd over details maar vinden de mensen die over details gaan maar lastig.
  • Medewerkers krijgen de vrijheid om hun eigen invulling te geven aan het volledig vastomlijnde en dichtgespijkerde kader.
  • Simpele problemen zijn zo saai dat je ze wel complex moet maken.
  • Mensen zijn in staat om bij de koffie-automaat te klagen over het onzinnige formulier dat ze daarna weer invullen.
  • Architecten die roepen dat ze niet in een ivoren toren willen zitten, roepen dit meestal uit hun ivoren toren.

Hoe agile is jouw beheer?

Wil je weten hoe agile jouw beheer op dit moment is? Stel jezelf dan de volgende tien vragen.

  1. Hoe lang duurt het gemiddeld voordat een wijziging op je applicatie is doorgevoerd?
  2. Hoeveel mensen (die niet direct met elkaar werken) moeten iets vinden van een wijziging?
  3. Hoeveel formulieren moet je invullen voor een wijziging?
  4. Hoeveel kosten schat je dat er gemoeid zijn met een gemiddelde wijziging?
  5. Hoe vaak leek je verzoek tot wijziging goedgekeurd, om vervolgens toch niet te worden uitgevoerd?
  6. Hoe vaak zijn er gesprekken tussen de klant en de beheerorganisatie?
  7. Hoe vaak zijn er gesprekken tussen de klant en de beheerorganisatie, waarbij deze gesprekken niet op management-niveau plaatsvonden?
  8. Hoe vaak is een wijziging gewoon doorgevoerd zonder dat de klant op de hoogte was gesteld?
  9. Hoe vaak hoor je mensen bij de koffie-automaat klagen over de procedures en regels die hen het werken onmogelijk maken?
  10. Hoe vaak heb je de klant of de beheer-organisatie als een volledig tegenwerkende persoon ervaren?

Scoren van de antwoorden
Je kan de de score bepalen op de volgende manier :

  1. Tel je antwoorden van vraag 1, 2, 3 en 5 bij elkaar op
  2. Tel daarbij de antwoorden van de vragen 6, 7, 8, 9 en 10
  3. Tel hierbij het getal dat je bij 4 hebt opgeschreven, maar deel deze eerste door 1.000
  4. Schrijf dit getal op een blaadje
  5. Gooi het blaadje weg
  6. Barst in lachen uit

Net zoals je in je huidige organisatie nauwelijks iets aan je KPI’s hebt, heb je ook helemaal niets aan deze score. Je antwoorden op deze vragen zijn dan ook bedoeld om te gebruiken in een gesprek met de rest van de organisatie.

 

De kloof tussen ontwikkelen en beheren

Yin en yang  zijn Chinese begrippen die verwijzen naar twee tegengestelde principes of krachten waarvan alle aspecten van het leven en het universum doordrongen zijn. Het yin-yangsymbool is de Oud-Chinese voorstelling van de kosmische dualiteit, waarbij yin vrouwelijkheid (aarde, koude, het noorden, vochtigheid) symboliseert en yang mannelijkheid (hemel, warmte, het zuiden, droogte). Het zijn echter niet louter tegenstellingen, maar vooral complementaire (elkaar aanvullende) waarden.

(bron: wikipedia)

Symboliek

Bijna iedereen kent het symbool van Yin en Yang wel. Voor degene die het nog even niet voor de geest kunnen halen, hieronder het symbool:

Yin Yang symbool

Yin Yang symbool

Kijk eens goed naar dit symbool, het symboliseert de verbondenheid tussen Yin en Yang, het één kan niet zonder het ander bestaan. En en het één maakt onderdeel uit van het ander. Ze zijn voor altijd met elkaar verbonden. Kijk nu een naar het volgende symbool:

two circles

Nee, het is geen eeuwenoud filosofisch symbool dat je toevallig nog nooit hebt gezien.  Het zijn gewoon twee cirkels die niet met elkaar verbonden zijn.

 

De kloof tussen ontwikkelen en beheren

De link naar ontwikkelen en beheren ligt nu voor de hand. We benaderen ontwikkelen en beheren als de twee cirkels die niet met elkaar verbonden zijn. Hoe vaak zeggen we niet dat we het over de muur gooien van ontwikkeling naar beheer?

Laten we nu zien dat ontwikkeling niet zonder beheer bestaat en beheer niet zonder ontwikkeling. Het ene heeft het andere nodig om te bestaan en is innig verbonden met elkaar. En deze werelden moeten met elkaar in balans zijn. Als ontwikkeling of beheer de overhand krijgt, raakt de balans tussen Yin en Yang weg.

Ik weet het… Het klinkt allemaal zweverig.

Maar uiteindelijk is dat het niet. Dus de volgende keer dat iemand roept dat de ontwikkelaars en beheerders het over de muur hebben gesmeten, denk dan eens aan beide plaatjes. En probeer de werelden bij elkaar te brengen.

 

 

De twaalf principes van agile beheer

Het agile manifest is een mooi startpunt, maar daarachter liggen nog twaalf principes voor de toepassing van agile in de praktijk. Hoewel deze principes, net als het manifest, geschreven zijn voor ontwikkelaars, zijn ze minstens zo bruikbaar voor agile beheer. Het onderscheid tussen ontwikkeling en beheer vervaagt toch steeds meer. Reden genoeg dus om als beheerder je voordeel te doen met deze twaalf principes!

1. Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.

Ja, het klinkt allemaal zo logisch, maar in de praktijk is dit nog wel eens een ondergeschoven kindje. Voor je het weet, raak je verstrikt in processen en protocollen, en dan is het fijn om nog eens herinnerd te worden aan waar je het allemaal voor doet.

2. Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.

Klanten weten niet wat ze willen. En als ze het toevallig wel weten, willen ze het vandaag nog hebben. Dat is altijd zo geweest en zal altijd zo blijven. Gelukkig schrik jij straks als agile beheerder niet meer van veranderende behoeftes of last-minute verzoekjes!

3. Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.

Kleine wijzigingen op regelmatige momenten zijn overzichtelijker dan ééns per jaar een grote wijziging. Bovendien ziet je klant op deze manier regelmatig vooruitgang, in plaats van dat hij geen idee heeft waar jij nou al maanden keihard aan werkt. En er is nog iets: klanten over het algemeen pas wat ze willen, wanneer ze zien wat er is. Zorg er dus voor dat je regelmatig iets hebt om aan de klant te tonen, dan wordt de communicatie over wensen en mogelijkheden meteen een stuk makkelijker.

4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.

Ja, dit is wel even wennen als je het vergelijkt met de huidige beheerpraktijk. Maar wees eens eerlijk; hoe fijn is het om direct een vraag te kunnen stellen aan degene die de software ook daadwerkelijk gaat gebruiken?

5. Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.

Dit is een essentieel punt. Als mensen geen zin hebben om mee te bouwen aan effectief beheer, moet je ze er ook niet vermoeien. Zoek naar enthousiastelingen en geef ze vervolgens je vertrouwen. Alleen op die manier creëer je een goed functionerend team.

6. De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.

Ja, je hoort het goed. De meest efficiënte en effectieve manier van informatie delen is dus niet door middel van calls. Echt niet. Geloof me.

7. Werkende software is de belangrijkste maat voor voortgang.

Dus niet dat het proces goed is gevolgd.

8. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.

Dit geldt net zo sterk voor de inrichting van agile beheer. Je kan alles inrichten zodat het een tijdje werkt, maar het idee achter agile beheer is nou juist dat je een hele tijd in een vast tempo kan volhouden. Op die manier komt er ritme in het doorvoeren van wijzigingen.

9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.

Zeker als je binnen agile beheer werkt met sprints (vastgestelde eenheden tijd waarin een vastgestelde hoeveelheid werk moet worden gedaan), worden er wel eens concessies gedaan aan de kwaliteit. De sprint moet behaald, en voor dat doel moet alles wijken. Dat kan later in het traject alsnog zorgen voor problemen. Kwaliteit en ontwerp moeten centraal blijven staan.

10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.

Dit principe houdt ook weer verband met zoveel mogelijk waarde leveren voor de klant. Des te slimmer we het werk organiseren, des te meer levert het op.

11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.

Dit vereist uiteraard wel dat je gemotiveerde en goede mensen in je team hebt.

12. Op vaste tijden onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Over het algemeen weten de mensen die het werk doen zelf het beste hoe ze effectiever kunnen worden. Praat er daarom regelmatig over en gebruik de ideeën die uit het team komen ook echt.

 

Agile beheer mythes

Zoals zo vaak het geval is, zwerven er ook rond agile beheer diverse mythes rond. Het zijn uitspraken die je soms hoort, waarbij sommigen de plank nét misslaan en anderen gewoon totaal niet kloppen. Hieronder zet ik er een paar op een rijtje. Mocht je zelf dergelijke mythes tegenkomen, of uitspraken horen waarover je twijfelt, dan hoor ik dat graag van je (onderaan kan je reageren). Wie weet kunnen we samen nog meer helderheid scheppen in de wereld van agile beheer.

We hebben geen SLA meer nodig

Echt gehoord in de dagelijkse praktijk: ‘als we agile beheer hebben, hoeven we geen afspraken meer te maken over uptime of reactietijden op storingen. We doen alles op vertrouwen.’ Nou, complimenten aan de consultant die dit verkocht heeft gekregen maar uiteraard is dit niet waar – en ook niet handig. Ook wanneer je agile beheer doet, moet je afspraken maken over wat je van elkaar verwacht en waar je elkaar op kan aanspreken. De insteek is bij agile beheer wel anders. Je moet daarin de SLA meer zien als een ondergrond, waarop met vertrouwen en respect voor elkaars situatie verder wordt gebouwd. Het is dus geen doel maar een middel, geen eindresultaat maar een vruchtbare bodem.

Als we agile beheer doen, gaat alles goed

Nee hoor, dat gaat het niet. Je kan in iedere situatie tegen problemen oplopen, agile of geen agile. Deze uitspraak is helaas symptomatisch voor de oude beheer-denkwijze. ‘Wanneer we proces goed hebben ingeregeld, de wijzigingen zo gecontroleerd mogelijk uitvoeren en alles (en dan bedoel ik ook echt alles) in ogenschouw nemen, hebben we de zaak onder controle, gaat alles goed en hebben we eindelijk rust.’ Beheer-organisaties streven al jaren naar die eindsituatie en dat kunnen ze doen tot ze een ons wegen, want in de praktijk wordt die situatie nooit gehaald. Met agile beheer omarm je de verandering en richt je de organisatie hierop in. Ofwel, je mikt nooit op de rustige tijden maar juist op de verandering. Geen ‘eindelijk rust’-moment voor de agile beheerder dus, maar in plaats daar van veel meer rust gedurende het gehele proces. Ook als er af en toe dingen misgaan…

We kunnen pas over op agile beheer als we alles op orde hebben

Dit is een mooi argument om verandering tegen te houden. Er is namelijk altijd wel iets te verzinnen waardoor je niet over gaat. Voordat je alles op orde hebt, ben je jaren verder, helemaal als je de definitie van ‘alles’ lekker laat schuiven. Nee, als je de basis op orde hebt (een product owner, een backlog, een team en een scrum master) dan kan je gewoon beginnen. Vanaf daar zal je uiteraard wel verder moeten ontwikkelen. Maar daar is agile beheer nou net zo goed in.

We kunnen nu ook zonder contracten

Nou… Hoe zal ik het zeggen… Weet je nog wat ik zei over de SLA? Afspraken vastleggen is in alle gevallen zinvol, je moet immers altijd een onderlegger hebben voor de samenwerking met je partners. Een contract is daar een uitermate geschikte vorm voor. Maar blijf denken aan dat verschil tussen doel en middel. Een contract een middel is om de samenwerking vorm te geven en geen doel op zich.

Nu hoeven we nooit meer…

Elke zin die in het kader van agile beheer begint met ‘nu hoeven we nooit meer’ zou onmiddellijk grote alarmbellen en zwaaiende sirenes moeten doen afgaan. Over het algemeen doe je met agile beheer namelijk gewoon dezelfde dingen. Wel op een andere manier, maar toch: ook de saaie, monotone dingen blijven gewoon bestaan. Sorry.

Al het beheer moet agile gedaan worden

Nee, gewoon nee. Er zijn zat situaties voor te stellen waarin een agile beheer organisatie helemaal niet de beste oplossing is. Een wijs persoon kijkt naar de sterke kanten van agile en besluit of dit toe te passen is op zijn organisatie.

Succesfactoren voor agile beheer

Hoe maak je agile beheer tot een succes? In dit artikel loop ik een aantal succesfactoren af, die je in je eigen agile beheer-praktijk kan toepassen.

Voorbij de sprint denken

Eén van de dingen die vaak fout gaan in het toepassen van agile, is dat de focus op de korte termijn komt te liggen. Als de huidige sprint wordt gehaald, is alles goed, zo is vaak de gedachte. Dat er eventueel nog kwesties liggen die in volgende sprints weer de kop op kunnen steken, wordt genegeerd. Dit kan echter wel voor problemen op lange termijn zorgen. Het team moet daarom de user stories in de lopende sprint goed oppakken, én zorgen dat deze in komende sprints ook goed kunnen worden opgepakt. Denk voorbij de huidige sprint en blijf een lange-termijn overzicht houden.

Gedachtengoed uitdragen

Binnen je team heb je overeenstemming over wat agile beheer inhoudt. Iedereen onderschrijft het belang ervan en je teamleden gaan iedere dag fluitend aan hun werk. Allemaal goed, toch? Helaas zegt dit nog niets over de mensen om je heen. Je team is onderdeel van een groter geheel en ook daar moet draagvlak zijn en blijven. Communiceren dus. Zorg dat je het agile beheer-gedachtegoed binnen de organisatie blijft uitdragen. Er zijn altijd nog meer supporters te veroveren!

Alle disciplines vertegenwoordigd en gemandateerd

Binnen agile beheerteams moeten alle disciplines vertegenwoordigd zijn en ook mandaat hebben. Dit is een essentieel onderdeel van agile, en als dit bij jou niet aan de hand is, beperk je je agile-mogelijkheden zwaar. Wanneer ieder teamlid eerst moet overleggen voordat iets wel of niet kan, wordt het resultaat van het team ernstig geremd. Sterker nog, het enige dat je dan voor elkaar hebt gekregen, is dat er nog een extra overleg-laag is ingevoerd. En dat is niet wat je wilt, toch?

Gebruiken wat er is

Het is heel verleidelijk om te starten met agile beheer en alles wat al bedacht is, overboord te gooien. Schoon schip, een nieuw systeem, weg met het oude. Goed idee toch? Nee, integendeel. Wat er al is, kan je slim gebruiken om je agile beheer vorm te geven. Is er al een handboek voor het live zetten van wijzigingen? Pas het aan je eigen behoeften aan en gebruik het! Denk vooral niet dat alles wat er al is, slecht is. Dingen zijn ontstaan met een reden en als je die reden achterhaalt, heb je er iets aan voor je eigen praktijk. Alles opnieuw uitvinden is al lang niet meer nodig. Gebruik het goede, verbeter het slechte.

Geen vrijheid, blijheid

Omdat agile beheer als een bevrijding voelt kan er ook een sfeer van vrijheid, blijheid ontstaan. Bevrijd van alle oude ketens gaat iedereen fris aan de slag en is geen idee te gek. Het is een valkuil waar veel agile teams invallen, dus pas op dat het jou niet overkomt. Agile beheer heeft een duidelijk omschreven doel, namelijk het bieden van flexibiliteit én stabiliteit. Dit is dan ook de sfeer die moet heersen binnen het team. Flexibiliteit is belangrijk, maar verlies vooral niet uit het oog waar je voor werkt.

Heldere verwachtingen

Binnen de organisatie moet duidelijk zijn welke verwachtingen er over en weer spelen. Ga zitten met je baas, de baas van je baas en iedereen die verwachtingen naar het team kan hebben. Spreek met elkaar af wat je verwacht dat je gaat presteren, wat je als risico’s ziet, waar je kansen ziet en hoe vaak je terug rapporteert.

Communicatie

Als binnen het team druk wordt gewerkt, wil het communiceren naar mensen buiten het team nog wel eens achterwege blijven. Zorg daarom dat er iemand binnen je team is die de communicatie op zich neemt, en laat diegene zich helemaal suf communiceren. Vertel zo veel mogelijk over wat je doet aan iedereen die het wil horen (en af en toe ook aan mensen die het niet willen horen…). Alleen dan komt de dialoog op gang, en kan je agile beheer tot een succes maken.