Hoe word je Agile? Begin er vandaag mee!

Binnen Agile transities met scrum als methode kom je op enig moment altijd op een soort kantelpunt waarbij er gekozen moet worden of je beter "moet gaan scrummen" of dat de focus moet gaan liggen op "Agile zijn". Als Agile coach ligt je focus primair op het laatste maar continue verbeteren in het doen van scrum helpt daar natuurlijk bij.

Maar ik merk een kentering in hoe men in de markt tegen scrum aankijkt. Bedrijven die zich toespitsen op scrum en de “holy grail” aanbieden schieten als spreekwoordelijke paddenstoelen uit de grond. Scrum neemt steeds meer vormen aan van een hype, een trend en lijkt daarmee op iets van tijdelijke aard.

Het is jammer dat zo’n mooie methode aan een negatief beeld ten onder zou gaan. Want veel belangrijker dan de methode, is de houding, de principes van Agile. Daarin ligt de toegevoegde waarde. Voel in al je poriën dat je bezig wilt zijn met toegevoegde waarde leveren, 100% klantgericht, dat je continue beter wilt worden, dat je actief feedback vraagt op alles wat je doet, dat je gelooft in autonome teams, dat de huidige manier van werken bol staat van schijnveiligheid, dat veranderingen een feit zijn en geen risico. Daar ligt de toegevoegde waarde van de verandering. Ik noem het regelmatig dat je Agile door je aderen moet voelen stromen. Kortom, being Agile.

Agile doen vs Agile zijn, ofwel de Agile adoptie vs Agile transformatie. Een stelling waar we uren over kunnen discussiëren. Maar in mijn optiek zit het verschil in de manier van doen vs de manier van denken. Als de Agile manier van denken afwezig is, dan is een andere manier van werken aanleren lastiger. De Agile mindset vormt de basis, het fundament van de verandering. Transformaties zonder dat de Agile mindset aanwezig of onvoldoende ontwikkeld is, gaan vele malen moeizamer dan wanneer de Agile competencies minder ontwikkeld zijn. Leg de focus op de Agile waarden en principes en minder op de methoden. Dit geldt zowel voor jezelf als op de transitie van een organisatie.

Hoe zorg je er nu voor dat dit Agile-bloed door je aderen stroomt? Hoe kom je nu op dat punt?

  1. Het belangrijkste antwoord is relatief eenvoudig: doe het zelf ook! Practise what you preach. Doe alles wat ik in de voorgaande alinea heb benoemd. Stel je iedere keer weer de vraag waar de meeste toegevoegde waarde voor je klant in zit, hoe je kunt verbeteren, speel in op veranderingen, beslis niet alles zelf maar benut de kennis en ervaringen van teams, vraag feedback, vraag actief of je het team nog kunt helpen, laat je niet leiden door excellijstjes, etc. Doe het en begin er vandaag mee.
  2. Denk klein, nee nog kleiner
  3. Denk in “afmaken” ipv aan beginnen
  4. Werk samen
  5. Iedereen mag fouten maken (maar leer er wel van)

Deze vijf punten gelden niet alleen in je werk, maar ook in je privésituatie. Stel je ook daar iedere dag weer de vraag wat ik kan doen zodat ik beter wordt in het zijn van een ouder, in het helpen van mijn kind, in het koken, in het coach zijn van het team van je kind, in het sporten, etc. Probeer nieuwe dingen uit ook al lukt het niet altijd, maar vraag actief feedback. Vraag altijd of je je team (gezin, vereniging, vriendengroep, etc) ergens mee kunt helpen zodat we dingen kunnen afmaken. Maar voel je ook niet schuldig als het eens niet zo gemakkelijk gaat. Ik doe ook niet alles goed, maak fouten en leer nog iedere dag. Gelukkig wel.

Ik probeer met mijn pleidooi duidelijk te maken dat de onderliggende gedachte veel belangrijker is dat de methode die je toepast. Ofwel Agile zijn biedt je veel meer voordelen dan scrum doen. Ik ben mij ervan bewust dat onze naamgeving scrum@work anders doet vermoeden maar ook wij als bedrijf draaien op de Agile gedachte. Het gaat om de intrinsieke motivatie en niet om een methode die je doet. Bij alles wat we als scrum@work doen kijken we naar toegevoegde waarde, hebben sterke klantfocus, werken we in teams, reflecteren we alles wat we doen en sturen we bij.

