scrummaster.nl

Some rights reserved by happiercircumstance

De Stacy Matrix is een van de theoretische achtergronden van Scrum. De theorie verdeelt het domein op twee assen, waarbij de X-as de zekerheidsgraad aangeeft en de Y-as de overeenstemmingsgraad. De positie op de beide assen bepaald welke strategie de meeste kans op succes heeft. Scrum projecteert op de Y-as, de overeenstemmings-as, de te ontwikkelen oplossing. Heeft de product owner de gevraagde functionaliteit scherp op het vizier, of nog geen idee wat er moet gebeuren? Klopt de functionaliteit nog bij de huidige situatie?

Maar aan die onzekerheid heb je niets aan als je echt iets wilt gaan maken, op dat moment is het toch wel handig dat de product owner weet wat hij wil en zou het toch ook fijn zijn dat de ontwikkelaars weten dat ze het kunnen maken. Dat is precies waarvoor de sprint planning voor is. In de Sprint planning wordt als het ware een foto gemaakt van dat moment, technologie en domein worden als het ware bevroren.

Het eerste deel van de sprint planning heeft als doel om ervoor te zorgen dat de overeenstemming tussen product owner en team over wat een item precies betekent groot is. Het team kan de product owner bevragen wat de bedoeling is, wijzen op eventuele beperkingen en door discussie onderling ook wat er moet gebeuren in foutsituaties.  Na deze meeting moet het duidelijk zijn wat de product owner gaat krijgen. Zou de product owner bij wijze van spreke de rest van de Sprint niet meer beschikbaar zijn maar wel zou komen opdagen bij de Sprint Review dan zou hij bij de demonstratie niet verrast moeten zijn over wat hij gekregen heeft en het team zou zeker moeten kunnen zijn dat het item af is.

Komt de product owner de sprint planning in met een zeer gedetailleerde uitwerking van het backlog item – zeg maar een ouderwetse specificatie – dan is er voor het team geen ruimte om te kijken hoe het item het beste in de technologie past. Het kan zijn dat de huidige technologische kennis van de groep onvoldoende is om het item precies zo te realiseren, maar daar zal de product owner geen genoegen mee willen nemen. Het moet zoals geschreven en daarvoor hebben ze tenslotte toch de beste software ontwikkelaars in dienst genomen… Het team staat onder druk om het toch maar uit te voeren en voelt zich niet serieus genomen.

Het zou ook kunnen zijn dat het team juist meer technische kennis heeft dan dat het gedetailleerde item nodig heeft. In plaats van deze ruimte te kunnen gebruiken is de kans groot dat het team die ruimte niet ziet, door de gedetailleerde omschrijving wordt de creativiteit niet aangesproken en blijven de suggesties achterwege. En als ze wel komen dan is er een kans dat de product owner – die waarschijnlijk redelijk veel moeite heeft gedaan om het correct te krijgen en af te stemmen – de suggesties niet in overweging zal nemen. Product owner en team gefrustreerd. De Product owner omdat het team maar blijft zagen terwijl het toch duidelijk is wat hij wil en het team omdat de product owner maar niet de verbeterde voorstellen wil inzien.

Ook niet onwaarschijnlijk is dat de product owner eigenlijk nog geen idee heeft wat het item precies zou moeten zijn, tenslotte heeft hij de rest van de tijd ook ander werk moeten verrichten en is helemaal niet aan de items toegekomen. Het item zit in dat geval nog helemaal bovenin de overeenstemmings-as, er is eigenlijk geen overeenstemming. Je zou verwachten dat soort items snel zouden sneuvelen in een sprint planning, maar dat lijkt toch niet het geval te zijn. Zowel team als product owner accepteren dan die onzekerheid. De product owner schuift een stuk verantwoordelijkheid richting het team, onder het mom dat het team de professionals zijn. Dat zijn ze ook, maar vooral op het technische gebied en de product owner juist op het bedrijfsgebied. Het risico van dit scenario is dat er gedurende de sprints nog veel beslissingen genomen moeten worden. En als de product owner daar niet gelijk antwoord op kan geven komt de uitvoering van het item ernstig in gevaar omdat het team moet wachten op antwoorden. Een ander risico is dat er een plotseling een antwoord komt waardoor het team verzucht ‘als we dat hadden geweten hadden we het heel anders gedaan’. En probeer dan nog maar eens voor die technisch betere oplossing te kiezen… Resultaat is dat de oplossing sub-optimaal in de al gekozen richting geduwd wordt, deze problemen komen later terug, en dan is de gekozen oplossing plotseling niet meer de snelste oplossing.

