Blog Archieven - Pagina 4 van 6

Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik Teamcoaching met Lencioni: Commitment... Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding. De piramide van Lencioni zet ik

Teamcoaching met Lencioni: Commitment; ook wel “betrokkenheid”

Geschreven door admin op 8 maart 2023. Gepost in Blog, Agile, Coaching, Teamontwikkeling.

Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding.

Te allen tijde wil ik voorkomen dat gegevens verborgen blijven. Ik heb liever openhartige debatten. Pas wanneer iedereen zijn standpunten en perspectieven naar voren brengt, kan een team met vertrouwen een beslissing nemen.
Tijdens mijn coaching gebruik ik de piramide van Lencioni (elk niveau komt voorbij in een aparte post): in mijn eerdere posts heb ik mijn kijk gedeeld op vertrouwen en constructieve conflicten.
Deze blog gaat over betrokkenheid, het derde niveau binnen de pyramide van teamontwikkeling. Wat heeft het ontbreken hiervan te maken met de volgende frustratie in een team? Een niet te onderschatten invloed!

In elk team heeft elk teamlid een zekere mate van oppervlakkigheid. Anders zou er ook geen mode industrie- of schoonheidsindustrie bestaan: we vereren jeugd, en willen daar zo lang mogelijk deel van uitmaken. Als ik eerlijk ben heb ik dit ook eerder als mechanisme ingezet om mij te beschermen tegen alles wat pijn zou kunnen doen of niet leuk is. Maar klopt mijn aanname wel? Oppervlakkigheid behoedt je namelijk wel voor heel wat teleurstellingen.
Als je ‘meer’ verwacht, loop je ook het risico dat dingen tegenvallen (en dat doen ze vaker wel, dan niet). Dat gaat op voor kunst, aspiraties, de liefde, noem maar op. Maar hoe oppervlakkig dit ook voelt- in de hedendaagse maatschappij toont Schoonheid je geschiktheid als partner, collega en/of geschikte medewerker en vormt zo de basis van onze evolutie. Je moet er niet aan denken hoe we eruit zouden hebben gezien als onze voorouders.

Tijdens mijn coachopdrachten loop ik (dagelijks) in de omgang tegen oppervlakkigheid aan. Wat is dat precies? Zodra men niet wil of durft om zaken met diepgang te bespreken, te schrijven of te bedenken. Het kan naar voren komen tijdens oppervlakkige gesprekken of onderzoeken. Wanneer zaken letterlijk aan de oppervlakte blijven, of men het gevoel krijgt dat we als team oppervlakkig blijven. Als er bij de samenwerking oppervlakkig wordt gesproken, geschreven of besloten.

Binnen de context van teams is betrokkenheid een functie van twee zaken; duidelijkheid en steun. Bij goed functionerende teams worden tijdige en duidelijke beslissingen genomen.
In echte teams wordt met volledige instemming gewerkt van alle teamleden, ook van de teamleden die tegen besluiten hebben gestemd. Na het einde van elke meeting/vergadering beseft iedereen dat er geen enkel teamlid twijfelt over de genomen keuzes.

De twee belangrijkste oorzaken van gebrek aan betrokkenheid zijn het verlangen naar contentie en de behoefte aan zekerheid. Ook bij goed functionerende teams weet ik dat het gevaarlijk kan zijn om te intensief die consensus op te zoeken. Volledige overeenstemming is soms onmogelijk maar samen op zoek naar kleine manieren om steun te verwerven gaat sneller in goed functionerende teams. We weten allemaal dat je als persoon niet altijd je zin hoeft te krijgen, maar dat jij je zodanig kunt opstellen dat het toch mogelijk is om je achter een beslissing te scharen. Daardoor ontstaat de bereidheid om verder te gaan, ongeacht het groepsbesluit. Bij een mogelijke impasse is het aan de teamleider om dan de knoop door te hakken. Daarvoor is wel nodig dat het standpunt wordt aangehoord en uiteindelijk wordt meegewogen bij de besluitvorming. Bij zelf organiserende teams wordt ook dit door het team zelf genomen en in de traditionele gevallen wordt de manager of teamleider gevraagd om hulp.

