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.
Goal:
Identify, classify and effectively manage your stakeholders
Duration
45-90 minutes
Group size
Game could be played with individuals, pairs or groups and is easy to scale up. Ideal group size is up to 6 people. More Participants? Just make two groups and do the game in parallel
Preparation
Buy a brown paper or white board paper and markers. Bring lego figurines or play mobile, chess pieces with you. Draw a stakeholder map with two axes ‘interest’ and ‘influence’
Game description
Start the game with a short discussion about what customers and stakeholders are and discuss what the benefit of good customer and stakeholder management is. Explain the game and stakeholder map to the group so all the participants understand the goal and rules of the game. Subsequently ask the participants the following questions:<!— wp:paragraph –>
What is your general stakeholder message?
Who are your stakeholders?
How would you qualify the stakeholders in terms of influence and interest? Plot your stakeholders on the stakeholder map (as-is).
What is the desired state/qualification of your stakeholders? Draw a line on the map which displays the direction in which your customers and stakeholders should move (to-be).
How would you manage your customers and stakeholders? Determine a strategy for each stakeholder (group).
If there is more time you could ask how you would like to go about with your communication strategy towards your stakeholders.
Let participants share their insights and summarise the goal and outcomes of the game.
Enjoy and success with managing your stakeholders.
In mijn vorige artikel heb ik geschreven over vertrouwen. Dit is de basis voor een goede samenwerking en voor open communicatie omdat je dan kwetsbaar durft te zijn.
Alleen binnen teams waar het vertrouwen goed is kunnen we de volgende stap richting een goede samenwerking nemen.
Wanneer we niet kwetsbaar kunnen zijn en open kunnen communiceren, zal de kans op een ongezond conflict (ruzie) exponentieel toe nemen waardoor men afziet van een ongeremde, open discussie met elkaar. Als deze discussie er wel is en we standpunten kunnen delen en belichten met het doel samen iets te bereiken, noemen we het een gezond conflict.
We bespreken zaken open en nemen op basis hiervan samen besluiten waar we als team achter kunnen staan, juist omdat we de standpunten hebben gedeeld en uitgedaagd.
Teams waar het vertrouwen goed is kunnen deze volgende stap nemen.
In de piramide van Lencioni noemen we dit “het gezonde conflict durven opzoeken met elkaar”.
Gezond conflict
Vaak worden conflicten als iets negatiefs gezien terwijl dit zeker niet aan de orde is.
Het is pas negatief wanneer een conflict te hoog oploopt en destructief wordt voor de samenwerking met elkaar.
Vaak is de basis van een negatief conflict “gelijk willen krijgen”, met als gevolg dat collega’s elkaar binnen de afdeling of binnen het team niet meer durven aan te spreken en dat ze elkaar minder zullen vertrouwen. Ieder gaat zijn eigen weg en er ontstaat een kunstmatige harmonie. Nergens is er sprake van conflict, of interesse in elkaar of in de gezamenlijke doelen.
We willen het conflict juist gebruiken om elkaar te begrijpen door elkaar uit te dagen op standpunten dan wel op een positieve manier waarbij wij ruimte laten zodat iedereen in zijn waarde kan blijven. Het conflict kan hier worden gezien en toegepast als middel om het vertrouwen in een team te versterken. Het wordt de basis voor het creëren van betrokkenheid en het nemen van eigenaarschap binnen het team.
Conflictstijlen
In de praktijk zijn er meerdere fasen en stijlen van conflicten- denk hierbij aan bijvoorbeeld toegeven, vermijden, exploreren of doordrukken. Elk van de stijlen van conflicthantering kan zich manifesteren tussen collega’s of teams. Afhankelijk van de karakters van de betrokkenen, het eigenbelang of het belang van de ander kan een bepaalde stijl zich nadrukkelijker manifesteren.
Het is goed om voor jezelf te bepalen welke stijl wenselijk is bij de specifieke situatie. Uiteindelijk moet ieder wel de wil houden om er samen uit te komen. Want je bent onderdeel van het team en nog steeds samen verantwoordelijk voor een doel.
Blijf dus hoe dan ook op zoek gaan naar een win-win situatie; tenslotte wil je met elkaar verder. Win-Win betekent overigens niet altijd compromissen.
Maar de persoon of partij die niet het gewenste resultaat krijgt moet wel de kans hebben om goed te begrijpen en te kunnen accepteren dat de keuze goed is voor het halen van het team is waar we allen toe behoren. Hiermee behoud je de relatie met elkaar en voorkom verkrampte reacties.
Wanneer binnen een team sprake is van een constante behoefte aan consensus lijkt alles bespreekbaar. Het continu kiezen voor de veilige middenweg, met de mindset “kan iedereen zich hierin vinden”, veroorzaakt uiteindelijk vooral gevoel van vaagheid over de richting en uiteindelijk is er nooit sprake van heldere prioriteit. Dit gaat direct ten koste van de betrokkenheid van de collega’s in het team en daarmee het wel of niet nemen van persoonlijk eigenaarschap. Teamleden zullen steeds minder offers brengen en dit kan zelfs doorschieten in opportunisme (eigen gewin) of ongeloofwaardigheid om ooit als team tot de beste resultaten te komen.
Kortom: zonder gezond conflict gaan teamleden twijfelen over de juistheid van genomen beslissingen.
Gaspedalen
Binnen mijn eigen opdrachten ben ik ook situaties tegengekomen waarbij ik te maken had met eigen vaste patronen. Ieder mens heeft vaste patronen die we allemaal bewust en onbewust toepassen in ons gedrag en onze communicatie. Ik noem ze ook wel onze “gaspedalen”. De vier gaspedalen zijn: -D(direct). -I(inspirerend). -S(supporting), -C(correct).
Door oefenen kan iedereen deze gaspedalen naar behoefte harder of zachter intrappen.
Naar gelang de situatie ben je vrij om te switchen tussen deze pedalen. Het helpt mij persoonlijk om de verbinding op te zoeken met mensen die van nature een ander gaspedaal dieper indrukken dan ik onbewust doe. Door dan wat anders “gas te geven” kan ik beter contact maken en daardoor ook beter omgaan met conflicten in mijn team of met mijn gesprekspartner. Mijn eigen natuurlijke voorkeursgedrag is “mensgericht”, iets wat niet goed of fout is, maar in situaties waar men juist heel “taakgericht” is zou ik minder effectief kunnen zijn. Wanneer ik mijn communicatie dan niet wijzig zal de kans op onbegrip, wrijving of conflict toenemen.
Sinds ik het DISC-model heb ontdekt gebruik ik het ook bij mijn teamcoaching.
Ik leer de mensen die ik coach onderling ook actief gebruik te maken van de gaspedalen die we van nature misschien niet zo snel intrappen. Hierdoor beginnen we elkaar beter te begrijpen en soms zelfs beter te waarderen en dat helpt dan weer de onderlinge communicatie te verbeteren. Doordat er ruimte ontstaat om waardering te oogsten terwijl je jezelf bent, stimuleert het ook het benutten van talent en vergroot het de individuele effectiviteit binnen het team.
Iedereen heeft sterke kanten die ons uniek maken waarvoor we graag erkend willen worden, met de erkenning van onze sterke kanten. Echter, elke sterke kant, indien overmatig of onjuist toegepast, kan ook worden gezien als een zwakke kant en daarmee verval je in overcompensatie en ongezond conflict. Kortom: balanceren, en bij elkaar blijven toetsen, is de sleutel.
Ik help mijn teams altijd de DISC-stijlen te herkennen door het observeren van de verbale en non-verbale communicatie. Zo vinden we bij de samenwerking snel de juiste handvaten om tot gezond conflict te komen. Als je je eenmaal bewust bent van elkaars communicatiestijlen, gedragsvoorkeuren en woordgebruik ben ik ervan overtuigd dat conflicten anders zullen worden beleefd. Dit zal dan weer helpen om afscheid te nemen van die kunstmatige harmonie waar we weinig aan hebben.
Ik nodig je van harte uit om te reageren en mijn posts te delen met anderen in je eigen netwerk.
Daarnaast geven collega’s en ik ook workshops rondom leiderschap en teamperformance.
Kijk eens op https://towson.nl/workshops voor meer informatie.
Ondanks dat vertrouwen niet zichtbaar of grijpbaar is hebben we allemaal een begrip, maar ook vooral een gevoel bij het woord vertrouwen. Wanneer je het woord in een woordenboek opzoekt zal een volgende tekst verschijnen:
“Bereidheid van een persoon of groep om afhankelijk te zijn van de daden van een andere persoon of groep”.
Het is niet voor niets mijn eerste artikel: zonder vertrouwen is er geen sprake van een team. Daarom is het ook zo belangrijk om in de eerste fase van de teamvorming en de coaching van je teams zo nadrukkelijk stil te staan bij vertrouwen.
Wanneer teams gevormd worden hebben we het wel over een team, maar in feite is het nog een groep. In deze fase is het nog “los zand”. En dat komt omdat in een beginnend team de leden elkaar nog niet volledig vertrouwen. Per slot van rekening is er dan ook nog helemaal geen basis voor vertrouwen omdat je nog niet weet hoe afhankelijk je van de anderen kunt zijn of bent, dus hier is gelijk werk te doen.
En dat leidt dan gelijk weer tot de volgende vraag: Welk niveau van vertrouwen is nodig om onze doelen te behalen en om een effectief team te zijn waar eenieder zich in thuis voelt en graag in wil werken?
Angst
De bereidheid en het vermogen om je afhankelijk (kwetsbaar) op te stellen heeft veel aandacht in de eerste fase, maar het gaat natuurlijk om een continu proces. Bij vertrouwen gaat het niet alleen over krijgen maar zeker ook over vertrouwen bieden. Dit is onderdeel van mijn aanpak als teamcoach.
Er zijn elementen waaraan je heel snel kunt zien dat er sprake is van vertrouwen binnen een team. Er is binnen een team de bereidheid om te werken met de geldende (geschreven en ongeschreven) regels. Binnen dit team zijn mensen bereid hulpvragen aan elkaar te stellen, maar ook bereid om elkaar aan te spreken. Mijn ervaring is dat iedereen zich eerst veilig moet voelen en bekend moet zijn met elkaars gedrag. Neem als voorbeeld autorijden.
Als we zelf de verkeersregels kennen, de auto zelf veilig genoeg vinden en we er min of meer van op aan kunnen dat anderen ook de regels kennen en ook hiernaar handelen, durven we de weg op. We hebben er dan vertrouwen in dat het goed komt.
Wat ik regelmatig ervaren heb is dat men uit angst voor de eigen veiligheid zich niet uitspreekt, bijvoorbeeld uit angst voor de reactie (of zelfs actie) van de leidinggevende.
Wat er dan ontstaat is schijnvertrouwen; alles lijkt goed, maar onder de oppervlakte groeit de onvrede en de afstand tussen de teamleden. Niks zeggen betekent dus ook dat er automatisch van je verwacht wordt dat je doet wat anderen willen. Dit gedrag wil ik niet binnen mijn teams en daarom besteed ik hier veel aandacht aan.
Open en gelijkwaardige communicatie kan soms wat schuren en zelfs wat pijnlijk zijn, maar is een belangrijke pijler voor vertrouwen.
Manifesto
Binnen teams met genoeg vertrouwen hoef je niet bang te zijn bij een misstap.
Binnen teams waar het vertrouwen goed zit, gelooft men erin dat het soms niet helemaal gaat zoals gepland maar dat het werk met de juiste intenties is uitgevoerd. Het naderhand bespreken in de retrospective is hierbij natuurlijk belangrijk; samen leren van je fouten en het vervolgens beter doen is een belangrijke bouwsteen in het team vertrouwen.
Hieronder een aantal kenmerken van teams waar het vertrouwen ontbreekt:
Zeer afwachtende houding bij het vragen om hulp
De teamleden koesteren veel wrok naar elkaar
Binnen het team worden regelmatig onterechte conclusies getrokken over bedoelingen/bekwaamheden van anderen zonder deze te (kunnen) verklaren
Teamleden die elkaar ontwijken en sprake van structurele afwijzing van meetings of gesprekken met elkaar
De teamleden verbergen hun eigen zwakte en fouten voor elkaar
Er is sprake van grote aarzeling bij het bieden van hulp
Daarom is het opstellen van een Teammanifesto een van de topics die ik bij een retrospective ook graag doe. Het is een waardevolle manier om het onderwerp vertrouwen binnen een team bespreekbaar te maken en het maakt de waarden die teamleden belangrijk vinden in het team expliciet waardoor er minder of geen ongeschreven regels meer zijn waar men zich aan moet houden.
Ter vergelijking: als je bij een concert achterwaarts wil “stagediven” moet het zo zijn dat je het liefste wilt dat de mensen die je opvangen de collega’s zijn uit jouw team. Want je wilt dat het team je opvangt mocht het misgaan.
Zou jij het durven binnen je huidige team?
Ik nodig je van harte uit om te reageren en mijn posts te delen met anderen in je eigen netwerk.
Daarnaast geven collega’s en ik ook workshops rondom leiderschap en team performance.
Kijk eens op https://www.towson.nl/trainingen voor meer informatie.
We all have intrinsic motivators that inspire us to perform an activity to get a job done: “pride”, “order”, or “mastery”, just to name a few.
Management 3.0 offers a game called Moving Motivators. Basically, it’s nothing more than 10 cards, each with the description of one motivator, and designed as a one player game.
My experiment was to make it a group game.
I started the game by handing each team-member a card deck and asking them to rank the motivators in order of importance measured against their own values. The “motivators” to be ranked were curiosity, honor, acceptance, mastery, power, freedom, relatedness, order, goal and status. The participants in my experiment did not take this task lightly and needed some time to think about their choices.
After all personal rankings were made, they were shared with the other team-members, not intending to start a discussion, but just to get a better understanding of what each team-member had ranked the highest. Finally, I asked a simple question:
“As of now, your team is fully self-managed and therefore as a team you are truly responsible and accountable for your team success. Would this change the order of your motivators?”
I did this experiment several times now and without fail each team-member had a few motivators that would become more important. Funny side note, this even happens in teams that had already declared themselves self-managed.
There are two levels of insights here:
On a personal level; when we are part of a team, we are willing to put more emphasis on the motivators that are the most important motivators for the good of the group instead of our personal motivators;
Our personal motivators are literally moving when the objective of a group has changed or when new members join the team.
Hiernavolgend is een aantal artikelen waarin ik deel wat ik zoal heb ervaren bij verschillende organisaties tijdens mijn opdrachten. Dit doe ik met een duidelijke knipoog naar Lencioni.
Ik gebruik Lencioni hierbij omdat dit een structuur is die ik graag toepas als ondersteuning van mijn teamcoaching-trajecten; en omdat het een prima kapstok is voor de toekomstige berichten in deze reeks.
In de volgende berichten zal ik ingaan op
– Gezamenlijke doelen;
– De verbinding, spanning en uitdaging binnen een team;
– Teaminteracties, zoals hoe om te gaan met emoties en hoe gebruik te maken van de kracht van de ander;
– Hoe gaan we om met eigenaarschap en verantwoordelijkheid;
– Aandacht voor houding en gedrag en hoe houden teamleden hier elkaar scherp op.
Ik nodig je van harte uit om te reageren en mijn posts te delen met anderen in je eigen netwerk.
Daarnaast geven collega’s en ik ook workshops rondom leiderschap en teamperformance.
Kijk eens op onze trainingen voor meer informatie.
Scaledagile.com heeft enige dagen geleden de verwachte update van SAFe 4.6 naar SAFe 5.0 aangekondigd. Het gaat bij deze update om een grote aanvulling op het model. Nieuw is bijvoorbeeld de nadrukkelijkere aandacht voor het centraal stellen van de klant binnen organisaties. Hiervoor is zelfs een extra “business agility” poster ontwikkeld.
Omdat het bij nieuwe versies van SAFe altijd om uitbreiding op de bestaande basis gaat, is je kennis die je in eerdere trainingen hebt opgedaan nog altijd even valide en toepasbaar.
Met de toevoeging van Business Agility worden organisaties die zich door SAFe laten ondersteunen nog beter in staat gesteld om op de snel veranderende markt in te spelen met innovatieve oplossingen.
Om alles wat in SAFe 5.0 nieuw is goed tot je te nemen, organiseren wij een update workshop. In 4 uur tijd nemen we je door de nieuwe big picture inclusief de bijbehorende business agility poster.
Deze workshop is een uitstekende basis voor iedereen die een geldig SAFe Agilist badge heeft en gebruik wil maken van de mogelijkheid om deze te vernieuwen naar SAFe 5.0.
Maar ook als je geen geldige SAFe 5.0 badge meer hebt is het natuurlijk een uitstekende manier om bij te blijven met de ontwikkeling van Scaledagile.com
De kosten voor deze workshop, inclusief SAFe Big picture op A0 formaat, waren slechts € 250,- ex. BTW. De workshops werden gegeven op 10 en 24 januari*.
Make a different start and have a better meeting just by sharing your appreciation.
In my meetings a check in has been the first point of order for a while now.
All attendees take a moment to state that they are free of impediments to give their full attention to the meeting.
Or: they share that there actually is an impediment. Sometimes the notification is sufficient and other times there is a short discussion about this specific impediment.
And even though I always thought this part of the meeting was valuable, I always had the feeling that there was something more that could be done.
Recently I bought a box of Management 3.0 Kudo Cards just because I thought it was good fun to have an easy enabler for everybody in my company to share their appreciation for one another.
And then I got this super simple idea that I would like to share with you.
When you chair the meeting, make it a point to share your appreciation to each participant present.
Before the meeting just write a Kudo Card for all participants. Have the cards on the table with the compliment face down and the name of the intended compliment-receiver on the back of the card.
As you open the meeting, invite everyone to take their own card. I like to leave it optional to the recipient of the compliment to share their compliment, since a compliment can be rather personal.
After sharing the compliment, I still do the check in. But now it feels “complete”. We ask all participants if there are impediments to a full commitment to the meeting we are about to have, after we shared our appreciation for each other.
I have done this a few times now and my experience is that not only did we have a better meeting that day, we had a better day together in general!