Wat hierboven nog positief is is dat er vragen gesteld worden aan de product owner, maar wat is de kans dat die vragen – of niet alle – worden gesteld. Natuurlijk, communicatie is heel belangrijk, enzovoort, maar in praktijk gaat niemand steeds vragen stellen en vult de mogelijk oplossing grotendeels zelf in. Gelukkig maar want het lijkt mij een niet werkbare situatie als iemand steeds maar weer vragen stelt – en dan een heel team. Hebben product owner en team geluk dan ontdekken zij eventuele foute keuzes ruim voor het einde van de sprint, zodat het item nog te corrigeren is. Helaas brengt dit de uitwerking van de sprint in gevaar want op deze keuzes zijn weer andere keuzes gestoeld en is men weer met andere items aan de slag gegaan.

Hebben ze pech dan komen ze er pas achter bij de sprint review als die ene slimme bezoeker iets opmerkt of vraagt. Daar gaat het ego van product owner en team! Maar wat als die slimme bezoeker die dag er niet is, het niet ziet of niet zegt?

Creative Commons License by Eneas

Het leuke van een groot bedrijf is dat je de hele tijd nieuwe mensen blijft ontmoeten. Zo hoorde ik bij de koffie automaat een paar, voor mij tot dan onbekende, collega’s praten over hun Daily Scrum. Ik kon even stiekem mee blijven luisteren en aangezien ze mij ook niet kenden verwachtten ze geen inbreng van mijn kant.

De Daily Scrum deden ze inderdaad dagelijks, en met het hele team. En zover ik begreep voldeed het redelijkerwijs aan het formaat van ‘wat deed je, wat ga je doen en wat zat er in de weg’. Alhoewel, dat laatste weet ik niet heel zeker.

Hun gezamenlijke klacht was echter dat ondanks de Daily Scrum de Sprint niet gehaald werd. Iedereen noemde de dingen die hij gedaan had en na de Daily Scrum ging men gewoon verder. Aan het eind van de Sprint was wellicht 60% van de dingen gedaan. Dit ging Sprint na Sprint zo.

Voor mij was dit het moment waarop ik mij afvroeg of ze dan de volgende Sprint wat met het bereikte resultaat deden voor hun nieuwe planning en dus besloot ik mij in het gesprek in te mengen. Ze wisten mij te vertellen dat ze inderdaad hun velocity bij hadden gesteld maar dat dit probleem echter bleef. Read more »

Wil je als team of bedrijf verbeteren dan zul je, net als sporters, daarvoor moeten gaan trainen. Dat hoeft niet altijd een cursus te zijn. Ook intern, zelf zonder budget zijn er uitstekende mogelijkheden die beter werken dan externe dure cursussen. Een interactief en ervaringsgericht concept is bijvoorbeeld de coding dōjō.

Een dōjō is de zaal waarin men op een veilige manier werkt aan zijn of haar vaardigheden van diverse Japanse vechtkunst en -sporten zoals Jiu-Jitsu, Judo, Karate en Aikido. Dit gebeurt onder andere met kata’s (型) en randori’s (乱取り).Een kata is puur gericht op de vorm en kent vaststaande stappen en technieken. Een randori is vrijer en interactiever. Een deelnemer wordt geplaatst in een gecontroleerde en veilige aanvalssituatie.

Een coding dōjō is een bijeenkomst van een aantal ontwikkelaars die bij elkaar komen om een uitdaging aan te gaan en om daarmee hun vakmanschap te verbeteren door te delen en te observeren en plezier te hebben. Dit kan met behulp van een oefening met vaststaande stappen (kata) of met een interactievere vorm (randori).

Een randori stijl coding dōjō is eenvoudig op te zetten. Het enige wat je nodig hebt is een ruimte waarin je een computer op een beamer kan aansluiten en voldoende stoelen om iedereen plaats te geven. Er zijn steeds twee mensen bezig met het probleem verder te brengen en de rest van de aanwezigen mag zich actief bemoeien met de oplossing. Om de paar minuten (5…7) wisselt een van de twee voor iemand uit het publiek en begint een nieuwe ronde. Interactiviteit en plezier verzekerd.

In lijn van de toepassing van de Japanse vechtsport termen wordt bij de coding dōjō de facilitator sensei genoemd, maar het blijft uiteindelijk faciliteren. Mocht je de rol van facilitator op je nemen dan zou ik je de volgende punten willen meegeven die ik ervaren heb:

1. Vraag je ten eerste af of de groep deelnemers die je uitgenodigd hebt überhaubt wel de technieken onder de knie heeft. Is er een groep die eigenlijk nog nooit iets met Test Driven Development gedaan heeft dan zullen zij niet spontaan begrijpen hoe ze het moeten aanpakken en wat de anderen eigenlijk aan het doen zijn. Voor hen is het verloren tijd, met veel discussies over het nut van TDD. Wellicht is het dan een betere optie om eerst een keer uit te leggen hoe TDD werkt.
2. Voor het kiezen van een opdracht zijn diverse voorbeeld kata’s beschikbaar op internet en vaak ook uitwerkingen. Stel jezelf dus de vraag hoe vroeg je van te voren bekend wil maken welk kata je wilt gaan gebruiken. Een aantal deelnemers zullen van te voren gaan kijken naar mogelijke oplossingen van iemand anders. Daarna is het moeilijk om niet het idee van die ander als basis te nemen als je het gezien hebt. Het beperkt dus de creativiteit.
3. Ook zijn er altijd mensen die die voorbereiding niet gedaan hebben, het gevolg kan zijn dat zij minder gaan participiëren. Je geplande randori stijl sessie veranderd daarmee meer naar een demonstratie, kata stijl. Dat hoeft niet fout te zijn, maar neem het mee in je overweging.
4. Zorg voor voldoende kopieën van de opdracht. Iedereen moet de opdracht tot zijn of haar beschikking hebben om zo het op zich in te laten werken, om het proces te laten werken. Een opgehangen opdracht heeft als probleem dat het niet leesbaar is vanuit de zitplaatsen van de deelnemers. Die moeten dan actief naar de opdracht toe lopen. Velen zullen dat niet doen, of uitstellen, en vergeten dan de details. Met als gevolg dat het niet meer te volgen is en ze dus minder mee gaan doen.
5. In tegenstelling tot een retrospective is het verstandig om actief te faciliteren. Het is geen oefening in groepsdynamiek, maar het zal blijken dat als je niet actief stuurt op de groepsdynamiek het meer een probleem gaat worden van hoe een groep mensen actief moet samen werken dan een oefening in de aangeboden kata. Leg desnoods af en toe de sessie stil en vraag de groep om eerst even na te denken. Het kan blokkerend werken voor hen die achter het toetsenbord zitten als de rest van de aanwezigen vol enthousiasme allerlij aanwijzingen zitten te roepen. Stimuleer hun om zelf te bepalen welke eerstvolgende test ze wensen te gaan implementeren. Ook bij een randori geldt dat als je niet weet waar je heen wilt je er ook niet gaat komen.
6. Verder kan ook blijken dat er sterke meningen zijn over stijl en aanpak. Deze sterke meningen kunnen tot verhitte discussies leiden die de aandacht weghalen van de eenvoud van de opdracht en zorgen voor een negatieve sfeer in de groep. Deze negatieve sfeer beïnvloed het vermogen van alle aanwezigen om te leren. Een coding dōjō gaat niet om stijl maar effectiviteit.
7. Dezelfde sterke meningen kunnen er ook voor zorgen dat bij elke ronde een stuk werk van de vorige weer wordt weggehaald. Daar waar de ene het prima vindt om een variable array door te geven veranderd de andere dat weer doodleuk in een lijst. Waar de ene een for-each loop gebruikt verandert de andere dat weer in een gewone for loop. Refactoren is prima, maar men kan er ook in blijven hangen.
8. 5..7 minuten wissel regel kan er voor zorgen dat de twee mensen die de oplossing ontwikkelen steeds in de fase blijven hangen om bij elkaar af te tasten wat zij als oplossing denken te zien. Dit met de druk dat je voor een groep mensen met ‘betere meningen’ zit kan een writer’s block veroorzaken.

Een sessie is geslaagd wanneer binnen de beschikbare tijd de oplossing gemaakt is en de deelnemers het gevoel hebben dit ook zelf te kunnen doen. Het is een succes als in ieder geval een aantal deelnemers het gevoel heeft dat ze iets van een ander geleerd hebben, een nieuwe strategie of techniek die ze zelf graag willen gaan toepassen.

はじめ!

Projectmatig werk wordt over het algemeen in teams uitgevoerd. De meeste software projecten zijn te groot om in een acceptabele tijd door één persoon tot een succesvol einde te brengen. En met het onstaan van een groep die een project gaat uitvoeren onstaat er teamwork. Alleen onstaat teamwork niet zomaar.

