Skip to main content
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 . 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! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early” Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early” Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early” Wil je ruimte in jouw team om fouten te mogen maken? Vier je succes! Als Agile-enthousiast sta ik helemaal achter het statement “Fail early”

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

Geschreven door admin op . 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. Scrum teams hebben net als traditionele waterval teams te maken met deadlines. Foute keuzes na gemiste deadlines in een agile omgeving. Scrum teams hebben net als traditionele waterval teams te maken met deadlines. Foute keuzes na gemiste deadlines in een agile omgeving. Scrum teams hebben net als traditionele waterval teams te maken met deadlines.

Foute keuzes na gemiste deadlines in een agile omgeving

Geschreven door admin op . Gepost in Blog, Agile, SAFe.

Foute keuzes na gemiste deadlines in een agile omgeving. Scrum teams hebben net als traditionele waterval teams te maken met deadlines.

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.

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.

Scaled Agile Silver Partner

Geschreven door admin op . 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! Wanneer je ook meer wil weten van SAFe en een Leading SAFe training zoekt op een mooie nieuwe locatie meld je dan aan.

Nieuwe trainingslocatie is geopend!

Geschreven door admin op . 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 - Agile Scrum kan onderwijsinstellingen helpen bij effectief en efficiënt ontwikkelen en geven van geïntegreerd onderwijs. Scrum in het onderwijs: Onderwijs geven en ontwikkelen op basis van Agile Scrum - Agile Scrum kan onderwijsinstellingen helpen bij effectief en efficiënt ontwikkelen en geven van geïntegreerd onderwijs.

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

Geschreven door admin op . 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: Wij geven onze SAFe trainingen met professionaliteit en enthousiasme. Hoog slagingspercentage & certificering

Reclameborden langs de snelweg

Geschreven door admin op . 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. Dankzij onze officemanager en accountant is Towson wederom “geslaagd” en wordt de NEN 4400-1 certificering gecontinueerd.

NEN 4400-1 audit

Geschreven door admin op . Gepost in Blog, Over Towson.

NEN 4400-1 audit. Dankzij onze officemanager en accountant is Towson wederom “geslaagd” en wordt de NEN 4400-1 certificering gecontinueerd.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!

Eduscrum: Agile onderwijs instellingen. Combinatie van Agile en Scrum principes, intensieve samenwerking tussen docent, praktijk & student... Eduscrum: Agile onderwijs instellingen. Combinatie van Agile en Scrum principes, intensieve samenwerking tussen docent, praktijk & student... Eduscrum: Agile onderwijs instellingen. Combinatie van Agile en Scrum principes, intensieve samenwerking tussen docent, praktijk & student...

Eduscrum: Agile onderwijs instellingen

Geschreven door admin op . Gepost in Blog, Agile, Teamontwikkeling.

1. Introductie

De maatschappij, de arbeidsmarkt en het onderwijs veranderen in rap tempo, opleidingen groeien en krimpen, lesmethodes veranderen en onderwijs veroudert steeds sneller. Onderwijsinstellingen en opleidingsinstituten zullen dan ook continu hun onderwijs en lesmethoden dienen te evalueren, vernieuwen en aan te scherpen.

Het gericht, efficiënt en effectief ontwikkelen van onderwijs is echter arbeidsintensief en wordt vaak naast de reguliere contacturen ontwikkeld, waardoor het voor docenten lastig is om prioriteiten te stellen. Agile scrum kan onderwijsinstellingen helpen bij het effectief en efficiënt ontwikkelen van onderwijs.

2. Aanpak en implementatie

Allereerst worden gezamenlijk alle vakken geïnventariseerd die ontwikkeld en verbeterd dienen te worden. Per vak wordt op basis van urgentie, ouderdom, werkdruk, beoordeling van studenten een Product Backlog opgesteld. Tegelijkertijd wordt een Scrum Team van docenten ingericht. Twee docenten worden benoemd tot Product Owner en Scrum Master. Idealiter vervult de persoon die eindverantwoordelijk is voor het curriculum de rol van Product Owner.

De rol van Scrum Master kan het beste worden vervuld door een docent met organisatietalent, draagvlak en oplossingsvermogen. Daarnaast is het handig om mensen uit de praktijk en studenten aan te haken. Op deze manier borg je dat het vak in lijn is met de praktijk en voldoet aan de behoefte van studenten.

Vervolgens wordt gestart met een Sprint Planning waar het eerste vak wordt opgepakt en bepaald wordt welke taken er allemaal opgepakt moeten worden om succesvol het vak te ontwikkelen. Elementen die vaak in de Sprint Planning besproken worden zijn: visie, leerdoelen, competenties, toetsnormen, lesbeschrijving en onderwijsmaterialen.

Voordat het vak definitief is afgerond is het handig om het vak te toetsen en testen. Dit kan door onderdelen van het lesmateriaal en werkvormen in een kleine groep van docenten, studenten en praktijkmensen te toetsen. Op deze manier ontvang je feed-back op basis waarvan je het vak en lesmethode nog voor gebruik kan aanscherpen.