De tweede eigenschap binnen goed functionerende teams die betrokken zijn is de hoge mate van zekerheid. Goed functionerende teams zijn vaak trots op de gehaalde doelen met elkaar en staan graag achter beslissingen. Zij engageren zich ook volledig met plannen.
Ook in het geval van weinig zekerheid nemen we besluiten met zijn allen en dus zijn wij met z’n allen verantwoordelijk voor het resultaat. In deze teams zie ik vaak terug dat elke beslissing beter is dan geen beslissing. Als je dit vergelijkt met slecht functionerende teams is de trend dat besluiten worden uitgesteld. Meestal ligt hier achter de zekerheid van het te nemen besluit (Is het nou goed wat we van plan zijn te gaan doen?). Hoe verstandig dit misschien ook lijkt, het kan leiden tot verlamming in het team. Het is ook van belang te beseffen dat de bereidheid tot constructieve conflicten ( zie eerdere post) de basis vormt voor de bereidheid tot engageren als sprake is van onvoldoende informatie.

Als je een team hebt waar de betrokkenheid minder is, is het tijd om aan de slag te gaan. Bedenk je: hoe gaat een team te werk dat eenheid wil creëren? Hiervoor kun je een aantal instrumenten inzetten. Denk hierbij aan gebruik van een besluitenlijst, deadlines, analyse van worst case -scenario’s (zorgt voor inperking van angsten), blootstelling aan lage risico’s (opeisen dat elke teamlid een besluit helpt nemen).
Als ik teams help om te betrokkenheid te vergroten zal ik als coach de groep voortdurend aansporen tot discussie rond problemen af te ronden en zich te houden aan de planning of het overeengekomen proces.
Tegelijkertijd probeer ik minder de nadruk te leggen op zekerheid en consensus.

Uiteindelijk wil ik dat mijn team als een eenheid optreedt en zich blijft ontwikkelen en fouten durft te maken. Kansen inzien of profiteren van kansen. Blijven handelen zonder aarzeling ook in geval van veranderingen of schuldgevoelens.

Niet vanuit het ‘ik’ en ook niet vanuit het ‘zij’ maar vanuit het ‘wij’ ontstaan de mooiste dingen.

Door Stanley Markiet, consultant bij Towson

Waarom zijn korte sprints beter?

Geschreven door admin op 7 maart 2023. Gepost in Blog, Agile, Coaching, Teamontwikkeling.

De sprint: een afgebakende korte tijdsperiode waarin teams aan de hand van vaste rituelen werk plannen en uitvoeren. Het hart van Scrum werken zoals de Scrum Guide het omschrijft.
Als scrum master sluit ik me daar helemaal bij aan. De sprint is namelijk één van de krachtigste tools om bottlenecks te ontdekken. Let wel; ontdekken, niet oplossen.

Teams hebben vaak het idee dat de sprint te kort is. Wat ze dan niet door hebben is dat problemen die normaal verscholen zijn nu aan de oppervlakte komen. De sprint verlengen verbergt deze problemen, maar lost ze niet op.

De sprint verlengen is sowieso geen goed idee vanwege de volgende redenen:

Feedback komt later – Sprints verlengen betekent automatisch dat de feedback pas op een later moment komt, terwijl je juist feedback zo snel mogelijk wilt ontvangen om het mee te kunnen nemen in je volgende sprint.
Minder Agile – Kortere sprints betekent meer mogelijkheid om in te spelen op verandering. Hoe langer de sprint, hoe groter de kans dat de sprint open gebroken moet worden om nieuwe items met spoed op te pakken.
Minder verbeteringen – Als sprints langer zijn voelen teamleden al snel dat er meer tijd is om werk uit te voeren en ontstaat er minder drang om te verbeteren.
Prioriteren wordt moeilijker – Als sprints langer worden willen stakeholders al snel dat hun items in de eerst volgende sprint opgepakt worden, omdat ze anders voor hun gevoel te lang moeten wachten.

Langere sprints ≠ Minder overhead