Er is vaak wel aandacht voor het doel dat het team dient te halen. Het ‘wat & hoe’ is één as die nodig is om tot een team te komen. Traditionele projecten proberen dit vanaf het begin af aan vast te leggen en spenderen veel tijd en energie in het controleren en bijwerken van dit aspect van een project. Hiermee wordt een groep mensen echter geen team. De onderlinge taken zijn wellicht vastgelegd, maar een team is geen groep individuen die slechts zijn taken uitvoert. Een team is een groep mensen die op een effectieve manier kan reageren op onverwachte gebeurtenissen, buiten hun eigen taakstelling.

Er is echter nog een as nodig, het proces. Door toevoeging van proces kunnen mensen met elkaar gaan samenwerken. Het maakt duidelijk wie wat van elkaar mag verwachten en waar de grenzen liggen. Traditionele en agile projecten voegen beide een nog een ‘proces’ aspect toe. Traditionele processen richten zich echter vaak op het ‘wat & hoe’ zoals risico management, exception management en change control boards. Agile frameworks richten zich vaker op het kunnen reageren op onverwachte gebeurtenissen – ze verwachten het onverwachte – door middel van iteraties, daily standups en retrospectives.

Deze aspecten worden het ‘harde proces’ genoemd en Scrum stelt hiervoor de ScrumMaster verantwoordelijk. Hij is uiteindelijk degene die ervoor zorgt dat het team het proces volgt. Hij zorgt ervoor dat de Product Owner voorbereid is als hij bij de Sprint Planning aan schuift, hij zorgt ervoor dat de juiste aspecten besproken worden tijdens de Daily Scrum. Bij niet iedereen doed de ScrumMaster dit zelf, maar het voordeel van iemand die zich met dit aspect bezig houdt is dat de rest van de teamleden zich met de resultaten kunnen bezighouden zonder dat het proces er onder gaat lijden. Het combineren van een ScrumMaster en ontwikkelaarstaak is om deze reden heel moeilijk te doen.

Om het team nog succesvoller te maken moet er ook aandacht zijn voor de zachte kant van het proces. Hoe voelen de teamleden zich? Kunnen ze het werk nog aan? Hebben ze te veel hooi op de vork genomen of maken ze zich er gemakkelijk van af? Werken de afgesproken processen werkelijk of blijkt dat het onderhuids toch stiekem irriteert?

Alhoewel een retrospective de ultieme plek lijkt om aandacht te hebben voor de zachte kant is het de vraag of dat gebeurt. Teams die onvoldoende aandacht hebben gehad gedurende de iteratie voor die zachte kant zullen die niet plots gaan uiten bij een retrospective. De retrospectives blijven oppervlakkig en de onderhuidse gevoelens onuitgesproken. Dit resulteert in geen of wellicht slechte acties, en in de volgende keer nog meer onuitgesproken emoties.

Een lastig aspect van gevoelens is dat ze niet oppervlakkig meetbaar zijn. Ze zijn niet op te delen in deeltaken, noch te beschrijven in ceremonies. Degene die de emotie waarneemt neemt slechts zijn interpretatie van de emotie waar, beïnvloed door zijn eigen perspectief en emoties. Degene die de emotie heeft hoeft zich niet bewust te zijn van deze emotie of drukt deze weg, onzeker of de rest van het team op het uiten hiervan zal reageren.

Het wordt als professioneel beschouwt om je niet te laten beïnvloeden door je emoties. Toch bepalen die emoties direct hoe je je werk uit voert. En het team wordt beïnvloed door de diverse emoties van elk individueel team lid. Het niet onderkennen van deze emoties, het niet bespreekbaar maken zorgt voor een team waarin iedereen afstand houdt.

Als ScrumMaster kan je je effectiviteit verhogen door oog en oor te hebben voor dit zachte aspect. En door je eigen effectiviteit hierin te verhogen vergroot je de cohesie en effectiviteit van het team. Je creëert een vangnet waarin mensen zich veilig gaan voelen, wetende dat als het mist in gaat iemand dat op zal merken om ze op te vangen. Door dit vangnet kunnen de angsten waardoor men zich inhoudt vrij gelaten worden en gaat het team verder dan ze eerder durfden te gaan.

