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.

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 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.

Scrum in de beheer-praktijk

In onderstaande video wordt uitgelegd hoe Scrum er in de beheer-praktijk uitziet:

 

Waarom agile beheer?

Onderstaande filmpje geeft op pijnlijke wijze weer hoe de beheerpraktijk op dit moment is. Deze frustratie willen we tegen gaan.

Beginnen met agile beheer

Goed, je weet nu iets meer over wat agile beheer is. Is bij jou daardoor ook het vlammetje aangegaan? Of had je dat gevoel al veel langer, maar wist je nog niet precies wat je er mee aan moest? Lees dan vooral verder, want nu gaat het echte werk beginnen. Wie of wat je ook bent, als je voelt dat de huidige gang van zaken binnen jouw organisatie niet langer aansluit bij jouw waarden en normen, dan is nu het moment om er iets aan te gaan doen.

Maar hoe? Hoe zorg je ervoor, dat dingen gaan veranderen? Denk alsjeblieft niet meteen weer aan protocollen, beleidsplannen en dat soort zaken. De verandering die je wilt bewerkstelligen, moet namelijk van binnenuit komen. Wees overigens gerust: dit was gelijk het meest zweverige deel van dit artikel. Door naar de concrete aanpak.

Nee

Wen maar vast aan het woord dat je het meeste zal horen: ‘nee’. Deze paragraaf is er niet voor niets aan opgedragen.

‘Nee’ wordt op vele manieren uitgesproken. Sommige mensen gebruiken alleen het woord ‘nee’, anderen maken er een een hele lange zin van. Weer anderen zeggen het niet, maar voorzien je in plaats daarvan van een soort bezigheidstherapie; ja, je mag een voorstel schrijven, maar na inlevering verdwijnt die onder in een la, om er vervolgens nooit meer uitgehaald te worden. Het woord ‘nee’ is nooit aangenaam te horen, in welke vorm dan ook. ‘Nee’ staat voor afwijzing en weerstand en ontneemt je dikwijls je energie.

Maar bekijk het nu eens zo. Een ‘nee’ is niets meer dan het huidige systeem dat zichzelf verdedigt. Het huidige systeem wil zich immers, zoals elk ander systeem, in stand houden. En dat is ook logisch. Het huidige systeem voorziet mensen in werk, geeft mensen een stuk van hun identiteit en geeft bovendien zekerheid. Wees eerlijk, zou jij meteen ‘ja’ zeggen tegen iemand die je vertelt dat hij alles wil veranderen? Oh ja, jij wel natuurlijk…

Ja, ik wil!

Nu naar de positieve insteek. Je moet een duidelijk beeld hebben van waar je naar toe wilt. Dit is namelijk hetgeen dat je gaat uitdragen naar je supporters. Neem een applicatie en schets het toekomstbeeld. Bij het concreet maken van je plannen, maak je ook het team concreet. Welke rollen je nodig hebt in je team, scheelt van organisatie tot organisatie. Het belangrijkste is is dat het team zelfstandig beslissingen kan nemen en ook zelfstandig wijzigingen kan doorvoeren. Als niet alle rollen zijn vertegenwoordigd, begin je het ‘experiment’ met een achterstand. Bij agile beheer gaat het immers om snel inspelen op veranderingen en via korte lijnen communiceren, en dat is lastig aan te tonen bij een team dat geen stap mag zetten zonder goedkeuring van bovenaf.

Uiteraard kies je in je verhaal voor een applicatie en team waarbij de kans groot is dat je successen gaat behalen. Deze kans op succes is afhankelijk van de volgende zaken:

  • De mate waarin het team agile beheer ziet zitten
  • De mate waarin het team de benodigde kunde heeft
  • De mate waarin alle rollen in het team zijn vertegenwoordigd
  • De mate waarin het team een ‘zegen’ heeft van het management
  • De mate waarin het team mandaat heeft of dit mandaat snel kan verwerven

Ja, wij willen ook!

Het is dus duidelijk: met jouw droom ga je de hort op en zoek je naar meer mensen die zeggen ‘ja, ik wil!’ Dit zijn je supporters. Het zijn de mensen die het ook oneens zijn met de huidige gang van zaken. Zij zullen je steunen in je zoektocht naar verandering. Je vindt ze overal, als je maar goed zoekt. Vertel je verhaal zo vaak mogelijk, want met zwijgen kom je nergens.

Vergeet daarbij niet dat je supporters op alle niveaus nodig hebt. Met alleen maar beheerders ga je er niet komen, maar met alleen maar klanten ook niet. Je hebt een mix nodig van medestanders. Zoek dus bij verschillende groepen naar steun en verzamel zoveel mogelijk supporters om je heen.

Vreemd hè?

Is je iets opgevallen toen je het toekomstbeeld schetste? Hoe vaak vloog je door het hoofd ‘maar dat lukt hier toch nooit’ of ‘dat wil Jantje toch nooit’? Dat is het vreemde aan in een systeem zitten, je kan je slecht voorstellen dat het op een andere manier gaat. Maar toch kan het en als je maar eenmaal je beeld hebt gevormd, is het ook makkelijk om mensen mee te krijgen. Je moet nooit vergeten dat je er niet alleen voor staat. Er zijn er zat die je willen helpen maar niet weten hoe. En uiteraard wil ik je ook altijd helpen, neem gewoon maar contact op.

In één keer perfect?

Supporters, een team, een applicatie; aan de slag! Natuurlijk ga je er vanuit dat je plannen werken en dat de gehele organisatie je straks na deze proof-of-concept dankbaar in de armen valt omdat je ze verlicht hebt. In theorie gaat dat natuurlijk lukken. Maar in theorie zijn heel veel dingen een stuk simpeler.

Onthou daarom dat het niet allemaal in één keer perfect zal gaan. Sterker nog, het hele idee achter agile beheer is dat je telkens kleine verbeteringen doorvoert. Je moet zelf dus ook het idee van een perfect eindresultaat uit je hoofd proberen te zetten. Zorg dat je per keer een beetje beter wordt, én dat je de zegen van de lagen boven je blijft houden.

Kies voor losse stappen. De ene keer kan je extra aandacht besteden aan het eenvoudig live zetten van wijzigingen. Een volgende keer kijk je misschien of architectuur makkelijker valt in te passen. Door telkens met elkaar te blijven communiceren, voel je aan waar de kansen liggen en krijg je een steeds beter functionerend team.

Als het team eenmaal een succes is, draag het dan zo breed mogelijk uit. Deel je ervaringen met je supporters en creëer een sneeuwbal-effect. Meer supporters, meer agile beheer-projecten, meer goed communicerende teams. Stapje voor stapje implementeer een nieuwe werkwijze binnen je organisatie.