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.
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.
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!
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.
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.
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
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.
De maatschappij, klantbehoeftes en -verwachtingen veranderen voortdurend. Kwaliteit- en veiligheidseisen worden strenger, wet- en regelgeving worden geharmoniseerd, en technologische ontwikkelingen volgen elkaar in rap tempo op. Tegelijkertijd worden de kwantiteit, snelheid en complexiteit van veranderingen steeds groter.
Overheden, onderwijsinstellingen, bedrijven en medewerkers zullen de komende jaren geconfronteerd worden met kleinschalige en grootschalige veranderingen en een omgeving waarin maatschappelijke, economische en technologische veranderingen leiden tot de intrede van nieuwe marktpartijen, nieuwe markt-productcombinaties, innovatieve diensten en verschuiving van bestaande machtsstructuren.
Dit vergt aanpassingsvermogen en vraagt om een sterke klant- en productfocus, flexibiliteit en lenigheid. Om te kunnen overleven dienen organisaties in staat te zijn om effectief en tijdig te reageren op veranderingen, kansen en bedreigingen binnen bestaande en toekomstige markten. In de praktijk blijkt dit vaak een uitdaging en is het voor organisaties lastig om blijvende veranderingen door te voeren. Traditionele programma- en projectmanagement technieken zoals MSP en PRINCE2 blijken niet altijd het gewenste resultaat op te leveren en voldoende uitkomst te bieden.
Agile change en delivery modellen
In reactie hierop zijn vanaf de jaren ‘90 verschillende agile change modellen ontwikkeld waaronder Rational Unified Proces (RUP), Scrum, Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). Dergelijke modellen en methodieken stellen organisaties in staat om tijdig, effectief en efficiënt veranderingen door te voeren door hun lenigheid te vergroten.
Veel organisaties zijn inmiddels overtuigd van het agile gedachtegoed en gestart met het werken volgens de agile en Scrum principes. Bekende voorbeelden zijn Spotify, Coolblue, ING, Eneco en bol.com waar meerdere scrumteams gezamenlijk werken aan de succesvolle introductie van nieuwe producten en diensten om steeds meer toegevoegde waarde te leveren aan hun klanten, stakeholders en eindgebruikers.
Voor veel organisaties is het een uitdaging om de agile principes toe te passen en geleidelijk de transitie te maken naar een volwassen agile organisatie. Daarnaast is het meestal een uitdaging om continu de volwassenheid en effectiviteit van de agile organisatie te verbeteren en met meerdere agile teams tegelijkertijd producten en diensten te ontwikkelen.
In dit artikel wordt een overzicht gegeven van de verschillende agile modellen en frameworks die organisaties kunnen gebruiken om op te schalen, met meerdere agile teams tegelijkertijd te werken en door te ontwikkelen naar een volwassen agile organisatie die in staat is om tijdig veranderingen te signaleren, door te voeren en zichzelf continu te verbeteren.
2. Het Agile Manifesto
In de jaren ‘90 werden organisaties en bedrijven steeds ICT-intensiever en steeds vaker geconfronteerd met technologische veranderingen, veeleisende klanten en een steeds korter wordende time-to-market van producten. Al snel bleek dat traditionele projectmanagement technieken onvoldoende flexibel waren om efficiënt en effectief proces- en systeemwijzigingen door te voeren.
In reactie hierop deden verschillende light-weigth development technieken hun intrede, waaronder Dynamic System Programming Method (DSDM), Extreme Programming (XP), Rapid Application Development (RAD), Feature-driven Development (FDD) en Rational Unified Proces (RUP). De methodieken waren gericht op het incrementeel en iteratief ontwikkelen van software op basis van de behoefte van de klant en hadden een sterke focus op continu verbeteren en kwaliteit.
In 2001 kwamen 17 software-pioniers bij elkaar om de verschillende light-weight software technieken te bespreken en te vergelijken. De uitkomst van de meet-up was het Agile Manifesto waarin de 12 uitgangspunten van agile werken zijn vastgelegd die organisaties kunnen gebruiken om hun lenigheid, flexibiliteit en aanpassingsvermogen te trainen en te vergroten.
Customer satisfaction by early and continuous delivery of valuable software
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business, people, and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Best architectures, requirements, and designs emerge from self-organizing teams
Regularly, the team reflects on how to become more effective, and adjusts accordingly
Samenvattend verkiest het Agile Manifesto individuen en interactie boven proces en tooling, werkende software boven documentatie, samenwerking met de klant boven contractonderhandelingen en het reageren op verandering in plaats van het volgen van een plan.
3. Single Team Scrum
Het Agile Manifesto heeft de deur geopend voor nieuwe delivery methoden om in een complexe omgeving veranderingen door te voeren, waaronder Scrum de meest toegepaste en gebruikte methode is. Bedrijven zoals Spotify, Coolblue, ING, Eneco en bol.com maken dankbaar gebruik van Scrum om hun producten en dienstverlening continu te verbeteren.
Scrum is in de jaren ‘90 bedacht door Ken Schwaber en Jeff Sutherland met als doel om op een efficiënte en effectieve manier software te ontwikkelen. De term Scrum is afkomstig uit de rugbywereld en is een proces framework dat gebruikt wordt om complexe producten en software te ontwikkelen in een continu veranderende omgeving.
Het framework is gebaseerd op teamwork. Het Scrum Team bestaat uit een Product Owner, Scrum Master en Development Team en is gezamenlijk verantwoordelijk voor het realiseren van werkende producten en software die voldoen aan de wensen van de klant. Om de kwaliteit van de producten en software te borgen stelt het team een Definition of Done (DoD) op. In de DoD beschrijft het team de eisen waaraan producten en software moeten voldoen voordat ze in gebruik kunnen worden genomen. Hierbij kan gedacht worden aan de uitvoering van testwerkzaamheden, het documenteren van functionaliteiten en het voldoen aan interne security richtlijnen van de organisatie.
Het Scrum Team is zelf-organiserend, werkt iteratief, incrementeel en levert volgens een vast ritme, de sprint, een werkend product en werkende software op. De sprint is fixed en mag niet meer dan maximaal 4 weken duren. Transparantie, observeren en aanpassen vormen tijdens de sprint de kernwaarden van het team.
Binnen het Scrum Team is de Product Owner verantwoordelijk voor het inventariseren en prioriteren van de te realiseren producten en wijzigingen. De producten en wijzigingen worden centraal vastgelegd op een prioriteitenlijst de Product Backlog genaamd. In overleg met de omgeving en betrokken stakeholders bepaalt de Product Owner in welke volgorde de producten en wijzigingen door het team worden opgepakt. De Scrum Master ondersteunt de Product Owner in zijn rol en is verantwoordelijk voor het wegnemen van issues en het ondersteunen en coachen van het team.
Aan het begin van elke sprint vindt er een Sprint Planning plaats. In dit overleg worden de richting en focus van de sprint bepaald en stelt het team een sprintdoel op. Daarnaast wordt de lijst met geprioriteerde producten en wijzigingen besproken en bepaald wat het team gaat oppakken in de sprint. Vervolgens wordt besproken hoe de wijzigingen worden opgepakt.
De uitkomst van dit overleg is de Sprint Backlog: een korte lijst met geprioriteerde wijzigingen en taken op basis waarvan het team start met de realisatie van de producten en wijzigingen. De Sprint Backlog is eigendom van het Development Team en kan tijdens de sprint niet gewijzigd worden door de Product Owner.
Gedurende de sprint wordt dagelijks de voortgang besproken in een Daily Scrum aan de hand van drie vragen:
Wat heb je gister gedaan?
Wat ga je vandaag doen?
Welke issues heb je?
Aan het eind van elke sprint worden tijdens de Sprint Review de producten en wijzigingen getoond aan de klant, stakeholders en eindgebruikers, en wordt de sprint afgesloten met een Sprint Retrospective. In dit overleg wordt de sprint door het team geëvalueerd en worden verbeterpunten benoemd die worden meegenomen in de volgende sprint. Op deze wijze kan het team zich continu verbeteren.
4. Multiple Team Scrum
Het agile gedachtengoed wordt inmiddels door veel organisaties omarmd en Scrum wordt in veel organisaties succesvol toegepast. Het op korte termijn starten met agile en Scrum blijkt in de praktijk voor organisaties relatief snel veel voordelen op te leveren ten opzichte van traditionele projectmanagement- en delivery technieken, waaronder het gericht en regelmatig opleveren van werkende software.
Het succes van Scrum heeft geleid tot een toename van het aantal Scrum Teams binnen tal van organisaties en de behoefte om tegelijkertijd met meerdere Scrum Teams producten en software te ontwikkelen. In de praktijk is echter gebleken dat het niet zonder meer mogelijk is om op te schalen en de uitgangspunten van het Agile Manifesto tezamen met de spelregels van Scrum niet altijd voldoende uitkomst bieden.
In reactie hierop zijn de afgelopen jaren in korte tijd een aantal agile frameworks ontwikkeld waaronder Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). De frameworks zijn bedoeld om organisaties handvatten te bieden voor het opschalen en doorontwikkelen naar een volwassen agile organisatie die in staat is om met meerdere teams tegelijkertijd agile te kunnen werken en producten te ontwikkelen.
De modellen zijn complex, omvangrijk en de uitdaging voor organisaties is om het juiste model of gedeeltes van de modellen geleidelijk te implementeren.
4.1 Nexus
Het Nexus Framework is afkomstig van www.scrum.org
Het Nexus framework is het nieuwe wapenfeit van Ken Schwaber en een reactie op de verschillende agile frameworks die de afgelopen jaren zijn ontwikkeld. Het raamwerk, exoskeleton, van Nexus is bedoeld om met 3-9 Scrum Teams op basis van één Product Backlog te werken aan een geïntegreerd product.
De agile en Scrum principes vormen de basis van het framework waarbij de focus ligt op het verbeteren van de onderlinge samenwerking tussen de teams en de integratie van de te realiseren producten en oplossingen. Om dit te bewerkstelligen wordt naast de scrum teams een apart Scrum Team ingericht: het Nexus Integration Team.
Het Nexus Integration Team bestaat dus uit een Product Owner, Scrum Master en leden afkomstig uit de overige Scrum Teams. De Product Owner is verantwoordelijk voor het vaststellen en prioriteren van de Backlog en de Scrum Master helpt de Scrum Teams de Nexus principes correct toe te passen. De teamleden van het Nexus team kunnen tevens onderdeel uitmaken van en participeren in andere Scrum Teams. Het team werkt volgens een vast ritme en is verantwoordelijk voor het afstemmen en mitigeren van de onderlinge afhankelijkheden tussen de teams en het integreren van de eindoplossing.
De sprintvergaderingen van het Nexus team zijn leidend en worden zoveel mogelijk geïntegreerd in de vergaderingen van de afzonderlijke Scrum Teams. Vertegenwoordigers vanuit de overige Scrum Teams worden uitgenodigd om deel te nemen aan het Nexus teamoverleg.
Het samenspel van het Nexus team en de overige Scrum Teams start met een Nexus Sprint Planning waarin het doel van de sprint wordt vastgesteld en wordt bepaald welke producten, oplossingen en wijzigingen worden opgepakt. De Backlog items vormen input voor de Sprint Planning van de individuele teams. Daarnaast vindt er een dagelijks overleg, de Nexus Daily Scrum, plaats waarin de onderlinge afhankelijkheden en integratie issues worden geïdentificeerd die worden besproken in de Daily Scrums van de overige teams.
Aan het eind van elke sprint wordt een Nexus Sprint Review georganiseerd waarin het geïntegreerde product getoond wordt aan de omgeving en volgt een Nexus en Sprint Retrospective. In de Retrospective wordt de sprint geëvalueerd en worden verbeteracties vastgesteld.
4.2 Large Scale Scrum (LeSS)
Het LeSS Framework is afkomstig van www.less.works.
Het LeSS framework is bedacht door Craig Larman en Bas Vodde en is bedoeld voor organisaties die met meerdere teams tegelijk willen scrummen. Inmiddels hebben onder andere BMW, Thales, Port of Rotterdam en Ericsson het framework geadopteerd.
Het framework heeft een sterke klant- en productfocus, omarmt lean- en systems thinking en doet nadrukkelijk afstand van tayloristische opvattingen, organogrammen en het denken in lokale optimalisatie. Onderstaand een overzicht van de belangrijkste principes.
Large-scale scrum is scrum – Multiple team Scrum versus multiple Scrum Teams
Customer Centric – Focus op klant en klantbehoefte vormt basis voor productontwikkeling
Whole product focus – Focus op product en toegevoegde waarde voor de klant
Lean Thinking – Creëer flow, vermijd rijen en verwijder de 7 verspillingen
System Thinking – Denk in systemen in plaats van oorzaak gevolg
Empirical process control – Inspecteer, observeer en pas aan op basis van bevindingen
Queuing theory – Reduceer en beperk rijen, work in progress, multi-tasking en variatie
Transparency – Creëer transparantie en geef inzicht in de voortgang en complexiteit van werkzaamheden
More with LeSS – Bouw een agile organisatie bottom-up en niet top-down met behulp van management
Continuous Improvement – Verbeter continu het proces van product delivery
LeSS is gebaseerd op multiple team scrum en gaat in tegenstelling tot het Scaled Agile Framework (SAFe) uit van één groot Scrum Team, bestaande uit meerdere teams die gezamenlijk producten realiseren op basis van één centrale Product Backlog. SAFe daarentegen gaat uit van een agile team dat bestaat uit meerdere afzonderlijke Scrum Teams met elk een eigen Product Owner en Product Backlog. Binnen het framework wordt een onderscheid gemaakt tussen LeSS (< 9 teams) en LeSS Huge (> 9 teams).
Het LeSS Scrum Team bestaat uit zelforganiserende cross-functional feature teams. Feature teams zijn multidisciplinaire teams die in staat zijn om ketenwijzigingen en component overstijgende producten te ontwikkelen. Het team beschikt over één productowner en meerdere Scrum Masters, waarbij de Scrum Masters verantwoordelijk zijn voor de LeSS adoption van de organisatie en de ondersteuning van de teams. In de praktijk vervult een Scrum Master vaak voor drie Scrum Teams tegelijk de rol van Scrum Master.
In het geval van LeSS Huge worden de teams vaak gekoppeld aan een area. Een area is een cluster van functionaliteiten of een gedeelte van een product dat seperaat waarde toevoegt voor de klant. De indeling in areas wordt gebruikt om focus aan te brengen in de productontwikkeling. Een area staat niet gelijk aan een SAFe valuestream, maar bewerkstelligt hetzelfde doel. Ter ondersteuning van de Product Owner wordt er vaak per area een Area Product Owner aangesteld die samen met de Product Owner een team vormt en de Product Owner ondersteunt bij het opstellen en prioriteren van de Backlog.
Overeenkomstig ‘single’ team Scrum start de realisatie met een overall Sprint Planning waarbij alle Scrum Teams aanwezig zijn en bepaald wordt wat er in de sprint wordt opgepakt. Vervolgens wordt in de teams afzonderlijk bepaald hoe de userstories worden opgepakt en gestart met de sprint.
Aan het einde van de sprint vindt er een gezamenlijke overall Sprint Review plaats, waarin de gerealiseerde producten en software worden getoond aan de betrokken stakeholders. Tot slot wordt er een overall Sprint Retrospective en Sprint Retrospective op teamniveau georganiseerd, waarin de sprint gezamenlijk en afzonderlijk door de teams wordt geëvalueerd.
4.3 Scaled Agile Framework (SAFe)
Het SAFe 4.0 framework is afkomstig van www.scaledagileframework.com
Het Scaled Agile Framework (SAFe) is een bekend agile framework dat is bedacht door Dean Leffingwel. SAFe is een framework dat organisaties helpt om met meerdere Scrum Teams tegelijkertijd veranderingen door te voeren. Inmiddels hebben grote bedrijven zoals onder andere TomTom, Lego en Intell het SAFe framework geadopteerd en toegepast.
Het framework is gebaseerd op lean principes en probeert alignment te creëren tussen de strategie van een organisatie en de daadwerkelijke realisatie van producten en diensten door agile Scrum Teams. SAFe maakt in tegenstelling tot LeSS hierbij gebruik van bestaande governance- en programmastructuren zoals het strategische portfolio overleg dat veel gebruikt wordt binnen organisaties om de prioriteit van veranderingen te bepalen.
Take an economic view – Change op basis van economische afwegingen (cost of delay)
Apply systems thinking – Optimaliseer ketens in plaats van (stand alone) componenten
Assume variability, preserve options – Ga uit van variëteit, wees flexibel en beschik over alternatieven
Build incrementally with fast, integrated learning cycles – Gebruik iteraties, test en evalueer periodiek (PDCA)
Base milestones on objective evaluation of working systems – Stel realistische doelen en vermijd tolgates
Visualize and limit WIP, reduce batch sizes, and manage queue lengths – Creëer flow en monitor work in progress
Apply cadence, synchronize with cross-domain planning – Hanteer een vast ritme, synchroniseer en plan delivery
Unlock the intrinsic motivation of knowledge workers – Motiveer en activeer intrinsieke motivatie
Decentralize decision making – Decentraliseer zoveel mogelijk de besluitvorming
SAFe onderkent respectievelijk vier niveaus: het portfolio-, value stream-, programma- en teamniveau. Op portfolio niveau worden door de directie de strategische thema’s gedefinieerd die richting geven aan de gewenste verandering. Daarnaast worden op dit niveau de belangrijkste value streams (waardeketens) geïdentificeerd waarbinnen de veranderingen plaats dienen te vinden.
De strategische thema’s worden gekoppeld aan de value streams en per waardeketen wordt een veranderbudget toegekend. Vervolgens worden de strategische thema’s per value stream op programma niveau vertaald in hapklare brokken en wijzigingen, de epics, die vastgelegd worden op een programma backlog.
Tegelijkertijd wordt er per value stream een Release Train ingericht. Een Release Train is een agile team bestaande uit meerdere Scrum Teams die gezamenlijk verantwoordelijk zijn voor het ontwikkelen van werkende producten en software binnen een waardeketen. Elk team binnen de Release Train beschikt over een afzonderlijke Product Backlog, Product Owner en Scrum Master en werkt overeenkomstig de principes van agile Scrum.
De programma backlog wordt vervolgens verder opgeknipt en vertaald in een Product Backlog op basis waarvan de Scrum Teams binnen een Release Train kunnen starten met de realisatie. Om de onderlinge samenwerking en alignment tussen te teams te vergroten wordt er gemiddeld één keer in de 10 weken een Release Planning georganiseerd. Het overleg duurt vaak twee dagen. Bij dit overleg zijn het management en alle teams aanwezig, en worden gezamenlijk de doelstellingen en de inhoud van de eerst komende sprints bepaald. Daarnaast worden in de vergadering de belangrijkste afhankelijkheden en risico’s tussen de teams afgestemd.
Tot slot benoemd het SAFe framework in tegenstelling tot LeSS verschillende ondersteunende rollen die de productontwikkeling en het voortbrengingsproces binnen het framework en de teams ondersteunen. Voorbeelden van rollen zijn de Agile Release Train Engineer, het Release Management en Enterprise Architecten. Rollen die sterke overeenkomst vertonen met leidinggevende functies in niet agile organisaties.
4.4 Disciplined Agile Delivery (DaD)
Het DaD framework is afkomstig van www.disciplinedagiledelivery.com
De ontwikkeling van het Disciplined Agile Delivery framework is in 2009 gestart door IBM onder leiding van Scott Ambler en Mark Lines. Het framework is bedoeld voor organisaties die op grote schaal lean-agile willen werken. DaD onderscheidt zich van LeSS en SAFe door de procesgerichte benadering van delivery, de focus op een werkbare oplossing, een significant andere teamsamenstelling en een sterke focus op de omgeving.
Het framework is een lean-agile hybride model en is gebaseerd op het Agile Manifesto dat de bedenkers hebben aangescherpt en vertaald in het Disciplined Agile Manifesto bestaande uit 15 simpele uitgangspunten waarin de focus ligt op het realiseren van werkbare oplossingen voor stakeholders in plaats van producten voor de klant.
In het framework zijn duidelijk invloeden van Scrum, Extreme Programming, XP, Kanban, ITIL, SAFe en Agile Modeling terug te vinden. Maar bovenal is DaD een procesgericht framework met een duidelijke focus op de interactie tussen personen en de brede omgeving van een organisatie.
Producten, oplossingen en software worden op basis van heldere doelstellingen overeenkomstig een vast delivery proces gerealiseerd. De basis Delivery Lifecycle van DaD bestaat uit 5 fasen: concept, inception, construction, transitie en productiefase. In de concept- en inceptionfase worden de visie, roadmap en doelarchitectuur opgesteld die richting geven aan de realisatie van de oplossing. Vervolgens wordt in de constructionfase gestart met de realisatie van de oplossing die in de transitiefase wordt gedeployed en in de productiefase in gebruik wordt genomen door de stakeholders voor wie de oplossing wordt gerealiseerd.
Gedurende dit proces is het DaD team, evenals een traditioneel Scrum Team, gezamenlijk verantwoordelijk voor de realisatie van de oplossing. De samenstelling van het team verschilt echter aanzienlijk van de samenstelling van traditionele Scrum Teams. Binnen het team wordt namelijk een onderscheid gemaakt tussen primaire en secundaire rollen. Een DaD team bestaat uit een Team Lead, Product Owner, Architectuur Owner, team members en vaak maken stakeholders ook onderdeel uit van het team. Daarnaast wordt het team aangevuld met secundaire rollen, waaronder proces-, systeem en technische experts, testers en integrators. Allen zijn volgens het framework noodzakelijk om een werkbare oplossing te realiseren en de interactie tussen het team en de omgeving succesvol te laten verlopen.
Bij de start van de realisatie wordt door het team overeenkomstig de Scrum principes een Iteration Planning georganiseerd, waarin bepaald wordt met welke oplossingen gestart zal worden. In de dagelijkse Coordination Planning wordt de voortgang besproken. Aan het eind van de sprint wordt in de Iteration Review de oplossing getoond aan de omgeving en wordt er afgesloten met een Retrospective waarin de sprint wordt geëvalueerd.
5. De agile organisatie
De maatschappij, klantbehoeftes en verwachtingen veranderen voortdurend. Kwaliteit- en veiligheidseisen worden strenger, wet- en regelgeving worden geharmoniseerd, en technologische ontwikkelingen volgen elkaar in rap tempo op. Tegelijkertijd worden de kwantiteit, snelheid en complexiteit van veranderingen steeds groter.
Om tijdig in te spelen op deze veranderingen zijn in de afgelopen jaren verschillende agile delivery modellen ontwikkeld, waaronder Scrum, Nexus, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe) en Disciplined Agile Delivery (DaD). De modellen en methoden zijn gebaseerd op het Agile Manifesto en hebben allen als doel om gericht, iteratief, incrementeel werkende producten, oplossingen en software te realiseren die voldoen aan de wensen van de klant.
Daarnaast proberen de modellen organisaties handvatten te geven om de transitie te maken naar een volwassen, effectieve agile organisatie die in staat is om tijdig in te spelen op veranderende marktomstandigheden en efficiënt en effectief veranderingen kan doorvoeren.
Welk model het beste past bij een organisatie is afhankelijk van het type, de governance en het volwassenheidsniveau van de organisatie, maar de praktijk heeft inmiddels voldoende aangetoond dat de agile principes en frameworks werken.
Ben je na het lezen van dit artikel geïnteresseerd geraakt? Neem gerust contact met ons op: info@towson.nl.
Onze creatieve collega’s hebben een scala aan workshops ontwikkeld die compact zijn en daarmee eenvoudig ingepland kunnen worden.
De onderwerpen zijn verschillend, maar de kwaliteit van alle workshops is even goed.
We zorgen ervoor dat een onderwerp in maximaal tweeënhalf uur behandeld wordt, dat de werkvormen uitnodigen om de kennis in de praktijk toe te passen en dat iedere workshop draait om fun en samenwerken.
De workshops behandelen altijd een onderwerp dat bijdraagt aan een van de drie pijlers Lean Agile Leadership, executie en teamdynamiek.
In februari starten we met een workshop “Het effectief opstellen van een Definition of Done”. Met deze workshop raken we maar liefst alle drie pijlers. De workshop is gepland voor woensdag 17 februari van half 12 tot 1 uur, en kost € 35,-* per persoon.
Tijdens deze workshop leer je hoe je op een interactieve manier met je team in minder dan een uur een goede Definition of Done kan opstellen. De werkvorm die we je aanreiken borgt dat ieder lid van het team actief uitgenodigd wordt om zijn of haar input te leveren. Hierdoor wordt de Definition of Done ook daadwerkelijk van het hele team.
Om met Jira meer inzicht te krijgen in de status in diverse doorsnedes kun je werken met geavanceerde filters of rapporten bouwen. Best een tijdrovend werk.
Daarom hebben onze collega’s de JQL codegenerator ontwikkeld: een supereenvoudige tool waarmee je, door een paar gegevens in te vullen, gebruik kunt maken van de filters en rapporten die Jira biedt.
Aanvullend goed nieuws op deze eenvoudige tool is dat wij deze ook nog eens gratis beschikbaar stellen. De basistool zal voor de meeste van jullie prima geschikt zijn om direct mee aan het werk te kunnen. Mocht je toch wat extra functions en features willen toevoegen, neem dan even contact met ons op om de mogelijkheden te bespreken.
Wil je ook gebruik maken van onze JQL code generator? Klik dan hier.