Bedrijven worstelen met de rol ScrumMaster. De toegevoegde waarde lijkt lastig te definiëren en vervalt soms tot een taak die eenvoudig te roteren is onder de teamleden. Daarmee is het een overhead taak geworden, een taak die weg geoptimaliseerd zou kunnen worden. Door je als ScrumMaster niet alleen te richten op de harde kant van het proces, maar ook te richten op de zachte kant, maak je de taak van een ScrumMaster zeer waardevol en geef je het team de kracht om tot volle wasdom te komen.

Documentatie is een belangrijk onderdeel van een software project. Requirements dienen opgeschreven te worden en architectuur en design opgeslagen in UML documenten. Allemaal met de goedbedoelde gedachte dat het in een later stadium gaat helpen voor iemand anders.
Read more »

Het valt me steeds vaker op. Er ‘moet’ steeds meer, en bepaalde aanpakken worden tot standaard verheven. Als je Agile wilt zijn dan moet je je conformeren.

Onbewust viel het me al een tijdje op, maar de eerste bewuste ervaring had ik vorig jaar bij Agile Open Holland. Ik was geïntereseerd in hoe anderen hun Sprint II planning doen en had dus een sessie voorgesteld. In plaats dat er verhalen kwamen over hun ervaringen kreeg ik een spervuur van vragen over mij heen die mij eigenlijk er van probeerde te overtuigen dat ik het fout deed. Zo waren volgens mijn gespreksgenoten de stories véél te groot, die moesten in kleinere stukjes opgehakt worden.

De aannames die hier gemaakt werden was dus dat je stories moet gebruiken en dat je ze in kleine stukjes moet verdelen. Jazeker, dit is een advies dat je vaker hoort en wellicht in veel gevallen een goed werkend mechanisme, maar het moet niet. Voor ons voegde het simpelweg niet zo veel toe. Wij hadden een goed werkend mechanisme, passend bij onze omgeving.

Maar dat is blijkbaar onvoldoende. Zo lijkt het tegenwoordig verboden om een Sprint Burndown bij te houden, je moet eenvoudig taken tellen. Taken maken? Is ook overbodig en een waste. En waste moet je met harde hand uitbannen. Nadenken voordat je iets doet? Verspilling! Niemand doet dat meer. Dus wat betreft mijn vraag over Sprint II planningen, zo old school.

Schrijf je nog code zonder xUnit tests? Heb je geen geautomatiseerde acceptance testen? Fout, fout fout. Sprints langer dan één week? Onmogelijk! Release je nog om de 6 maanden? Ben je gek? Reken je nog met uren? Oh, zelfs voor taken? Mag niet, had ik al gezegd dat taken ook verouderd zijn?

Het is zelfs al teveel om te pogen om Scrum ‘puur’ te implementeren, wat dat is te verstorend voor de organisatie, en kom zeg, je gaat toch niet Scrum by the book doen? En hele Sprint lang de inhoud constant houden? Dat kan geen enkelijke organisatie meer volhouden. Veel te lang.

Ooit, in het begin van Agile schreef men Individuals and interactions over processes and tools.Ik denk dat men zat was dat er vele ‘verplichte’ werkzaamheden waren die niet werkten en afhankelijk van de context waren. Soms konden ze best werken en hadden ook hun waarden, maar vaak ook niet.

Tien jaar later zitten we met een Agile community die proces wel degelijk stelt boven personen en hun interacties. Het corset wordt strakker en strakker getrokken.

Behalve verplichte werkwijzen is ook de groei aan tools enorm. Nu hoeft er niets mis te zijn met tools, toch is het tekenend hoeveel er zijn en hoe veel ze gebruikt worden. Zijn er überhaubt nog mensen die Post-Its™ gebruiken voordat ze een tool gaan toepassen?

Scrum is een licht gewicht framework. Er wordt heel veel niet in bepaald. Dat is voor jou om te bepalen hoe je dat doet. Geniet van die vrijheid en bepaal dat lekker zelf. Nét genoeg, niet meer.

Het populaire boek “Mannen komen van Mars, vrouwen van Venus” beschrijft hoe mannen en vrouwen van elkaar verschillen. Het boek is zelfs zo populair dat de titel min of meer een gezegde is geworden. Vele studies worden aangehaald om te bewijzen dat er inderdaad een bijna onoverbrugbaar verschil is.

Maar is het ook werkelijk het geval? In het boek ‘Waarom we allemaal van Mars komen’ onderzoekt de schrijfster de aangehaalde onderzoeken om vervolgens te concluderen dat de resultaten gefilterd worden om de stelling te bekrachtigen.