Ik wil jullie als lezer van deze blog natuurlijk ook actief om feedback vragen. Inspireert dit artikel je (dat is mijn primaire doelstelling)?, Is het begrijpelijk?, Helpt het je?, Ben je het er mee eens/oneens?, Wat had je anders verwoord?, etc. Alles met als doel om mijn volgende blog beter te laten zijn dan deze. Ik dank je wel.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Over het “hoe” en “wat” van scrum

Scrum gaat veel over het effectief organiseren van werk. Tijdens de trainingen die wij geven krijgen we vaak de feedback dat het onderdeel waarin we dit principe duidelijk maken, heel verhelderend is. Het is het verhaal over het hoe en wat van scrum, over waarom scrum zo effectief is en over hoe je inzicht krijgt over hoe huidige projecten georganiseerd zijn.

Bij traditionele projecten is er een projectleider die verantwoordelijk is voor zowel de inhoud (de scope, wat er gedaan moet worden) als over het proces (hoe zorgen we er voor dat het werk gedaan wordt). Dat is een hele grote verantwoordelijkheid om door één persoon uit te laten voeren. Scrum heeft deze verantwoordelijkheden gesplitst in de wat-vraag en de hoe-vraag. Deze twee verantwoordelijkheden zijn verdeeld over twee rollen: de wat-vraag is het werkgebied van de product owner en de hoe-vraag is het domein van het projectteam

Doordat scrum deze verantwoordelijkheden uit elkaar getrokken heeft, geeft veel mensen duidelijkheid in ieders rol. In de huidige situatie is niet altijd duidelijk wie over het ‘wat’ gaat en wie over het ‘hoe’.  Het komt in huidige projecten regelmatig voor dat veel mensen zich met de wat-vraag bezighouden. Daardoor kan het lang duren om hier een duidelijk antwoord op te krijgen. Maar ook nadien er een besluit genomen is, komt het voor dat er mensen zijn die dit besluit telkens weer ter discussie stellen.

scrum-1Maar andersom gebeurt precies hetzelfde. Veel mensen hebben een mening over hoe het werk gedaan moet worden en schromen niet om deze te ventileren. Scrum is duidelijk: hoe het werk gedaan wordt, wordt door het projectteam bepaald. Iedereen die zich mengt in de manier waarop het team zijn werk zou moeten doen, verstoort het groepsproces en ontneemt het team de mogelijkheid om zelf een goede manier te ontdekken hoe het werk zo snel mogelijk gedaan te krijgen.

Kortom, er wordt lang over gesproken over wat er gedaan moet worden en als dat dan bekend is, wordt de teamontwikkeling verstoord door externe partijen. Conclusie: de voortgang van het project komt ernstig in het geding.

Ons advies: laat de product owner vanuit zijn rol duidelijk aan het team maken wat zij moeten gaan doen. Laat het team in zijn waarde door het zelf te laten bepalen hoe zij dat doen. Dan ben je het werk effectief aan het organiseren.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Shared spaces en Agile

Onlangs was in het nieuws dat het aantal shared spaces was toegenomen. Voor wie nog niet bekend is met het begrip shared space, dit betreft een verkeersgebied waar meerdere verkeersdeelnemers van gebruik mogen maken. Geen aparte fietspaden meer, maar automobilisten en fietsers maken gebruik van hetzelfde stukje weg.

Ik herken deze ontwikkeling want ook in mijn eigen woonplaats zie ik steeds meer van deze plekken. Ik kan mij nog goed herinneren hoe de “burgerij” reageerde op de plannen van de gemeente op het moment zij deze bekend maakte. “Het zal leiden tot onveilige situaties”, “de kwetsbare groepen zouden er niet mee om kunnen gaan” en “het aantal ongelukken zou zeker toenemen”. Ik beperk mij even tot de inhoudelijke argumenten want ook de verwensingen richting gemeentebestuur was niet van de lucht. Dat ging van “ondeugdelijk bestuur” tot “ik hoop dat ze zelf een ongeluk krijgen”.

 

Binnen Agile werken we al veel langer met “shared spaces”. Sterker nog, dat is één van de sterke punten van Agile: het werken van meerdere disciplines in één werkgebied. Ofwel, het werken in multifunctionele, autonome teams. Het team vormt de shared space binnen het Agile gedachtengoed. Binnen Agile geen ruimte voor aparte wegvlakken voor auto’s, aparte fietspaden of een trottoir. Geen aparte disciplines maar één grote shared space waar het team in opereert en werkt. Natuurlijk heb je een kerndiscipline (lees: automobilisten rijden niet het meest rechts vlak langs de gebouwen, daar lopen de voetgangers) maar doen al het werk dat nodig is om het teamdoel te behalen. Alle disciplines die door elkaar werken om een gereed product aan het eind van de sprint op te leveren.

