Valueminds Agile Meetup Breda

Aankondiging: Agile Meetup Breda #4

Op 25 september is alweer de vierde Agile Meetup Breda van Valueminds! Je kan je hier aanmelden. De agile community in Breda bestaat inmiddels uit bijna 150 leden. Mocht je op 25 september niet kunnen, kan je je wel aanmelden voor de agile groep Breda, zodat je altijd op de hoogte blijft van de laatste meetups.

Het thema op 25 september is ‘Liberating Structures’. Dit is een verzamelijk van faciliteertechnieken voor allerlei meetings ene events die de laatste tijd steeds meer genoemd worden. De term is uitstekend gekozen, het zijn structuren om meetings te faciliteren, die je niet begrenzen maar juist heel veel ruimte genereren voor creativiteit en innovatie.

Tijdens de meetup zullen we globaal kijken naar het gehele idee van Liberating Structures, en we gaan ook met een aantal van de technieken praktisch aan de slag. Het is een mooie meetup om je toolbox verder te vullen met materiaal om nog meer succes vol te zijn in je rol. Je kan naar de meetup komen als je nog weinig ervaring hebt met agile werken, of als je juist al heel veel ervaring hierin hebt: iedereen is welkom!

De Agile Meetup Breda wordt zoals altijd georganiseerd vanuit Valueminds, maar we werken graag samen met andere partijen! Zo zullen we deze keer waarschijnlijk meeten op de locatie de Avans Hogeschool in Breda.

De meetup is op 25 september en duurt van 16:00 uur tot ongeveer 20:00 uur. Aanmelden kan dus hier! Voor meer informatie kan je altijd contact met ons opnemen door even te bellen (085 273 19 54) of te mailen. Tot dan!

Ps: André gaat ook spreken op 18 september bij de Meetup Agile & Robotica in Eindhoven. Hier kan je je ook voor aanmelden!

 

Backlog refinement Valueminds

Backlog refinement – hoe zit dat nou precies?

De backlog refinement is een activiteit in Scrum waar veel onduidelijkheid over is. De scrum guide behandelt het niet als een meeting zoals de sprint planning of de retrospective. Die meetings hebben een duidelijke plaats aan het begin of het einde van de sprint. Maar de backlog refinement (verder: refinement) heeft niet 1 duidelijke plaats in de sprint, en wordt dus terecht wat anders behandeld.

De letterlijke tekst in de scrum guide is als volgt: Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog verfijning worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner of naar de Product Owner’s eigen beoordeling.

Het doel van de backlog refinement is dus dat het team en de product owner gezamenlijk werken aan een goede backlog. Om dit werk wat duidelijker te maken volg ik de tijdlijn van een nieuw idee naar werkende software.

Backlog refinement Valueminds

Backlog refinement Valueminds

 

Een nieuw idee start bij een stakeholder. Misschien bij een klant die met een idee of een klacht komt, misschien bij iemand van de business die een slim idee heeft of misschien bij een developer die vanuit de techniek een suggestie heeft. Elk item dat opgepakt gaat worden door het team moet als een item op de product backlog komen en de product owner beheert deze backlog. Dus de stakeholder die een idee heeft moet in gesprek gaan met de product owner.

Dit gesprek is de eerste backlog refinement die plaatsvindt. Misschien zijn hier alleen maar de product owner en stakeholder met elkaar in gesprek. Uit dit gesprek ontstaat een helderder beeld van het idee en kan dit op de product backlog geplaatst worden. Je zou dit business refinement kunnen noemen.

Vervolgens moet dit idee met het development team besproken worden. Zij moeten helder krijgen wat er ontwikkeld moet worden en zij moeten er een inschatting van maken zodat de product owner een geïnformeerde beslissing kan nemen of zij dit item wel of niet wil laten ontwikkelen. Deze refinement kan met het gehele team gedaan worden, maar het is ook mogelijk om een eerste refinement te doen met een deel van het team. (sommigen noemen dit een pre-refinement, of prefinement). En het is zeker mogelijk om de stakeholder die met dit idee gekomen is ook uit te nodigen voor deze prefinement. Niemand kan dit idee immers beter uitleggen dan de indiener zelf. Als een idee al behoorlijk duidelijk is en de product owner er redelijk zeker van is dat dit idee snel ontwikkeld gaat worden is een refinement met het gehele team verstandig. Als het idee nog redelijk vaag is en nog even kan wachten kan het verstandig zijn om niet het gehele team in deze discussie te betrekken. Waarom de tijd van iedereen inzetten op een idee dat de discussie misschien niet overleeft?