3. Het resultaat

Door een combinatie van Agile en Scrum principes, intensieve samenwerking tussen docent, praktijk en student is het mogelijk om continu effectief en efficiënt onderwijs te ontwikkelen dat voldoet aan de wensen van docenten en studenten en geldende kwaliteitseisen.

Ben je na het lezen van dit artikel geïnteresseerd geraakt? Of vind je het leuk om ervaringen uit te wisselen? Neem dan contact op via info@towson.nl

Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen. Scrum in business: Op weg naar zelfsturende teams - Uitleg over Agile en Scrum principes toepassen en zelfsturende (Scrum) teams ontwikkelen.

Scrum in business: Op weg naar zelfsturende teams

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

1. Introductie

De maatschappij, klantbehoeftes en -verwachtingen veranderen voortdurend. Daarnaast wordt de kwantiteit, snelheid en complexiteit van veranderingen steeds groter en zullen organisaties en medewerkers de komende jaren geconfronteerd worden met een continu veranderende omgeving.

Dit vraagt naast aanpassingsvermogen, om sterk leiderschap en teams die naast de uitvoering van de operationele werkzaamheden (running the business) in staat zijn om producten, diensten en werkzaamheden continu te verbeteren (changing the business).

In de praktijk blijkt dit een behoorlijke uitdaging en passen energiebedrijven, banken, verzekeringen, zorg- en onderwijsinstellingen steeds vaker de agile en scrum principes toe binnen hun dagelijkse operatie om veranderingen door te voeren.

De agile principes helpen organisaties relatief snel hun effectiviteit te vergroten door werkzaamheden te prioriteren en transparant te maken, in een vast ritme te werken, tijdig te evalueren, te investeren in medewerkers en tegelijkertijd de medewerkerstevredenheid te vergroten.

Bekende praktijkvoorbeelden zijn onder andere salesteams, HR-, communicatie- en marketing-afdelingen die met succes volgens de agile en scrum principes werken. Daarnaast wordt Scrum ook steeds meer ingezet bij het ontwikkelen van onderwijs, beleid en wet- en regelgeving of gericht bij het opstellen van bijvoorbeeld een jaarrekening.

In dit artikel wordt in het kort uitgelegd hoe je geleidelijk de agile en Scrum principes kan toepassen binnen de operatie en zelfsturende (Scrum) teams kunt ontwikkelen die in staat zijn om veranderingen door te voeren, te innoveren en producten te ontwikkelen.

2. Scrum in business

Het agile gedachtegoed en de scrum principes worden steeds vaker door organisaties in de operatie gebruikt om de effectiviteit en het aanpassingsvermogen van de organisatie, afdeling en teams te vergroten.

In de praktijk is het een uitdaging om de transitie te maken van regulier opererende teams naar teams die werken op basis van scrum principes. Onderstaand wordt beschreven hoe je stapsgewijs de transitie kunt maken naar zelfsturende (Scrum) teams.

2.1 Organiseer commitment en volg gezamenlijk de training

Voordat je start met de eerste stappen is het allereerst belangrijk om de juiste commitment en draagvlak bij het management, de medewerkers en de omgeving te creëren. Dit bepaalt in grote mate het succes.

Verder is het verstandig om klein te beginnen met medewerkers die enthousiast zijn en kunnen zorgen voor een goede start.

Vervolgens is het zaak om ervoor te zorgen dat iedereen de spelregels kent en dezelfde taal spreekt door een gedegen training te volgen waar de agile en Scrum principes worden uitgelegd en de koppeling met de praktijk wordt gemaakt.

In het kader van commitment is het tevens handig om het management kader ook deel te laten nemen aan de training of de training te laten volgen, zodat het voor het management inzichtelijk wordt hoe Scrum werkt en wat de voordelen ervan zijn voor de organisatie.

2.2 Benoem de Product Owner en Scrum Master

Na de training kunnen de Product Owner en Scrum Master benoemd worden die respectievelijk verantwoordelijk zijn voor het prioriteren van de Product Backlog en het oplossen van issues.

Een Product Owner dient inhoudelijk sterk, besluitvaardig en goed met stakeholders om te kunnen gaan. Een goede Scrum Master daarentegen dient goed te zijn in issue-management en in staat te zijn om het team op sleeptouw kunnen nemen en te coachen.

Belangrijk in de zoektocht naar een geschikte Product Owner en Scrum Master is om op zoek te gaan naar een match tussen de rol en de kennis en vaardigheden van een medewerker in plaats van een match tussen rol en bestaande functieprofielen. Uiteindelijk is de match tussen rol en medewerker succesvoller dan de match tussen rol en functieprofiel.

In het begin wordt de rol van Product Owner en Scrum Master vaak door een leidinggevende vervult of benoemd. Het komt ook voor dat de keuze wordt overgelaten aan het team. Hierbij is het van belang om te benadrukken dat de rol van Scrum Master en Product Owner geen hiërarchische rollen zijn en het team gezamenlijk verantwoordelijk is. Daarnaast is het goed om te beseffen dat rollen in de praktijk na verloop van tijd vaak rouleren en de rol van Scrum Master verandert in agile coach of team lead.