Zoals er veel tegenstand is bij het invoeren van shared spaces binnen het verkeer, is er vaak ook tegenstand tegen het invoeren van autonome teams bij organisaties. Het blijkt dat veel van de tegenargumenten van de shared spaces in het verkeer niet gebeuren en voorkomen. Het aantal ongelukken neemt niet toe, sterker nog het wordt er juist veiliger omdat de verkeersdeelnemers zich veiliger gaan gedragen.

Zou het bij het invoeren van “shared teams” ook niet zo gaan? In plaats van te denken dat medewerkers minder productief worden omdat werk gaan doen dat buiten hun kerndiscipline en comfortzone ligt, zou het ook kunnen zijn dat ze juist productiever worden? Omdat ze gezamenlijk werken aan het teamdoel (lees: veiliger gedragen) en zich daar meer op focussen? Dat maakt het team effectiever en daarmee je eigen bijdrage aan het totale doel.

Iets om over na te denken? Wij denken graag met u mee!

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Scrum en (anti)Stress

In april van dit jaar waren we van Scrum@work op het antistress event in Groningen om daar een workshop te geven over hoe het werken met scrum stressverlagend werkt. Als thema hebben we gekozen: “scrum, daar krijg je energie van!”. We hebben daartoe de ball point game gedaan om de deelnemers aan de workshop te laten ervaren hoe het is om in een autonoom, zelforganiserend en zelfsturend team te werken, hoe het voelt om daar een manager aan toe te voegen en hoe je in korte tijd kunt verbeteren door retro’s te houden.

Het event werd geopend door Joke Koster van het Centrum voor Stressmanagement. Zij gaf in haar presentatie een overzicht van de lessons learned en best practices bij een case bij het bestrijden van stress binnen woningcorporaties. Ze deelde een slide uit met het TNO-werkdruk-model.

Ik heb dit model aandachtig bekeken en kon niet anders dan tot de conclusie komen dat scrum heel veel van deze aspecten afdekt en ondervangt. Maar ik zal dit ook uitleggen. Ik begin met de factoren die de werkdruk bepalen. Als je kijkt bij Taakeisen (zowel werkcontext en werkinhoud) zie je daar aspecten genoemd als onduidelijke of veranderende taak, onduidelijke verantwoordelijkheden, tijdsdruk, hoeveelheid werk, kwaliteitseisen, variatie.

Het Scrumraamwerk heeft al een oplossing voor al deze aspecten:

  • onduidelijke of veranderende taak: het gebruik van user stories
  • onduidelijke verantwoordelijkheden: het team is gezamenlijk verantwoordelijk
  • tijdsdruk: het team bepaalt zelf de inhoud van de sprint ipv een opgelegde planning
  • hoeveelheid werk: idem
  • kwaliteitseisen: door acceptatiecriteria en Definition of Done weet iedereen aan welke eisen het product moet voldoen.
  • Variatie: door gezamenlijke verantwoordelijkheid van het team moet het team ook werk doen dat niet binnen zijn/haar primaire functie behoort. Dat zorgt meer variatie in het werk.

Als we vervolgens kijken naar de voorgestelde regelmaatregelen, zien we daar al een paar kenmerken van Scrum in terugkomen:

  • Autonomie: het team is zelforganiserend en heeft de vrijheid om zelf de oplossing (het “hoe”) te bepalen.
  • Tijdsautonomie: het team maakt zelf de inschattingen en bepaalt zelf de sprintinhoud.
  • Functionele steun collega’s: je werkt in teamverband met gedeelde verantwoordelijkheid en steun van je collega’s is daar onderdeel van.
  • Participatie in besluitvorming: door de continue communicatie met de opdrachtgever (product owner) over de user stories, ben je betrokken bij de besluitvorming over “wat” er gedaan moet worden.

Een rode draad, die vaker die middag terugkwam is het houden, faciliteren en opvolgen van verbetersessies. Binnen scrum kennen we daar de retro voor. Binnen scrum kennen we al de voorwaarden om een goede retro te houden in de zin van een save space (veilige omgeving waarin je mag zeggen wat je denkt en voelt), respect en het opvolgen en invullen van benoemde verbeterpunten. Waar dit binnen scrumprojecten vaak al gemeen goed is, is dit bij organisaties die niet scrummen nog een bijzonderheid waar extra aandacht aan moet worden gegeven.