Te vaak hoor ik als scrum master het argument voorbij komen dat langere sprints in verhouding minder “overhead” hebben dan kortere sprints. Maar dat is niet zo. De lengte van alle rituelen schalen namelijk mee volgens de scrum guide [1].

Timeboxes volgens de Scrum Guide

Zo gaat de timebox voor de sprintplanning bijvoorbeeld van 4u naar 6u als je de sprint van twee naar drie weken verlengt. Dat klopt ook want je moet immers een extra week werk inplannen. Daarbij speelt ook nog eens dat hoe verder in de toekomst, hoe lastiger het inschatten is of je iets wel of niet op kunt pakken en af kunt maken. Je weet immers beter wat je morgen gaat doen dan wat je over drie weken gaat doen. De onzekerheid neemt toe naarmate de sprint langer wordt. De sprintplanning zal dus in verhouding eerder langer dan korter worden.

Vooral voor teams die niet dagelijks bij elkaar zitten is er nog een groot nadeel bij het verlengen van de sprint. Bij een tweewekelijkse sprint passen de review, de retrospective en de planning exact op één werkdag. Je kan dus zo een echte “sprintwisseldag” creëren waarbij iedereen op locatie aanwezig is.

Verleng je de sprint naar drie of meer weken dan passen deze drie rituelen niet meer op één werkdag en zullen ze over twee of meer werkdagen verspreid moeten worden.

Het is dan ook niet zonder reden dat het Agile Manifesto korte sprints als één van de belangrijkste principes noemt: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale [2]”.

De sprint verlengen? Voer dan eerst deze checklist uit

Speelt het team tegen beter weten in met het idee om de sprint te verlengen? Vul dan eerst onderstaande checklist in om te ontdekken of er een ander probleem speelt binnen het team:

☐ Het team is bezig met het uitvoeren van “mini-watervallen” (Eerst design, dan ontwikkelen en als laatste testen). Zie ook mijn eerdere artikel.

- Het team heeft moeite met het splitsen van user stories.
- Teammeetings zijn niet efficiënt.
- Het team heeft moeite met deployments (incl. merge & integration).
- Het team heeft niet genoeg ervaring met test driven development of andere quality practices.
- Technical debt is zo groot gegroeid dat werk langer duurt.
- Team werkt aan te veel items buitenom de sprint.
- Skills en vaardigheden zijn niet goed verdeeld binnen het team waardoor het team afhankelijk is van één of enkele specialisten binnen het team.
- Team werkt en worstelt met oude technologie.
- Uitzoekpunten en antwoorden laten te lang op zich wachten.
- Het team worstelt met afhankelijkheden buiten het team.

☐ De communicatie met teamleden die niet op locatie werken verloopt moeizaam.

Problemen met prioriteren of gebrek aan een actieve Product Owner.
Moeite met het concept van een MVP’s.
De product owner of stakeholders bemoeien zich met de sprint backlog tijdens de sprint.
Het team is bang om “niet genoeg” op te leveren aan het eind van de sprint aan de stakeholders.
Het team vreest te moeten overwerken om aan de commitment te voldoen.

[1] Bron: https://agilescrumgroup.nl/duur-scrum-meetings/
[2] Bron: https://agilemanifesto.org/iso/nl/principles.html

Door William van der Maas, consultant bij Towson

Als scrummaster ben je continu teamdynamiek aan het verbeteren. Soms werk je al een hele tijd samen, soms ben je net aan een team toegevoegd, of is het team inclusief jou net gevormd- in welke situatie je je ook bevindt: het spelen van een escaperoomgame biedt inzicht.

Leer je team kennen via een escaperoomgame

Geschreven door admin op 6 maart 2023. Gepost in Blog, Teamontwikkeling.

Als scrummaster ben je continu teamdynamiek aan het verbeteren. Soms werk je al een hele tijd samen, soms ben je net aan een team toegevoegd, of is het team inclusief jou net gevormd- in welke situatie je je ook bevindt: het spelen van een escaperoomgame biedt inzicht.