Na de prefinement moet in ieder geval nog een ‘echte’ refinement volgen, zodat het gehele team het item begrijpt en betrokken is bij de schatting. Als het nodig is kunnen meerdere refinement sessies gehouden worden voor een item, totdat deze helemaal helder is.

Items worden tijdens de refinement geschat. Als items door de refinement discussies helder geworden zijn kunnen ze ingeschat worden en zijn ze klaar om in een volgende sprint opgepakt te worden. Het oppakken in een sprint vindt plaats in de sprint planning meeting. Als voorafgaand aan deze meeting een goede refinement plaats heeft gevonden is het eerste deel van deze meeting heel eenvoudig. We kennen onze velocity, bijvoorbeeld 30 punten, en selecteren items ter waarde van 30 punten. De product owner heeft hier een belangrijke stem in. Zij bepaalt welke items bovenaan de backlog staan en suggereert een sprint goal waar stories bij gekozen kunnen worden. Maar ook developers hebben hier een stem in. Soms is er winst te behalen door soortgelijke items als groep op te pakken. En er kan een technische reden zijn om items in een bepaalde volgorde op te pakken.

Naast het kiezen van de stories blijft dan het tweede deel over van de sprint planning, waar technische taken bedacht worden om de stories te realiseren. Dat onderwerp laat ik in deze blog verder liggen.

Het zou kunnen dat tijdens de sprint er toch nog kleine onduidelijkheden naar boven komen. Deze kunnen vaak in afstemming met de product owner nog worden verhelderd. Je zou dit de after-refinement kunnen noemen.

Valueminds blog Rene de Leijer

Combineren van de rol van scrum master en teamlid is niet verstandig

”De meeste scrum masters groeien in hun rol vanuit een functie als ontwikkelaar of als software tester. Ook ik ben begonnen als software tester en ben nu fulltime scrum master bij Valueminds. Ik mocht bij een opdrachtgever steeds meer scrum master werkzaamheden uitvoeren, waardoor ik de rol van tester en scrum master moest combineren.

Hoewel ik veel van deze periode heb geleerd, is het volgens mij niet de manier om de kracht van een scrum master volledig te benutten. Mijn mening is dat je als dedicated scrum master veel meer waarde kan toevoegen dan wanneer je een combirol vervult.

Ik kan me voorstellen dat niet iedereen het met dit statement eens is. Zelf heb ik wel eens de vraag gekregen: hoe doe je dat dan als het team waarin je werkt klein is en je rol als scrum master niet genoeg is om je dag te vullen? In dat geval kan je meer teams helpen, omdat daar ruimte voor is. Bij mijn huidige opdrachtgever begeleid ik ook twee teams als scrum master.

Mijn grootste doel als scrum master, is mijzelf overbodig maken.

Wanneer je als scrum master start met het agile maken van het team, heb je veel werk. Maar hoe volwassener een team wordt in de agile manier van werken, hoe meer zij zelf initiatief zullen tonen en nemen. Wanneer dit gebeurt, zit jouw fulltime werk als scrum master erop! Als je naast deze rol ook nog een rol in het team hebt (zoals tester of ontwikkelaar),  is er geen punt waarop je denkt: mijn werk zit erop. Je kan dan minder goed focussen op de agility van het team en je hebt minder de tijd om na te denken over het proces: wat gaat er goed in het team, en wat gaat er mis? Ook is het moeilijker om met een helikopterview naar het team te kijken, iets wat noodzakelijk is om met een frisse blik de events voor te bereiden.

Hoe moet het dan wel? 