We kunnen dus stellen dat werken in een scrumteam dus stressverlagend werkt! Dat heeft natuurlijk weer positieve effecten voor zowel de medewerker als de organisatie en HR. Een stressloze medewerker is voor de organisatie productiever en draagt meer bij aan de organisatiedoelstellingen. En de kosten van een medewerker die met stressklachten thuis zit, zijn voor de organisatie niet te overzien.IMG_6066

Terug naar het thema van onze workshop dat scrum energie geeft. Wij weten allang dat flow die scrum biedt energie oplevert en dat stress juist energie kost. Los van de feedback die we via het retrovel hebben gekregen was duidelijk dat de workshop geslaagd was af te leiden uit het feit dat de meeste mensen met een glimlach de zaal verlieten. Ze hadden duidelijk een mooie, inspirerende en energiegevende workshop gehad. En dat geeft ons ook weer energie.

Ook weten hoe scrum in uw organisatie stressverlagend kan werken, neem dan contact met ons op.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

100% versnelling gehaald

Het begon op enig moment toen we door een relatie gebeld werden, nadat hij getipt was door een klant van ons. Hij kwam met de mededeling dat hij met een probleem zat en vroeg ons of wij konden helpen.

Hij moest een probleem oplossen en een product opleveren. In essentie kwam het er op neer dat er een visie ontwikkeld moest worden en dat daar een programma van acties uit voort moest vloeien. Hij had inmiddels 1 sessie met alle stakeholders gehad om input te vragen. Na deze eerste sessie kwam hij al tot de conclusie dat er iets moest veranderen wilde er überhaupt enig resultaat komen. Wij hebben samen over de scrummethode gesproken en uitgelegd waar en hoe deze methode kan helpen om tot resultaat te komen. We verwachtte hier vier avondsessies voor nodig te hebben.

We gebruikten niet alle onderdelen van scrum maar hanteerden wel heel veel basisprincipes van scrum. We maakten geen plan van aanpak maar bepaalden voorafgaand aan iedere sessie waar de meest toegevoegde waarde lag en zetten deze bovenaan onze “backlog”. Tijdens de sessie’s waren de teams zelfsturend. Wij gaven aan “wat” ze moesten doen maar waren de teams vrij om te bepalen “hoe” ze dit deden. We sloten iedere avond af met een demo en een retro. Tijdens de demo toonden de teams hun resultaat van de avond aan de overige groepen en keken we in de retro naar hoe de avond was verlopen en wat we de volgende keer beter moesten doen.

Na de tweede sessie werden we gebeld door de betreffende klant met de mededeling dat er al zoveel voortgang was geboekt dat het project kon worden afgerond. Uit de twee sessie was dusdanig veel informatie naar boven gekomen dat het programma van acties kon worden afgerond. Voor ons natuurlijk jammer, want het was een leuke opdracht maar aan de andere kant is er geen beter compliment dan dat wij onszelf overbodig hebben gemaakt doordat het project eerder is afgerond dan gedacht. Twee sessie i.p.v. de vooraf bedachte vier sessies waren er nodig. Een versnelling van 100%!

Wij zijn blij en trots op dit resultaat en natuurlijk blij dat we de klant zo hebben kunnen helpen.

Mocht u vragen hebben hoe ook uw project weer in een stroomversnelling te krijgen, neem dan contact met ons op.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Lego Serious Play

Vorige week was ik bij een meetup van Lego Serious Play (LSP) om kennis te maken met andere toepassingen van Lego. Voor onze Scrum Xperience maken we al geruime tijd van Lego. Deelnemers aan de Scrum Xperience krijgen opdrachten om user stories te maken d.m.v. Lego.

Vaak is deze Xperience op maat gemaakt en verschillen de user stories per opdrachtgever. De basis vormt de case dat wij burgemeester zijn en dat we graag willen dat er een stad gebouwd worden. Aan de hand van het scrumproces wordt er in drie sprints een stad gebouwd bestaande uit huizen, een supermarkt, een gemeentehuis, kinderopvang, etc.

Het was een leuke, interessante en leerzame avond waarbij ik geleerd hebt dat nagenoeg alles met Lego in modellen kan worden uitgebeeld. De Lego Serious Play sessie houden een vaste structuur aan bestaande uit:

  1. Vraag stellen
  2. Bouwen van model
  3. Betekenis geven aan model
  4. Reflectie