Daarvoor hoef je niet naar een (dure) escaperoom: er zijn diverse escaperoom-boardgames verkrijgbaar tussen de 10 en 30 euro. De escaperooms kunnen gespeeld worden met maximaal 4 of 6 personen. Heb je een groter team dan kun je meerdere escaperooms aanschaffen en het team in groepen verdelen, hetgeen zorgt voor een extra competitie-element.

De “pocket-escaperoom” (€ 10) bestaat uit alleen kaarten, de “Exitgame escaperooms” van € 15 bevatten ook objecten die je moet vouwen, beschrijven en/of verknippen.
De uitgebreide escaperoomspellen (€ 30+) hebben daarbij ook nog een tijdklok die terugloopt.
Ga goed na bij je team of iemand al eens een escaperoomspel gespeeld heeft, voor je er een aanschaft. Je wilt niet dat iemand de oplossingen al kent.

Als scrummaster of Agilecoach doe je niet mee maar observeer je alleen het gedrag van de teamleden en maak je aantekeningen. Het mooie is dat de tijdsdruk, complexiteit en samenwerking vaak een goede afspiegeling zijn van de situaties waarin je team normaal gesproken ook terecht komt.

Als je een beetje bekend bent met Disc-profielen en Kolb-leerstijlen zul je deze ongetwijfeld herkennen in het gedrag van je teamleden. Wie neemt het voortouw, wie observeert, wie “doet”, wie betrekt de rest van het team erbij, wie neemt beslissingen, wie houdt het overzicht? Maak notities en probeer voorbeelden te onthouden.
Uit de observaties komt vaak ook goed naar voren welke rol er mist in een team. Als het team geen “beslisser” heeft zullen discussies lang doorgaan. Als er geen “doener” is blijft het team analyseren; als er alleen maar dominante personen zijn zonder bruggenbouwer, ontstaat er vaak onenigheid en komt het team ook niet verder.

Het beste is om het team van tevoren niet in te lichten waar je op zult letten, zodat men onbevangen en “als zichzelf” deelneemt aan het spel. Achteraf kun je je observaties delen en bespreken en samen met het team kijk je dan naar mogelijke verbeterpunten en te ondernemen acties.

Bij Towson gebruiken we een escaperoomspel in de teamworkshop “Samen Succesvol”.
Als je nieuw bent bij een team of met een team start, kun je het spel als kennismakingsoefening gebruiken. Als je al langer met een team samenwerkt kun je het als alternatieve retrospective gebruiken. Of als start van een teamuitje. Je moet ongeveer 90 minuten uittrekken want niet iedereen redt het in 60 minuten te ontsnappen en dan wil je toch tot het einde door gaan. Daarnaast wil je ruimte hebben om de terugkoppeling te kunnen geven.

Zelfs teamleden die niet van spelletjes spelen houden vinden dit vaak toch wel een leuke uitdaging. Het is spannend om te doen en biedt jou als (nieuwe) scrum master inzichten die kunnen helpen het team te laten groeien.
Veel plezier met de escaperooms!

Door Tamara Teunissen van Manen-Kiljan, consultant bij Towson

Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes!

Geschreven door admin op 5 maart 2023. Gepost in Blog, Agile, Coaching.

Als Agile-enthousiast sta ik helemaal achter het statement “Fail early”. En om dan maar gelijk míjn interpretatie erbij te geven: dit betekent wat mij betreft niet “We doen maar wat en zien wel waar het schip strandt”, want dat is simpelweg slechte voorbereiding. De basis is goede voorbereiding die gewoonweg nodig is om een gewenst effect te behalen. Echter: wanneer de goede voorbereiding gedaan is komt de keuze; ga ik voor een eindeloos lange voorbereiding waar ik in theorie en in detail àlles wil voorbereiden, of ga ik van start. Dit is het punt waarop je je wat mij betreft over je koudwatervrees zet en van start gaat.