Maar hoe kan je dan het beste de stap maken van tester/ontwikkelaar naar scrum master? Het is natuurlijk niet zo dat je na het behalen van je scrum examen meteen aan de slag kan als scrum master. Volgens mij kan je dit het beste als volgt aanpakken:

  • Zorg dat je zeker weet dat je scrum werken ‘voelt’. Het is geen kwestie van het scrum trucje toepassen, je moet zeker weten dat dit de manier van werken is waar jij achter staat. Dit gebeurt niet in 1 dag of na een paar dagen training, ik heb zelf 4 tot 6 maanden intensief met een agile coach gewerkt en dit was voor mij echt een eye opener: zo wil ik werken!
  • Vallen en opstaan is onvermijdelijk. Zoals bij alle nieuwe dingen waar je mee start, ga je in je nieuwe rol als scrum master vast en zeker fouten maken. Maar hier leer je weer van en zo kom je iedere sprint een beetje beter in je rol. Lef hebben om fouten te maken is onderdeel van het scrum werken.
  • Wanneer je start als scrum master zal je vast veel vragen hebben. Het is fijn als er een agile coach of ervaren scrum master is waar je af en toe mee kan sparren en van kan leren.
  • Houdt ons in de gaten😊: we zijn bij Valueminds bezig met het opstellen van een to-do list voor starten scrum masters, hierover horen jullie later meer!

Hoe denken jullie over dit statement? Is het combineren van de rol van teamlid en scrum master wel/niet verstandig?”

René de Leijer, scrum master bij Valueminds

planning poker kaarten Valueminds

Value points

De kosten van een user story worden in de regel ingeschat in story points, waarvoor we meestal de Fibonacci-reeks gebruiken (1, 2, 3, 5, 8, etc.). Ik heb daar zelf ook al een paar keer over geschreven (Zie mijn blogs over de story point liniaal en snel veel stories inschatten).

De waarde van een user story kan je op dezelfde manier ook inschatten. Hier is niet het development-team aan zet, maar de product owner, samen met zijn stakeholders. Om de inschattingen te kunnen doen kan je dezelfde Fibonacci-reeks gebruiken met dezelfde planning poker kaarten of je gebruikt een andere set getallen. Ik vind het zelf wel prettig werken met een reeks van 1 .. 1000, waarbij 1000 het meest belangrijk is. Je kunt trouwens nog belangrijker stories dan ook meer dan 1000 punten geven. Als je prio 1 het belangrijkste vindt moet je bij nog belangrijker naar 0 en -1, en dat wordt echt heel verwarrend.

Als je de backlog ingeschat hebt met zowel kosten als waarde, dan is een deel van de prioritering van de backlog gemakkelijk geworden. Je kunt per user story de prioriteit berekenen als business waarde / story points. Bijvoorbeeld:

Stories zoals story 4 met veel waarde en weinig kosten moet je zo snel mogelijk oppakken. Stories met weinig waarde en veel kosten (story 3) kunnen van de backlog verwijderd worden. Etc.
Nu is dit niet het enige wat de product owner mee moet nemen in de prioriteitsstelling. Technische afhankelijkheden tussen stories kunnen tot een andere volgorde leiden (je kunt story 5 pas bouwen als story 13 eerst gebouwd is). Daarnaast is het vaak ook slim om soortgelijke stories in 1 sprint bij elkaar op te pakken. Je krijgt dan een heldere sprint goal zoals: “in deze sprint doen we alle rapportage-stories”.

Als je met stories op meerdere niveau’s werkt, zoals epics, thema’s, etc. dan moet je oppassen dat je maar op 1 niveau de waarde-punten toekent. Wat mij betreft is het laagste niveau (het niveau van de user stories) de plek waar je waarde zou moeten toekennen. Als je zowel op story- als op epic-niveau waarde toekent ga je dingen dubbel tellen. De reden dat ik kies voor het laagste niveau is dat ik van mening ben dat elke user story waarde zou moeten hebben. Het toekennen van de punten op dit niveau dwingt je ook om er zo over te gaan denken.

Ik hoop dat dit zo helder is. Bij vragen of opmerkingen weten jullie me wel te vinden! (andre.heijstek@valueminds.nl / 0648476451)

Mas Mik Agile Guild Valueminds

Scrum of Projecten

Laat ik maar met de deur in huis vallen. Wat mij betreft zijn Agile/Scrum en Projectmanagement heel andere dingen. Je hoort nogal eens mensen praten over Agile projectmanagement, maar ik zie daar niet zo veel in.

In een one-liner: “in projecten breng je mensen naar het werk, in scrum breng je werk naar de mensen.