Nadat de vraag cq opdracht is gegeven, begin je met een beperkte set aan Legoblokjes te bouwen. Het is verbazingwekkend dat er altijd iets “uit je handen” komt dat aan de opdracht voldoet. Nadat het bouwen klaar is, geef je tekst en uitleg over je model. Wat heb je gebouwd en welke betekenis heeft het. Na deze ronde volgt de reflectie, m.a.w. wat gebeurde er precies?

Ik wil jullie graag meenemen in een toepasselijke opdracht: “maak een model dat werken met Agile weergeeft”. Ik heb er het volgende model van gemaakt dat voor mij het volgende uitbeeld:

  • De twee poppetjes staan voor mij gelijk aan werken in teams. Het werken in teams is zoveel meer effectiever dan individuele werkzaamheden. Je kunt een beroep op elkaar doen en je bent in teamverband ook veel creatiever dan alleen. De poppetjes staan ook naast elkaar wat weergeeft dat er geen hiërarchie binnen een team is, iedereen in het team is gelijk aan elkaar.
  • Het groene blokje er voor beeld het gezamenlijk product weer waar het hele team aan werkt. De focus ligt op producten met het meest toegevoegde waarde, daarom ook de groene kleur.
  • De transparante voetjes van het linker poppetje staat voor transparantie. Dat vind ik een krachtig mechanisme binnen Agile en van grote toegevoegde waarde t.o.v. andere methodieken.
  • Het vlaggetje en het boompje vooraan tenslotte beelden voor mij het werkplezier en de energie uit die het werken met Agile met zich meebrengt: bovenal is het leuk om met Agile te werken.

Deze oefening deden we met een aantal mensen en ieder model was (uiteraard) anders omdat iedereen andere onderdelen van Agile belangrijk voor zichzelf vind.

IMG_5738Tot slot wil ik mijn model laten zien die ik gemaakt heb bij de vraag: “wat is de toegevoegde waarde van Lego Serious Play?” Mijn model is heel beperkt maar beeld uit dat LSP heel eenvoudig is maar dat het heel veel creativiteit biedt. Creativiteit in de betekenis van het uitbeelden in modellen maar ook in de diversiteit van toepassingen. Zo hebben wij LSP gebruikt in het uitbeelden van een Agileteam maar andere groepen waren LSP aan het toepassen voor retrospectives. En zo zijn er nog veel meer toepassingsmogelijkheden.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Intervisie

Vanuit de organisaties die vorig jaar het Agile Congres in Groningen hebben georganiseerd, zijn diverse werkgroepen ontstaan die kennisdelen over diverse LEAN en Agile gerelateerde onderwerpen als doel hebben. Agile Coaching is één van die werkgroepen.

Deze week was er wederom een bijeenkomst vanuit Samenwerking Noord in Groningen. Samenwerking Noord is een samenwerkingsverband van (semi-)publieke organisaties die als werkgevers de dreigende tekorten op de arbeidsmarkt voor ICT-personeel het hoofd willen bieden. Vorig jaar hebben we gezamenlijk met een aantal organisaties en bedrijven uit zowel de (semi)publieke als commerciële sector het Agile Congres in Groningen georganiseerd. Omdat de samenwerking goed is bevallen, is de samenwerking voortgezet in een werkgroep LEAN/Agile. Binnen deze werkgroep zijn diverse subgroepen opgezet waaronder Agile Coaching en Projectmanagement van de toekomst. Twee onderwerpen waar wij veel affiniteit mee hebben en dus mag het geen verrassing zijn dat wij (Yvonne en ik) ons bij deze groepen hebben aangesloten. Hoewel er ook andere subgroepen zijn met zeer interessante thema’s: IT leadership en management, HR en informatie/business analyse bij Agile werken. Maar soms moet je keuzes maken……..

Binnen de subwerkgroep Agile Coaching staat inmiddels een eerste bijeenkomst op de agenda. Tijdens deze meeting zullen we ons gaan richten op het begrip Intervisie. We gaan uitleggen wat intervisie inhoudt, wat zijn de spelregels van intervisie maar ook vooral wat intervisie niet is. Zo zal er een duidelijk onderscheid gemaakt worden tussen inhoud en persoon, ofwel taakgerichtheid en mensgerichtheid. intervisie gaat veel over hoe jij als persoon acteert en opereert in situaties. Als bepaalde acties niet tot het gewenste resultaat leiden, wat is dan jou rol en hoe je acteert hierin? De overige deelnemers houden je aan de hand van de juiste vraagstelling een spiegel voor waardoor je inzicht in de effecten van je handelen vergroot wordt.