Ga je tegen zaken aanlopen die je niet had voorzien? Zeker! Maar dat zou je na de eindeloos lange voorbereiding ook zijn gebeurd, omdat je niet weet wat je niet weet totdat je het in de praktijk gaat proberen. Maar: omdat je een goede voorbereiding hebt gedaan kun je die tegenslag gelukkig goed aan. Daarnaast ben je wendbaar en veerkrachtig genoeg om een assessment te doen: blijkt het idee in de praktijk een matig idee of is het een horde die ik met mijn team kan nemen.

Een ander oneliner waarop ik niet alleen voor mezelf, maar ook voor de mensen en teams waarmee ik werk heel streng in ben, is: “Liever af en toe vragen om vergeving achteraf, dan constant vragen om toestemming vooraf”. Wat mij betreft is dit een basishouding die je heel hard nodig hebt om enerzijds tot zelfsturende teams en organisaties te komen, en anderzijds om de motivatie in je organisatie te houden.
Organisaties waar je constant op toestemming aan het wachten bent zijn voor de meeste mensen niet de leukste organisaties om in te werken. De reden is simpel- het gaat rechtstreeks in tegen 1 van de 3 pijlers voor gelukkige werknemers, namelijk het hebben van autonomie. Tegelijkertijd is iedere keer toestemming vooraf eisen voor organisaties ook kostbaar want het leidt tot wachttijden waarin de kosten voor teams gewoon doorlopen en ze minder of zelfs niets realiseren. Je kunt dan dus bijna de businesscase maken “Wat is duurder? De kosten van het wachten, of de kosten van af en toe een fout?”

In mijn trainingen en coaching krijg ik vaak de opmerking dat het geven van de ruimte, om besluiten “laag” in de organisatie te nemen, een voornemen is waar vaak aan begonnen wordt, maar dat ook snel afgelopen is zodra er een fout wordt gemaakt. De manager neemt dan weer de traditionele rol van “besluitenmachine” op zich. Direct daarop volgt dan de vraag: “Hoe los jij dit dan op?”.
Het antwoord is kinderlijk eenvoudig: vier je successen!
Dat weer terugdraaien van autonoom besluiten nemen heeft een oorzaak- we zijn servicegerichte mensen. Servicegerichte mensen hebben naast een hele reeks goede eigenschappen ook een paar minder goede:

- Dat wat goed gaat is “normaal”, en dat geven ze van nature weinig tot geen aandacht. Doe maar gewoon dan doe je al gek genoeg;
- Wat fout gaat moet gefikst worden om te kunnen verbeteren en wordt volop aandacht gegeven.

Het gevolg is dat in een omgeving waar we bijzondere dingen doen, waar iedereen met eer en geweten en vol energie een bijdrage levert en waar het overgrote deel van wat we doen hartstikke goed gaat, de sfeer alsnog matig is. Dit komt doordat de focus vooral gericht is op datgene dat fout gaat.
Door in dezelfde omgeving actief stil te staan bij wat er goed gaat, collega’s te bedanken voor hun bijdrage en te vieren dat doelen behaald worden, ontstaat er een heel andere balans. Fouten worden (natuurlijk) nog steeds besproken: niet meer als het enige onderwerp, maar als een van de onderwerpen. Doordat er ook actief aandacht en waardering geschonken wordt aan de bijdrage is het vertrouwen van de mensen waarmee fouten besproken wordt groter, en kan er ook met een open vizier naar een oplossing gezocht worden. Door niet alleen de fouten, maar ook de successen te bespreken ontstaat er een sfeer waarin fouten gemaakt mógen worden. Wat mij betreft is dat een omgeving met een menselijke maat.

Jaren geleden was er al een filmpje van Prof. Sumantra Ghoshal met de titel “The smell of the place”, waarin hij in een prachtige metafoor zijn persoonlijke verhaal over empowerment mixt met zijn inzichten wat organisaties moeten doen om hun personeel de ruimte te bieden om te ontplooien, zelf besluiten te kunnen nemen en te leren. Het is een kort filmpje dat ik vaak laat zien en me nog altijd raakt. Hij beschrijft typisch de bedrijven waar ik zou willen werken omdat daar ruimte is om fouten te maken waardoor er een basis is om samen succesvol te zijn.
Daar waar hij het in een prachtige metafoor deed ben ik meer van de oneliners. Vandaar mijn stelling: Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes!