Een project is een tijdelijke aangelegenheid, met een duidelijke start- en einddatum. Projecten hebben in de regel een tijdsduur van een paar maanden tot een jaar of iets meer. Om het project uit te voeren zoek je de juiste mensen bij elkaar, en voor de duur van dat project vormen zij een team. Als het project is afgelopen dan gaat het team weer uit elkaar en worden de mensen in nieuwe projecten opgenomen. (En dan beschrijf ik hier nog de ideale situatie dat het projectteam voor de duur van het project bij elkaar blijft, in de regel wordt er hier flink met resources geschoven).

In Scrum werken we juist met vaste teams. Teams blijven voor lange tijd bij elkaar. Het werk stroomt via de product owner en de product backlog naar de teams toe. We spreken hier ook zeker niet over resources. Deelnemers aan een team zijn mensen, die we als mensen en niet al middelen bekijken.

Een project heeft in de regel de verantwoordelijkheid om een nieuw systeem te bouwen en is daarmee tot en met in-productie-name bezig met de opdracht. De fase daarna, van onderhoud en operatie behoort niet tot het project. Er is dan een overdracht van het projectteam naar het beheer team. Zo’n overdracht is altijd lastig. Veel kennis gaat verloren want de mensen die het systeem gebouwd hebben en de mensen die ermee moeten werken en het onderhouden zijn andere mensen. De beheer-afdeling die het product moet accepteren probeert met een goede ingangscontrole en acceptatiecriteria en -tests hier wat greep op te krijgen, maar in de regel overheerst toch het gevoel dat het product over de schutting gegooid wordt. Het grote probleem in deze organisatievorm is dat ‘de vervuiler niet betaalt’. Het team dat de software bouwt is niet verantwoordelijk voor de rommel die ze opleveren. De druk is altijd groot om op tijd op te leveren waardoor de kwaliteit al snel het slachtoffer wordt. De beheer-afdeling zit daar dan mee.

Bij een vast scrum team is die overdracht er in de regel niet. Hetzelfde team dat het product bouwt is ook verantwoordelijk om het te onderhouden, en vaak ook verantwoordelijk voor de operatie (in een dev-ops setting). Het mooie daaraan is dat hier de vervuiler wel zelf betaalt. Als er slecht ontwikkeld wordt, zit hetzelfde team met de problemen van moeizaam beheer. En dat leidt er in de regel toe dat er veel meer aandacht besteed wordt aan een hoge kwaliteit. En, het feit dat we met een vast team werken, leidt ertoe dat we een sterk team krijgen. Mensen raken op elkaar ingespeeld. Weten van elkaar wie waar goed in is. Zijn bereid om voor elkaar de kastanjes uit het vuur te halen.

Een bijkomend effect van deze twee verschillende organisatievormen is de bijbehorende overhead. Ieder project moet wel een rechtvaardiging hebben. Dus voordat een project kan starten moet er research plaatsvinden, moet een business case worden opgesteld en moet senior management beslissen of dit project al dan niet mag starten. In veel organisaties duurt dit vele maanden. Allerlei Prince2 documenten moeten worden geschreven en goedgekeurd. Er ontstaat dan snel de werkvorm die Jez Humble als water-scrum-fall beschrijft. Er is een lange waterval-achtige voorfase. Daarna wordt een systeem met scrum in sprints ontwikkeld, waarna er weer waterval-achtig de onderhouds- en operatiefase ingegaan wordt.

Om te bewaken dat het project zijn doelstellingen vanuit de business case waarmaakt worden er zware controles ingezet. Regelmatige rapportages zijn noodzakelijk. Iedereen moet tijdschrijven en om al deze overhead een beetje aan te kunnen wordt er dan ook maar een PMO opgetuigd, want de projecten kunnen die ballast zelf niet aan.

In een zuivere scrum context is dat allemaal niet nodig. De team zijn vast, en daarmee liggen de budgetten ook vast. Een keer per jaar (of iets vaker als dat noodzakelijk is) besluit senior management waar de prioriteiten liggen en welke teams groter of kleiner moeten worden. Daarmee liggen alle uitgaven ook vast. Een scrum-team heeft grofweg een vaste prijs per sprint. Natuurlijk, de ene sprint is het ietsje minder want dan is er iemand ziek of op vakantie, en de volgende sprint is het weer een beetje meer. Maar je hebt al heel snel een duidelijke gemiddelde prijs per sprint met wat ruis eromheen. Dat maakt de controlling in organisaties veel eenvoudiger. Tijdschrijven is daarmee grotendeels overbodig (misschien nog nodig voor externen die per uur factureren). De noodzaak om de bureaucratie door een PMO te laten afhandelen verdwijnt dan ook. En daarmee steek je de eerste financiële winst van de transitie naar agile al meteen in je zak. (Ik zal zo links en rechts geen vrienden maken met deze opmerking, vrees ik.)