Kortom, dit soort werkgroepen heeft een dubbel voordeel: andere deelnemers kunnen leren van jou inbreng in de vorm van kennis en ervaring. Anderzijds hou ik mijn kennisniveau op peil omdat ik ook weer leer van de inbreng van andere deelnemers. Deze kennis neem je weer mee in je dagelijkse werk als Agile Coach. Als de bijeenkomst geweest is, zal ik er zeker een verslag in de vorm van een blog van uitbrengen.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Moest nodig weer eens bloggen

Het is al vééééél te lang geleden dat ik een blog op mijn site heb gezet. Reden? Eigenlijk geen. Je bent geneigd om te zeggen dat je geen tijd hebt maar het heeft allemaal te maken met prioriteit

Blijkbaar heeft bloggen lange tijd niet de hoogste prio Is er dan niets meldenswaardigs gebeurd? Zeker wel, te veel om in één blog te noemen. Ik heb mij voorgenomen nu vaker en regelmatiger te delen wat ik gedaan heb, beleefd heb en waar ik een mening over heb. Natuurlijk wel alles zakelijk en Agile gerelateerd.

Vorige week heb ik op uitnodiging van ROC De Friese Poort een verhaal verteld over de voordelen van het werken met scrum. Binnen deze ROC is er een module “toerisme” en deze module wordt volgens de scrummethode gegeven (via scrum@school). Naast het vertellen over de voordelen van scrum, heb ik ze het natuurlijk ook laten ervaren. Dat zegt meer dan duizend woorden. Voor het voorstelrondje heb ik de groep gevraagd om in volgorde van kennis over toerisme te gaan staan. Daarmee stimuleer je de communicatie maar simuleer je het begrip relatief schatten. De rugbybal rondgooien tijdens het voorstellen staat garant voor lol. Daarna de ball-point-game gedaan om ze in korte tijd de werken en effecten van scrum te ervaren. Ook daarin weer veel lol maar ook duidelijk progressie.

IMG_5249Vorige week met scrum@work ook de eerste dag van de scrum praktijk opleiding voor de teams sport en cultuur binnen de gemeente SudwestFryslan. Beide teams werken al deels met scrum maar deze groep heeft behoefte om de werking eens goed uitgelegd te krijgen. Weer goede terugkoppeling gekregen. Vooral de feedback dat wij als trainers zo flexibel waren bij het kiezen van de praktijkcase. Wij hebben als trainer een case liggen maar bieden de groep ook de mogelijkheid om een eigen praktijkcase in te brengen. Ook dat is Agile: welke case heeft voor de de groep de meest toegevoegde waarde? De eigen case of de door ons voorbereidde case? We zijn met de praktijkcase mbt de sporthallen in de gemeente aan de slag gegaan. Mooie eerste dag, 16 februari dag 2.

Deze week de project startup gedaan bij Gemeente Opsterland voor de invoering en vervanging van een systeem voor het sociale domein. Gemeente Opsterland zit in een fase van ambtelijke samenwerking en daar hoort harmonisatie van systemen en processen bij. Dat klinkt eenvoudig maar bij de gemeentelijke overheid is dat altijd vervuld met politieke belangen, inzichten en voorkeuren. Dat is een situatie die uitermate geschikt is voor de scrumaanpak: complex product in een complexe organisatie. In zeer korte tijd hebben we in een workshopvorm een eerste versie van de product backlog gemaakt. Niet IT-gericht, daar mag PinkRocade iets over zeggen, maar juist businessproducten. Via inventarisatie zijn in groepjes veel (deel)producten benoemd. Deze producten zijn vervolgens geclusterd tot epics en deze zijn ingeschat. Voor de inschatting is de T-shirtsize methode gebruikt. Geen absolute inschatting, maar juist relatief. Tot slot is er al een begin gemaakt om de risico’s te benoemen. Het is (nog) geen scrumproject maar we gaan zeker scrumelementen in het project inzetten om de realisatie te versnellen. Wordt vervolgd.

Tot slot (om te delen) heb ik mij aangemeld voor een online training voor sketchnoting. Dit is een methode om gedachten, ideeën en aantekeningen niet meer uit te schrijven in tekst, maar juist in combinatie van tekeningen, schema’s, kleuren en tekst te doen. Daardoor blijft de boodschap beter in je hoofd zitten. Ik wil dit voor mijzelf inzetten, maar natuurliik op termijn ook voor de trainingen. En echt als laatste heb ik mij ingeschreven voor de training tot Agile Coach. Vorig jaar heb ik de tray out van 1 dag al gedaan maar ik wilde de gehele training toch ook nog volgen. Afgelopen december ging de training helaas niet door, maar hij staat nu gepland voor 18 en 19 februari. Beloven twee leerzame en inspirerende dagen te worden. Ik heb daar nu al zin in.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Agile werkt niet, denk eerst maar eens logisch na