Foute keuzes na gemiste deadlines in een agile omgeving

Geschreven door admin op 4 maart 2023. Gepost in Blog, Agile, SAFe.

1. Introductie

Scrum teams hebben net als traditionele waterval teams te maken met deadlines. Om diverse redenen kan het voorkomen dat nieuwe functionaliteiten niet op tijd gereleased worden. Dat is zuur. Zeker omdat de volgende wijzigingen vaak al in de planning zijn opgenomen.

2. Combineren van releases

Een voor de hand liggende oplossing lijkt het combineren van de verschillende releases. Dan kun je bijvoorbeeld alle testen combineren en hoef je alles maar 1x te testen. Hierdoor creëer je tijdwinst en kom je de eerstvolgende release weer in de normale heartbeat (cadans).

Het tegendeel is echter waar. Het samenvoegen van releases levert geen tijdwinst op. Het kost zelfs meer tijd. Veel meer tijd.

Oorzaken zijn onder andere:

– Door meer te wijzigen wordt de scope vergroot en neemt de kans op defects toe. Blijft het aantal ontwikkelaars gelijk dan ontstaat er een defect queue (bottleneck). Testen staan hierdoor stil totdat fixes worden opgeleverd. Een grotere scope leidt tot een exponentieel grotere defect queue.
– De development- en testinfrastructuur blijft hetzelfde. Hierdoor ontstaat wachttijd (waste). Zo kunnen sommige testen bijvoorbeeld niet parallel uitgevoerd worden op dezelfde testomgeving waardoor ze op elkaar moeten wachten.
– De coördinatie en afstemming tussen teams en afdelingen neemt exponentieel toe.
– Omschakeltijd. Schakelen tussen verschillende activiteiten kost tijd. Voorbeeld: Een teamlid stuit tijdens het testen op een blokkerend defect en wil hierdoor een andere test opstarten. Hiervoor moet eerst nieuwe testdata klaargezet worden, ingelogd worden met een ander gebruikersaccount, etc.
– Scopecreep. Hoe langer een release onderhanden is, hoe meer “extra functionaliteiten” van alle kanten toegevoegd worden. Denk hierbij bijvoorbeeld aan hotfixes.

Kortom: Het vergroten van de scope zal dus door verschillende oorzaken exponentieel toenemen.

3. Release early, release often

In plaats van de scope te vergroten door releases te combineren adviseer ik met klem het tegenovergestelde. Maak de scope juist kleiner zoals het Agile Manifesto ook voorschrijft en release vaker.

De volgende technieken kunnen helpen bij het verkleinen van de scope:

– Dark Launches: Release van code naar productie waarbij de functionaliteit niet beschikbaar/zichtbaar is voor de eindgebruiker.
– Feature toggles: Een techniek waarbij je gebruik maakt van Dark Launches waarbij je de mogelijkheid inbouwt om de functionaliteit op een later tijdstip alsnog aan/uit te zetten.
– Canary release: Een techniek waarbij je de functionaliteit alleen beschikbaar maakt voor een selecte groep gebruikers. Vervolgens meet je de feedback en kun je er voor kiezen om op een later tijdstip de functionaliteit alsnog te releasen naar meer gebruikers.
– Decouple release elements: Een release kan in de regel opgeknipt worden naar kleinere elementen die apart van elkaar live gebracht kunnen worden.

Scaled Agile Silver Partner

Geschreven door admin op 3 maart 2023. Gepost in Blog, Over Towson.

Met trots kondigen we aan dat Towson vanaf nu Scaled Agile Silver partner is.

De status Silver partner is de erkenning voor het werk dat onze SAFe program coaches bij onze opdrachtgevers doen, en het aantal SAFe program coaches dat bij Towson werkzaam is.

Door de partnerstatus krijgen wij verbeterde toegang tot het netwerk dat Scaled Agile biedt en hebben wij nog meer kans om onze kennis verder uit te breiden en die in te zetten bij onze opdrachtgevers.

Nieuwe trainingslocatie is geopend!