Het is naïef om te denken dat dit niet zou gebeuren in ‘onze’ agile community. Ook de boeken die tot de vaste literatuur behoren staven hun uitspraken met referenties. Maar kloppen die referenties wel?

In ‘De Slinger van Foucault’ zijn de hoofdpersonen werkzaam voor een uitgeverij die wat we nu ‘New Age’ boeken noemen. Het boek haalt aan hoe die boeken door naar elkaar te refereren hun eigen waarheid creëren. Klakkeloos citeren ze elkaar. Omdat het hier en daar staat is het dus waar.

Steeds meer boeken over Agile doen dat ook. Waar het originele Scrum boek het vooral moest hebben van externe studies hebben de nieuwere boeken het vooral over reeds bestaande boeken over Agile en refereren ze aan totaal oncontroleerbare bronnen zoals blogs. En hoera, ze zijn het allemaal met elkaar eens en verkrijgen daarmee een status van juistheid.

De uitdaging die blijft is het kritisch lezen van boeken en blogs, hoe fijn het ook mag zijn dat ze je denkbeelden bevestigen. Waar haalt de auteur zijn informatie vandaan en on hoeverre misbruikt hij die om zijn ideeën een waarheid mee te geven?

Dit artikel kan natuurlijk niet compleet zijn zonder dat ik als auteur openheid van zaken geef. In ‘Mannen komen van Mars,Vrouwen van Venus’ heb ik ooit een paar bladzijden gelezen om het vervolgens verveeld aan de kant te gooien. De laatste keer dat ik de ‘Slinger’ heb gelezen is denk ik meer dan 15 jaar geleden. Een ‘Waarom we allemaal van Mars komen’ heb ik helemaal niet gelezen, ik heb slechts een artikel in “Psychologie Magazine” erover gelezen…

Natuurlijk, al diegenen die volgens het boekje (A)TDD doen en hun code voorzien van xUnit tests en SLIM/Fitnesse, Cucumber en bij elke build de volledige regressie test runnen zullen dit niet herkennen: soms doet het programma toch niet wat je eigenlijk zou willen. De meeste mensen noemen dat een defect, alhoewel de scheidslijn tussen een echte fout en nieuwe functionaliteit erg dun kan zijn.

Voor hen die dankzij (A)TDD en wat nog meer 100% correcte programma’s opleveren is dit artikelen weinig interessant. Voor hen die toch nog, ondanks al hun moeite en effort geconfronteerd worden met defects biedt dit artikel advies over hoe defects te schedulen. En, als lezer mag je ook stiekem toegeven er nog steeds fouten in de software zitten. Niemand zal het horen….

Read more »

Zichbaar vermoeid kwam Ken Schwaber het zaaltje binnen. Hij had net de hele dag zijn Product Owner cursus gegeven, het diner was net op, en nu kwam nog een avond programma, de door Codecentric Nederland georganiseerde meetup voor de cursisten plus enkele genodigden.

Aangezien er geen voor opgestelde presentatie was, het zou een interactieve avond worden was het voor Ken duidelijk even moeilijk om te beginnen. Er kwam niet direct veel input van de aanwezigen – de cursisten hebben natuurlijk de hele dag alle vragen al kunnen stellen. Met het verzoek vanuit het publiek “hoe ‘verkoop’ ik Scrum aan mijn management” kon hij beginnen om zijn verhaal op te hangen.

Read more »

Yesterday I visited the Agile Stammtisch in Düsseldorf which held a meetup about the Agile Lean Europe movement. Olaf Lewitz wrote a nice summary of what was discussed at that evening. I joked that I attended because I wanted to put the E (of Europe) in the topic of the evening.

The Agile Stammtisch Düsseldorf is a local, Düsseldorf based (suprise, isn’t it?) iniative. Despite that the people present were German, Dutch and Norwegian. So at a single evening we represented a network of European Agile enthousiasts. At that evening we strengthened the nodes between at least three countries (and that doesn’t even include the Country of Cologne…).

To me this is what the ALE could be: meeting people from other countries, building up a network of likeminded people over Europe. Maybe the ALE movement brings us that we should, as Europeans, be aware that we must actively be aware of opportunities to connect to other countries, to look over our bounderies, creating an open mind to do so. How much more ALE than this could this evening have been?

I’m hoping I will return to Düsseldorf once in a while, despite that it is every time at my busy, completely booked, Thursday evening. If so I will at least have done a small part to strengthen the European Network.