Ondanks dat ik erg enthousiast ben over Agile en geloof in de methodiek (mits goed toegepast), zijn er ook genoeg mensen die geen vertrouwen in Agile hebben. Ik vind dat we ook naar diens argumenten en twijfels moeten kijken. Al was het alleen maar om er zelf stil bij te staan en er van te leren.

Onlangs stuurde een collega mij een link naar een artikel waarin de auteur, Lajos Moczar (senior strategie consultant), in zijn eigen bewoording aangeeft waarom Agile niet werkt. In zijn betoog noemt hij drie argumenten:
1. Een groeiende lijst met defects.
2. Changes met (te) grote gevolgen
3. Gebrek aan goed projectmanagement

Een belangrijk Agileprincipe is dat er snel en continue waardevolle software opgeleverd moet worden. Hierdoor bestaat het gevaar dat fouten en defects niet gedurende de sprint opgelost worden maar op de product backlog gezet worden om in een later stadium opgepakt te worden. Als dit lang genoeg volgehouden wordt, ontstaat er een enorme lijst met defects die niet meer te managen is. Volgens de auteur van het artikel is negeren van defects (en niet oplossen) volgens Agile de normaalste zaak van de wereld. Gevolg daarvan is dat er een niet te onderhouden systeem ontstaat.

Het tweede gevaar volgens de auteur is dat Agile op ieder moment in het project wijzigingen toestaat, dit conform het principe van “het aansluiten op veranderende behoeftes”, ook gedurende het project. Waar Agile geen rekening mee houdt is het verschil in kleine en grote wijzigingen. Naarmate een project en daarmee de hoeveelheid code vordert, neemt de impact op wijzigingen alleen maar toe. Wijzigingen kunnen in het begin een minor impact hebben maar kunnen grote gevolgen hebben indien ze in een later stadium doorgevoerd worden. Met wijziging in structuur en architectuur tegen het eind van het project, neemt de kans op rework alleen maar toe. Parallel daaraan ook de kosten om de wijzigingen door te voeren. Mensen voeren vaak de Agile-methodiek als excuus aan om op ieder moment wijzigingen door te voeren zonder een degelijk change management proces.

Als laatste tegenargument heeft de auteur geen vertrouwen in zelfsturende en zelforganiserende teams met een scrummaster. Er zal altijd verantwoordelijk projectmanagement gevoerd moeten worden om het project tot een succes te maken.

De auteur heeft meer vertrouwen in het denken in Agile dan het doen in Agile. En Agile denken is met gezond verstand prima te realiseren. Denk eerst maar eens goed na over hoe je de huidige projectvoering zou kunnen veranderen. Hij noemt daarvoor drie principes:
1. Prioriteiten stellen
2. Pragmatisme
3. Dynamiek

Iedere projectmanager zou de kwaliteit moeten hebben om een projectplan op te stellen om het meest belangrijke te realiseren. Daarbij is altijd het uitgangspunt om op tijd goede software op te leveren en binnen het budget te blijven.

Pragmatisme is voor programmeurs moeilijk aan te leren. Vaak verzanden discussies in academische, abstracte en theoretische discussies en wordt de praktijk en praktische toepasbaarheid uit het oog verloren.

Dynamiek is nodig om tijdens het project van plan en strategie te switchen als je merkt dat de gekozen strategie niet werkt. Niet oneindig lang vast houden aan het plan maar de gave hebben om van plan te veranderen.
Kortom, Agile belooft oplossingen die het niet waar kan maken, is niet transparant in de ontwikkelkosten en voorkomt effectief management. In tegenstelling tot wat beloofd wordt, leidt dit tot lang lopende projecten, ontevreden klanten en een overall ineffectieve inzet van IT. Wat nodig is, is het denken in Agile en niet het inzetten van Agile als methodiek.

Lajos Moczar

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren

Seminar “Nu: Scrum op school”

In het voorjaar van 2015 heb ik samen met Ellen Reehorst het seminar “Nu: Scrum op School” over het inzetten van scrum binnen het onderwijs.