Geschreven door admin op 2 maart 2023. Gepost in Blog, Over Towson.

In de afgelopen weken is er hard gewerkt om de nieuwe trainingslocatie in te richten. Er werd gesjouwd, getild en gesleept toen het nieuwe meubilair werd afgeleverd. Na voor de laatste keer met de bezem en stofzuiger door het pand te zijn geweest, kon op donderdagochtend 14 februari 2021 de deur open van onze mooie nieuwe trainingslocatie.

Voor 9 uur druppelden de cursisten binnen om deel te nemen aan de Leading SAFe training. De training was uitverkocht, dus het was gezellig druk met een mix van beginnende tot meer ervaren deelnemers. Voor iedereen was er ruimte om zijn of haar eigen uitdaging te bespreken en van elkaar te leren. We kunnen terugkijken op een meer dan geslaagde training met positieve feedback van de deelnemers. Na afloop was er zelfs applaus voor de trainer!

In maart staat de volgende training alweer gepland en hier hebben zich ook al een aantal deelnemers voor opgegeven zodat we weten dat deze training doorgaat. Wanneer je ook meer wil weten van SAFe en een Leading SAFe training zoekt met een uitstekende prijs/kwaliteit verhouding, dan ben je van harte uitgenodigd om je op te geven. Wij kijken er naar uit om je bij ons te ontvangen.

Scrum in het onderwijs: Onderwijs geven en ontwikkelen op basis van Agile Scrum

Geschreven door admin op 1 maart 2023. Gepost in Blog, Agile.

Introductie

De maatschappij, de arbeidsmarkt en het onderwijs veranderen in rap tempo.

Wet- en regelgeving wijzigen voortdurend, opleidingen groeien en krimpen, lesmethodes veranderen en nieuwe technologie doet zijn intrede.

Deze ontwikkelingen hebben grote impact op onderwijsinstellingen, opleidingen en de manier van lesgeven.

En dit vergt aanpassingsvermogen: onderwijsinstellingen en docenten zullen dan ook continu hun onderwijs en lesmethoden dienen te evalueren, vernieuwen en aan te scherpen, om in te kunnen spelen op de veranderende omgeving, arbeidsmarkt en behoefte van studenten.

Agile Scrum kan onderwijsinstellingen helpen bij effectief en efficiënt ontwikkelen en geven van geïntegreerd onderwijs.

Door haalbare doelen te stellen en onderwijs te ontwikkelen op basis van een heldere prioriteitstelling is het mogelijk om stapsgewijs volgens een vast slagritme onderwijs te ontwikkelen dat voldoet aan de behoefte van de docent en student.

Door een combinatie van Agile Scrum principes, intensieve samenwerking tussen management, docent en student, wordt het onderwijs continu verbeterd en voldoet het aan de meest recente praktijkstandaarden.

In dit artikel leggen we uit hoe de Agile Scrum-principes een hogeschool heeft geholpen bij het continu verbeteren en geven van hun onderwijs.

Scrum in het onderwijs

De uitdaging van de hogeschool was om tegelijkertijd onderwijs te geven en het curriculum te vernieuwen, vakken te ontwikkelen en bestaande en nieuwe online lesmethoden te integreren.

Daarnaast was er de sterke wens om docentteams en docenten nauwer met elkaar te laten samenwerken in autonome teams.

Om dit te bewerkstelligen is er eerst een nieuw curriculum ontwikkeld en zijn er docentteams gecreëerd die verantwoordelijk zijn voor een blok en clustering van meerdere vakken die onderling sterk afhankelijk zijn.

Zo worden inhoudelijke vakken en projecten geïntegreerd met vaardigheidstrainingen en taallessen.

De vaste docentteams en de onderlinge afhankelijkheid tussen vakken en projecten stimuleert en maakt onderlinge samenwerking tussen docenten noodzakelijk om kwalitatief onderwijs te ontwikkelen.

Vervolgens heeft de hogeschool gezocht naar een werkwijze die uitgaat van de student, die samenwerking stimuleert gericht op kwaliteit, en die het mogelijk maakt om tegelijkertijd onderwijs te geven en te ontwikkelen.