2.3 Stel gezamenlijk de Product Backlog op

Nu de Product Owner bekend is kan gestart worden met het opstellen van de Product Backlog en het inventariseren en prioriteren van de werkzaamheden. Vaak is het handig om voorafgaand aan het opstellen van de Product Backlog een stakeholdermap op te stellen om inzicht te krijgen in het speelveld en type stakeholders die betrokken dienen te worden bij het opstellen van de Product Backlog.

Vervolgens kan op basis van de behoeften van interne en externe stakeholders bepaald worden welke concrete producten en diensten opgeleverd dienen te worden.

De Backlog van een operationeel team of stafafdeling is vaak operationeler van aard dan de Backlog van een ICT afdeling en bevat veelal naast ICT-wijzigingen ook operationele wijzigingen zoals het opstellen van customer journeys, procesplaten en werkinstructies. Hoewel het de voorkeur geniet om op de Backlog alle items op te nemen, wordt in de praktijk vaak nog een onderscheid gemaakt tussen producten en wijzigingen gericht op het veranderen van de business (changing the business) en het uitvoeren van de dagdagelijkse werkzaamheden (running the business). Voorbeelden zijn operationele issues en het opleveren van maandelijkse rapportages.

Uiteindelijk dient de Product Backlog door de Product Owner geprioriteerd te worden. Hiervoor worden afhankelijk van het type organisatie, afdeling en team vaak verschillende criteria gebruikt waaronder business value, klanttevredenheid, impact en werkdruk. Tot slot is het handig om gezamenlijk met het team per Backlog item de relatieve omvang in te schatten alvorens gestart kan worden met de eerste sprint, zodat een goed beeld gevormd kan worden van de omvang van werkzaamheden.

2.4 Stel het Scrum Team samen

Nadat de backlog is opgesteld en geprioriteerd kan gestart worden met de verdere samenstelling van het Scrum Team. Idealiter bestaat het team uit “T-shaped” medewerkers of “generalized specialists”. Dit zijn medewerkers die naast een of meerdere specialismes tevens beschikken over andere vaardigheden en allround inzetbaar zijn. In de praktijk is het lastig om dit type medewerkers te vinden omdat medewerkers niet allemaal all-round zijn opgeleid en functieprofielen binnen organisaties vaak vragen om specialistische kennis, vaardigheden en ervaring.

Desalniettemin is het van belang om op zoek te gaan naar een match tussen de werkzaamheden op de Backlog, het team en de individuele medewerkers in het team. Het team is immers collectief verantwoordelijk en dient zelfstandig in staat te zijn om alle werkzaamheden die op de Product Backlog staan in nauwe samenwerking met de omgeving te realiseren.

Verder is het handig om alvast na te denken over de opleiding en training die het team en de individuele medewerkers binnen het team nodig hebben om zichzelf en de samenwerking binnen het team continue te verbeteren.

2.5 Bepaal het slagritme van de sprint

Tot slot is het van belang om op voorhand het slagritme te bepalen en de Scrum vergaderingen in te plannen. Het slagritme varieert vaak per organisatie, afdeling en team. Veel organisaties kiezen voor een vast ritme van 2-4 weken en houden in het begin strikt vast aan de scrum vergaderingen om de de agile scrum principes goed onder de knie te krijgen.

Naarmate het team volwassener wordt, worden vaak het slagritme, de frequentie en de duur van de vergaderingen aan de behoefte van de organisatie en teams aangepast. De Sprint Review wordt bijvoorbeeld ingekort en de Daily Scrum vindt om de dag plaats. In de praktijk houden teams vaak wel vast aan de Sprint Planning en de Sprint Retrospective. Beide vergaderingen geven het team richting en helpen het team om continue te kunnen verbeteren.

3. Scrum works

Het agile gedachtegoed heeft zich inmiddels bewezen en wordt steeds meer door organisaties en bedrijven toegepast binnen de operatie om effectieve zelfsturende teams te creëren en efficiënt veranderingen door te voeren.

Medewerkers zijn op basis van de agile en scrum principes niet langer individueel verantwoordelijk voor het uitvoeren van werkzaamheden, onderlinge verhoudingen worden minder hiërarchisch en er wordt verwacht dat medewerkers hun expertise inbrengen en over de grenzen van hun eigen expertise heen kijken.

Scrum vraagt dus een nieuwe mind-set waar organisaties en medewerkers geleidelijk aan moeten wennen. De meest effectieve manier om hiermee om te gaan is om gezamenlijk het avontuur aan te gaan en te starten.

De komende weken zullen een aantal korte praktijkvoorbeelden gepost worden. Dus stay tuned…

Ben je na het lezen van dit artikel geïnteresseerd geraakt? Of vind je het leuk om ervaringen uit te wisselen? Neem dan contact op via info@towson.nl.