Natuurlijk blijft er wel gestuurd worden op waarde, maar dan op een veel fijner niveau. Waar in de oude wereld van het projectmanagement er een business case was per project, is er in de agile wereld een business case per backlog item (user story zo je wilt). Voor ieder item op de product backlog maakt de product owner, in overleg met de stakeholders, een inschatting van de waarde (bijvoorbeeld in business value points). En het development team maakt voor ieder item een inschatting van de kosten (bijvoorbeeld in story points). De product owner is degene die continu, op basis van de verhouding tussen business value en kosten, de beslissing neemt welke items eerst worden opgepakt en welke later.

Dus, scrum is niet maar een kunstje waarmee we onze projecten beter kunnen uitvoeren, maar een fundamenteel andere wijze waarop we onze organisatie kunnen besturen.

Story point ruler Valueminds

Story point ruler

In mijn vorige blog heb ik het refinement proces beschreven. Eén van de taken in de refinement is het inschatten van user stories. Dat schatten hoort echt bij de refinement. Sommigen doen het pas in de planning, maar wat mij betreft is dat te laat. Als stories al ingeschat zijn is het voor de product owner gemakkelijk om de juiste hoeveelheid stories voor een sprint aan te bieden in de planning.

Het schatten van stories doen we met planning poker. Daar is al veel over geschreven, dat zal ik hier niet herhalen. Voor de geïnteresseerden hier een link. Om goed te kunnen pokeren heb je een baseline nodig. Als je weet wat een ‘1’ is, dan kan je alle stories daarmee vergelijken en inschatten. Deze is twee keer zo groot, die vijf keer, etc.

Maar wat mij betreft is een baseline met alleen de ‘1’ een beetje mager. Ik maak voor mijn teams graag een story point liniaal waarin ik voor diverse getallen uit de pokerset (1, 2, 3, 5, 8, 13, …) een paar voorbeeldstories in opneem.

Als je nu gaat schatten werkt het heel gemakkelijk. Je houdt je story naast de liniaal en je vergelijkt. Is ‘ie groter dan de stories die we eerder als 3 hebben ingeschat maar kleiner dan de achten? Dan moet dit wel een vijf zijn.

Mijn ervaring is dat als teams hier twee meetings mee gewerkt hebben dat het dan gesneden koek is.

Als scrum master zorg ik er altijd voor dat ik een paar kopieën van de liniaal bij me heb als we de refinement doen. Zodra de discussie over de story een beetje afgerond lijkt stel ik de vraag “kunnen we al pokeren?”. Als dit inderdaad het geval is pakt iedereen zijn kaarten, vergelijkt nog even met de liniaal, gooit de kaarten op tafel, en het pokeren kan beginnen.

Biertje erbij en cashen maar (oh, nee, dat was de andere vorm van pokeren).

Agile Meetup Breda Valueminds

Agile Meetup Breda #2

Tijd voor de tweede Agile Meetup Breda! Deze keer zullen wij vanuit Valueminds de locatie van de Meetup verzorgen, het is in ons kantoorpand ”het Blushuis” op 10 april. We starten om 16:00 uur en eindigen om 19:00 uur (als experiment een keer een uurtje korter).

Meer over het programma volgt. Het programma zal uiteraard gebaseerd worden op de interessante agile onderwerpen die we tijdens de vorige meetup hebben uitgekozen. Voor eten en drinken wordt gezorgd. Als er dieetwensen zijn, mail dat dan even door naar Sanne Fraanje, s.fraanje@testpeople.nl (graag minimaal 1 week van te voren). Er zitten geen kosten aan de meetup verbonden. Laten jullie weten of jullie erbij kunnen zijn?

Meld je hier aan!

We hebben er zin in, tot 10 april!
Groeten, Valueminds

Samenvatting Agile Meetup Breda Valueminds