Uiteindelijk heeft de hogeschool gekozen om gebruik te maken van de Agile Scrum-principes.

Hogeschool way of working

Vervolgens is er gezamenlijk grondig nagedacht hoe de Agileprincipes toegepast kunnen worden in het onderwijs: het Scrum-framework werd op maat gemaakt en de rollen en het ritme bepaald.

Uiteindelijk zijn er in onderling overleg drie docentteams geselecteerd en zijn de Productowners en Scrummasters benoemd.

Verder is er per team een wensenlijst (“product backlog”) opgesteld en zijn de sprintvergaderingen ingeroosterd zodat docenten op wekelijkse basis bij elkaar zitten.

En uiteindelijk zijn we gestart met een gezamenlijke interactieve kick-off van 4 uur waarin de basisprincipes van Agile en Scrum en de “Hogeschool way of working” zijn uitgelegd.

De Productowners en Scrummasters hebben nog een korte praktijkgerichte opleiding inclusief examentraining gehad.

De docenten hebben vervolgens zelf de wensenlijst verfijnd en een digitaal scrumboard gemaakt in Trello, en zijn van start gegaan.

Gedurende een periode van 10-12 weken zijn de docentteams achtereenvolgens tijdens de vergaderingen gecoacht op het opstellen van een wensenlijst, het ontwikkelen van een Scrumbord, de verschillende rollen en verantwoordelijkheden, vergaderingen en het geven van retrospectives.

Geïntegreerd onderwijs en betere samenwerking

De manier van werken bleek verrassend goed aan te sluiten bij de organisatie, het curriculum en de onderwijspraktijk van de docenten. Met name de zorgvuldige voorbereiding en het (zelf)organiserende vermogen van de docenten hebben voor een goede start en landing gezorgd.

De inrichting tezamen met de Agile Scrum manier van werken heeft uiteindelijk geleid tot betere geïntegreerde vakken, meer overzicht in werkzaamheden en meer samenwerking.

Reclameborden langs de snelweg

Geschreven door admin op 31 januari 2023. Gepost in Blog, Over Towson.

Wij geven onze SAFe trainingen met professionaliteit en enthousiasme. Om te zorgen dat jullie net zo enthousiast worden om onze trainingen te volgen, nemen we actie om ze goed bekend te maken bij een breder publiek. Naast adverteren op social media hebben we nu de stap genomen om onze trainingen te adverteren op reclamezuilen langs de snelweg. In eerste instantie op de A15 en de A2, maar andere locaties sluiten we voor de nabije toekomst niet uit.

Binnen Towson hebben we al een behoorlijke tijd de Leading SAFe training geprogrammeerd op ons trainingenrooster. Naast de goede reviews die we hierop ontvangen, halen we een hoog slagingspercentage met de certificeringen. Met veel vuur zijn we daarom nu begonnen met de SAFe DevOps trainingen en certificeringen. Wij verwachten hier dezelfde positieve resultaten te behalen!

Werk je in een Agile organisatie en wil je je expertise uitbreiden en laten ondersteunen door een certificaat dat in de hele sector erkend wordt? Kijk dan op Towson.nl en schrijf je in op één van onze trainingen!

NEN 4400-1 audit

Geschreven door admin op 30 januari 2023. Gepost in Blog, Over Towson.

NEN 4400-1 audit
Vorige week heeft bij Towson de VRO Audit plaatsgevonden. Deze audit is verplicht vanwege de SNA (Stichting Normering Arbeid) certificering.

VRO controleert middels een uitgebreide inspectie op bijvoorbeeld de correcte uitbetaling van lonen, de afdracht van belastingen, de opbouw van dossiers, het in bezit hebben van de juiste personeelsgegevens etc.

Dankzij de gedegen voorbereiding van onze officemanager en accountant is Towson wederom “geslaagd” en wordt de NEN 4400-1 certificering gecontinueerd. Vanuit de VRO werden complimenten gegeven over de administratieve processen binnen Towson en de efficiency daarvan.

Ook dit keer kregen we te horen dat de administratie prima in orde is!