Op woensdag 5 maart 2015 was het eerste seminar van “Nu: Scrum op School” dat ik samen met Ellen Reehorst van EduScrum heb georganiseerd. Het seminar bestond uit twee delen waarbij Ellen het toepassen van Scrum als lesmethode (Scrum@school) toelichtte en bij mijn de nadruk op het toepassen van Scrum in de schooloroganisatie lag. Zoals bekend is Scrum als projectmethode geschikt voor complexe projecten, complex wat product betreft als complex in omgeving. Projecten binnen schoolorganisaties zijn vaak creatieve processen in een complexe organisatie, zeer geschikt voor de scrummethode.

Nadat we de eerste aankondiging van het seminar hadden gedaan stroomden de aanmeldingen binnen. Het ging zelfs zo hard dat we veel geïnteresseerden op de wachtlijst moesten zetten. We waren die eerste middag te gast bij Yacht in Groningen, een bedrijf dat al jaren actief met Scrum bezig is. De middag werd geopend door Fiora van den Bosch, professional bij Yacht. Zij heette de 40 aanwezigen van harte welkom en zette kort uiteen waarom Yacht graag de host van de middag wilde zijn. Daarna mocht ik namens het Agile Competence Center het raamwerk van Scrum schetsen en de mogelijkheden om deze projectmethodiek in te zetten voor complexe projecten binnen scholen. ‘Curriculum ontwikkeling, een beleidsplan opstellen, een module ontwerpen – Scrum kan ook op scholen zorgen voor snelheid, plezier en kwaliteit.’ Ik begin altijd graag met de spaghettigame, omdat hiermee in zeer korte tijd veel facetten van Scrum worden behandeld: teams doen het werk, niet de managers. De deelnemers aan het Seminar lijken het daarmee eens; in no-time plakken zij tientallen post-itjes met kansen voor Scrum in de schoolorganisatie.

Na interessante vragen en discussies, was het woord aan Ellen Reehorst. Ook in de klas biedt Scrum mogelijkheden: Scrum@school is de Nederlandse onderwijsbewerking van Scrum, die afgelopen jaar op 20 scholen is geïntroduceerd. Ellen Reehorst (Scrum@school) laat zien hoe fanatiek leerlingen met eduScrum werken. De ervaringen met Scrum@school zijn zeer positief en de reacties van leerlingen die hier mee werken zijn motiverend. Het korte filmpje met een willekeurige les Scrum@school, opende voor de aanwezige docenten de ogen. Zij willen het naadje van de kous weten, maar het advies blijft ‘don’t try this at school tomorrow’ – Scrum@school doe je goed voorbereid of niet.

Vanwege het aantal mensen dat we voor de eerste sessie moesten teleurstellen, hebben we een tweede sessie georganiseerd op 2 april bij TKP Pensioen in Groningen. Onder de noemer “Onderwijs leert van TKP” waren ruim dertig docenten, schoolleiders en opleidingsmanagers uit VO en mbo op deze zonnige aprilmiddag bij TKP Pensioen te gast. Wat beweegt TKP Pensioen om de tweede editie van het Seminar ‘Nu: Scrum op School?’ te hosten? En vooral: welke meerwaarde heeft deze bijeenkomst voor beide partijen? Harry Boekhoudt van TKP Pensioen opent het Seminar met een bevlogen verhaal over de ervaringen van TKP met Scrum. ‘Ik merk dat de teams snel volwassener worden en veel meer bezig zijn met de waarde van wat ze opleveren. We laten daar straks graag wat van zien, dat geeft ons energie.’

Na de sessie van Ellen en mijzelf was het toetje van de bijeenkomst een kijkje in de Scrumkeuken van TKP. Harry neemt de schoolleiders mee naar zijn kamer, waar hij laat zien hoe je met post-its van een beleidsplan een dynamisch en transparant actie-universum kunt maken. Scrummaster Ard vertelt docenten trots over de werkwijze van zijn team en illustreert dat staand aan het Scrumbord. De gasten kijken hun ogen uit en vinden het boeiend om iets van de praktijk van Scrum mee te maken. ‘Nu heb ik nog veel meer vragen’ zegt een van hen verlekkerd. Als feedback aan TKP schrijven zij onder meer: ‘Dank voor jullie openheid, enthousiasme en boeiend vertelde ervaringen!’

Zien hoe Scrum in een bedrijf wordt ingezet, voelen hoeveel dit energie oplevert – voor onderwijsmensen een inspirerende ervaring, die vast tot Scrum experimenten op scholen gaat leiden. Veel dank dus aan zowel Yacht als aan TKP.

Delen
Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this pageShare on Google+

Op dit bericht reageren