Samenvatting Agile Meetup Breda – Valueminds

Op 30 januari 2018 van 16:00 uur tot 20:00 uur was de eerste Agile Meetup Breda. We mochten zo’n 25 agile professionals verwelkom in het kantoor van AXI bv. Het doel van de avond was duidelijk: kennis maken met gelijkgestemden, van elkaar leren en ervaringen uitwisselen op het gebied van agile. De avond werd geleid door André Heijstek, de directeur van Valueminds. Bij Valueminds ademen we agile, we denken agile, we doen al heel lang niets anders. We vinden het altijd leuk om kennis te delen en om ons netwerk rondom Breda te vergroten!

We startten in kleine groepjes, waarbij we na een kennismaking uitlegden wat de twee grootste uitdagingen met agile werken zijn. Hier kwamen de meest uiteenlopende uitdagingen uit:

  • Hoe zorg ik voor teambuilding als de helft van mijn team remote werkt?
  • Hoe implementeer ik het agile werken in een niet agile omgeving?
  • Wat kan ik doen om het management te overtuigen agile te gaan werken?
  • Hoe ga je van een theoretisch plan naar een werkend stuk software?

Vervolgens werd door dot voting per groepje duidelijk welk probleem het meeste aandacht zou krijgen. Daarna gaf André een presentatie over POPCORN. POPCORN is een acroniem dat staat voor:

P – Problems/observations
O – Options
P – Possible experiments
C – Committed
O – Ongoing
R – Review
N – Next

Een presentatie van de bedenker van POPCORN vind je hier.

Mocht je nog vragen hebben naar aanleiding van de presentatie van André over POPCORN, neem dan gerust contact met hem op! Andre.heijstek@valueminds.nl

Tijdens het eten gingen we verder met stap 2 en 3 van de POPCORN methode, namelijk ‘Options’ en ‘Possible experiments’. Daarna hebben we de methodes per groep gepresenteerd voor de hele groep.

Tot slot hebben we met de hele groep geëvalueerd hoe het ging, en hoe deze meetups er in het vervolg uit moeten komen te zien. We blijven vanuit Valueminds  meetups organiseren, dit zal ongeveer 1 keer per 2 maanden zijn.

Blijf ons volgen op LinkedIn, onze website en op de Meetup pagina om op de hoogte te blijven! Vragen, opmerkingen of ideeën? Mail ons of bel ons! info@valueminds.nl / 085 273 19 54

 

Valueminds can you speak your mind

Nieuw bij Valueminds: in-house trainingen

Regelmatig geven wij cursussen agile foundations, scrum master en product owner. Hiervoor prikken wij zelf data en iedereen kan zich hiervoor aanmelden.

Maar denk je: ik wil samen met een aantal collega’s graag een in-house training volgen? Dat kan natuurlijk ook! In dat geval kan je het beste een bericht sturen naar André Heijstek. André zal de cursus geven. Hij heeft jarenlange ervaring met zowel het geven van cursussen en trainingen, als met het werken in allerlei soorten projecten. Je kan hem je aanvraag altijd mailen: andre.heijstek@valueminds.nl.

Het voordeel van een in-house training op maat, is dat deze toegespitst is op de specifieke wensen en behoeften van jullie organisatie. Ook kan dit handig zijn wanneer bepaalde informatie over je bedrijf misschien gevoelig ligt. Stuur André een verzoek met je aanvraag en wij maken een programma die precies bij je past. Wil je meer weten over de cursusdata of aanbevelingen over André lezen? Dat kan hier.

Meetup logo Valueminds

30 januari: Agile Meetup Breda

Op 30 januari 2018 is het zo ver: Valueminds’ eerste agile meetup! De meetup zal plaatsvinden in Breda en aanmelden kan hier (je mag ook een mailtje sturen naar info@valueminds.nl).

De meetup wordt georganiseerd voor en door agile denkers en doeners in regio Breda. De inhoud wordt bepaald door de groep zelf, zo zelf-organiserend zijn we wel.

Wil je meer weten over agile werken? Of wil je meer weten over Valueminds? Of allebei…? Kom dan zeker naar deze meetup! We starten om 16:00 uur en het programma duurt tot ongeveer 20:00 uur.

Meer informatie over de Agile Meetup wordt zo snel mogelijk bekend gemaakt.