Kumbaya
Waarom willen hele organisaties Agile werken en zijn ze hiervoor bereid om een transitie te doen? Wat was ook alweer het kerndoel om Agile te werken? Richard geeft hier in zijn blog zijn visie op en herinnert ons er nog eens aan waarom ook executive teams een Agile transitie in hun organisatie interessant vinden.
Om maar gewoon met de deur in huis te vallen:
Wat is de aanleiding om ‘Agile’ te werken? Of een Agile transitie te doen, ongeacht de methode of het framework? Waarom überhaupt een transitie doormaken als organisatie en het gehele denken en handelen van mensen in die organisatie van top to bottom willen veranderen?
Is het om medewerkers gelukkig te zien? Is het omdat de concurrentie het doet of omdat dit nou eenmaal hip & happening is? Of zit er zelfs een droom of visie achter dat we een prachtige wereld voor ons zien waarin iedereen gelijk is, en ieders stem gehoord wordt en evenveel gewicht in de schaal legt? We hebben volledig vertrouwen in de goedheid van de mens?
Als je sommige publicaties leest, motivational speakers hoort, Agile HR managers aanhoort en ook Agile coaches beluistert, zou je toch haast het laatste denken.
Als ik nou bestuurder of manager zou zijn die voor de keuze staat om Agile werken te introduceren, wat een radicale verandering met zich meebrengt, dan zou ik toch ernstige bedenkingen hebben als dit de boodschap is die wordt verkondigd. Want wat levert al dit gedoe dan eigenlijk op? Kumbaya?
Waarom toch alleen focus op autonomie, zelfsturende teams, happiness, afbreken van autoriteit/zeggenschap, afbranden van hiërarchie, management of zelfs leiderschap.
Het lijkt wel of de gehele gedachte achter Agile werken volgens hen is: we maken er een mooie commune van waar iedereen gelijk is en de kennis en kunde van een ontwikkelaar gelijk is aan die van een bestuurder, manager, marketingspecialist, productspecialist etc. Iedereen neemt uiteraard automatisch zijn/haar verantwoordelijkheid en optimaliseert zijn/haar werk en ontwikkeltraject, want zo is de mens. Right.
Zijn al deze mensen vergeten, blind of onwetend waar Agile werken voor bedoeld is en welke gevolgen dit heeft voor een organisatie? Of zijn ze het er gewoon niet mee eens?
Iemand de laatste tijd het Agile Manifesto bijgehaald? Waar draait het daar om? Zo snel mogelijk, zo veel mogelijk, zo goed mogelijke waarde leveren. Alles en iedereen staat ten dienste daarvan. En aangezien we dat nooit in 1x goed kunnen doen, gaan we alles in het werk stellen om dit zo snel mogelijk te verbeteren en versnellen.
Dit is zonder twijfel een zeer strikte en economische filosofie welke tot in ieder hoekje en gaatje van een organisatie gevoeld zou moeten worden. Maximale waardecreatie, rigoureuze keuzes maken, continue optimalisatie van efficiëntie en kwaliteit, kritische reflectie op alles en iedereen, keiharde onderlinge concurrentie en eliminatie van de zwakste schakel binnen een team (we willen toch alleen gemotiveerde professionals?).
Alles wordt daarbij vele malen meer controleerbaar door de glasharde transparantie. Waterfall en Prince2 zijn er echt helemaal niets bij, en voordat de engineering projectmanagers commentaar leveren: daar is de feitelijke ontwikkeling al geweest, een project om onderdelen in te kopen en te monteren is geen ontwikkel- of innovatietraject. Mocht dat wel zo zijn, ga dan Agile werken (als je wil weten hoe, neem maar eens contact op).
Alle keuzes die gemaakt moeten worden, gaan om zo snel mogelijk de juiste waarde toe te voegen op het juiste moment, inclusief het meten of het gerealiseerde wel het beoogde effect had zodat het de volgende keer nog beter kan.
Daarnaast is er strak georganiseerde, kortcyclische controle op wat nou iedereen aan het leveren is en hoe de verbetering gaat, inclusief directe feedback van en exposure naar het hoogste echelon.
Iedereen en alles staat dus continu ten dienste van de maximalisering van waarde creatie (wat je ook maar als waarde hebt gedefinieerd als organisatie).
In mijn oren klinkt dat helemaal niet Kumbaya, maar wel erg efficiënt en effectief en daardoor goed voor een organisatie om noodzakelijk snel, wendbaar en economisch efficiënt te kunnen worden en de enige basis waarom je überhaupt aan een Agile transitie begint.
Om de pijn hiervan te verzachten, hebben we prachtige afleidingen, kralen en spiegels bedacht die hopelijk het zicht op deze harde werkelijkheid bedekken. Want goed samenwerkende teams zijn essentieel. Samenwerkingsvormen, mooi ingerichte teamwerkplekken, leuke spannende benamingen als Tribes en Chapters, leuke rolbenamingen, teamspiritverhogende meet-ups en spelletjes, gekleurde post-its op de muren, high fiven bij resultaten. Het ziet er, en klinkt, allemaal prachtig en is ook echt nodig.
Het zijn echter slechts middelen die ten dienste staan van de waardecreatie. Maar om hier de focus op te leggen bij een Agile transitieadvies, is ronduit liegen tegen een organisatie en haar medewerkers.
En zoals eenieder weet, mensen weten dondersgoed als er tegen hen gelogen wordt met alle gevolgen van dien.
Wat is er mis mee dat het om waarde gaat bij een organisatie? Het hele voortbestaan van de organisatie is ervan afhankelijk. Wat kan er dan erg zijn aan eerlijk vertellen dat ieders bijdrage wordt geëist in het realiseren hiervan? De hele reden dat mensen aan het werk zijn bij een organisatie, is om waarde toe te voegen met kun skills, talenten en karakters. Dat er van medewerkers (inclusief management) wordt geëist dat ze zich continu openstellen voor nieuwe inzichten en eigen ontwikkeling? Daar worden ze toch echt voor betaald (vrijwilligers daar gelaten, die krijgen voldoening, hoop ik voor hen). Moeten bedrijven blij zijn met jou als medewerker, of moet jij blij zijn dat je bij dat bedrijf mag werken? Beantwoord die vraag maar als er zich een crisis voordoet waardoor er een flinke werkloosheid ontstaat.
Laten we dus voortaan eerlijk zijn en het beestje bij de naam noemen: Agile werken gaat om maximale waarde te creëren voor een organisatie, niet meer, niet minder. Met deze maximale waarde kan het bedrijf blijven voortbestaan. Alle technieken en manieren van organiseren zijn daarin geoorloofd, als het maar efficiënt en effectief is en natuurlijk meerwaarde oplevert. En laten we de belofte uitspreken dat we allemaal ons best doen om deze nieuwe focus zo aangenaam mogelijk voor elkaar te maken. Dat we iedereen zullen faciliteren in hun ontwikkeltraject. Dat we genoeg zullen regelen zodat zoveel mogelijk mensen het naar hun zin hebben tijdens de uitvoering van hun werk. En dat, mocht dit allemaal niet lukken, we als goede vrienden uit elkaar zullen gaan.
Want: verlies je de focus hierop, dan verlies je de meerwaarde van Agile werken.
Geen oppervlakkigheid gewenst in mijn team- ik zet in op verbinding.
Te allen tijde wil ik voorkomen dat gegevens verborgen blijven. Ik heb liever openhartige debatten. Pas wanneer iedereen zijn standpunten en perspectieven naar voren brengt, kan een team met vertrouwen een beslissing nemen.
Tijdens mijn coaching gebruik ik de piramide van Lencioni (elk niveau komt voorbij in een aparte post): in mijn eerdere posts heb ik mijn kijk gedeeld op vertrouwen en constructieve conflicten.
Deze blog gaat over betrokkenheid, het derde niveau binnen de pyramide van teamontwikkeling. Wat heeft het ontbreken hiervan te maken met de volgende frustratie in een team? Een niet te onderschatten invloed!
In elk team heeft elk teamlid een zekere mate van oppervlakkigheid. Anders zou er ook geen mode industrie- of schoonheidsindustrie bestaan: we vereren jeugd, en willen daar zo lang mogelijk deel van uitmaken. Als ik eerlijk ben heb ik dit ook eerder als mechanisme ingezet om mij te beschermen tegen alles wat pijn zou kunnen doen of niet leuk is. Maar klopt mijn aanname wel? Oppervlakkigheid behoedt je namelijk wel voor heel wat teleurstellingen.
Als je ‘meer’ verwacht, loop je ook het risico dat dingen tegenvallen (en dat doen ze vaker wel, dan niet). Dat gaat op voor kunst, aspiraties, de liefde, noem maar op. Maar hoe oppervlakkig dit ook voelt- in de hedendaagse maatschappij toont Schoonheid je geschiktheid als partner, collega en/of geschikte medewerker en vormt zo de basis van onze evolutie. Je moet er niet aan denken hoe we eruit zouden hebben gezien als onze voorouders.
Tijdens mijn coachopdrachten loop ik (dagelijks) in de omgang tegen oppervlakkigheid aan. Wat is dat precies? Zodra men niet wil of durft om zaken met diepgang te bespreken, te schrijven of te bedenken. Het kan naar voren komen tijdens oppervlakkige gesprekken of onderzoeken. Wanneer zaken letterlijk aan de oppervlakte blijven, of men het gevoel krijgt dat we als team oppervlakkig blijven. Als er bij de samenwerking oppervlakkig wordt gesproken, geschreven of besloten.
Binnen de context van teams is betrokkenheid een functie van twee zaken; duidelijkheid en steun. Bij goed functionerende teams worden tijdige en duidelijke beslissingen genomen.
In echte teams wordt met volledige instemming gewerkt van alle teamleden, ook van de teamleden die tegen besluiten hebben gestemd. Na het einde van elke meeting/vergadering beseft iedereen dat er geen enkel teamlid twijfelt over de genomen keuzes.
De twee belangrijkste oorzaken van gebrek aan betrokkenheid zijn het verlangen naar contentie en de behoefte aan zekerheid. Ook bij goed functionerende teams weet ik dat het gevaarlijk kan zijn om te intensief die consensus op te zoeken. Volledige overeenstemming is soms onmogelijk maar samen op zoek naar kleine manieren om steun te verwerven gaat sneller in goed functionerende teams. We weten allemaal dat je als persoon niet altijd je zin hoeft te krijgen, maar dat jij je zodanig kunt opstellen dat het toch mogelijk is om je achter een beslissing te scharen. Daardoor ontstaat de bereidheid om verder te gaan, ongeacht het groepsbesluit. Bij een mogelijke impasse is het aan de teamleider om dan de knoop door te hakken. Daarvoor is wel nodig dat het standpunt wordt aangehoord en uiteindelijk wordt meegewogen bij de besluitvorming. Bij zelf organiserende teams wordt ook dit door het team zelf genomen en in de traditionele gevallen wordt de manager of teamleider gevraagd om hulp.
De tweede eigenschap binnen goed functionerende teams die betrokken zijn is de hoge mate van zekerheid. Goed functionerende teams zijn vaak trots op de gehaalde doelen met elkaar en staan graag achter beslissingen. Zij engageren zich ook volledig met plannen.
Ook in het geval van weinig zekerheid nemen we besluiten met zijn allen en dus zijn wij met z’n allen verantwoordelijk voor het resultaat. In deze teams zie ik vaak terug dat elke beslissing beter is dan geen beslissing. Als je dit vergelijkt met slecht functionerende teams is de trend dat besluiten worden uitgesteld. Meestal ligt hier achter de zekerheid van het te nemen besluit (Is het nou goed wat we van plan zijn te gaan doen?). Hoe verstandig dit misschien ook lijkt, het kan leiden tot verlamming in het team. Het is ook van belang te beseffen dat de bereidheid tot constructieve conflicten ( zie eerdere post) de basis vormt voor de bereidheid tot engageren als sprake is van onvoldoende informatie.
Als je een team hebt waar de betrokkenheid minder is, is het tijd om aan de slag te gaan. Bedenk je: hoe gaat een team te werk dat eenheid wil creëren? Hiervoor kun je een aantal instrumenten inzetten. Denk hierbij aan gebruik van een besluitenlijst, deadlines, analyse van worst case -scenario’s (zorgt voor inperking van angsten), blootstelling aan lage risico’s (opeisen dat elke teamlid een besluit helpt nemen).
Als ik teams help om te betrokkenheid te vergroten zal ik als coach de groep voortdurend aansporen tot discussie rond problemen af te ronden en zich te houden aan de planning of het overeengekomen proces.
Tegelijkertijd probeer ik minder de nadruk te leggen op zekerheid en consensus.
Uiteindelijk wil ik dat mijn team als een eenheid optreedt en zich blijft ontwikkelen en fouten durft te maken. Kansen inzien of profiteren van kansen. Blijven handelen zonder aarzeling ook in geval van veranderingen of schuldgevoelens.
Niet vanuit het ‘ik’ en ook niet vanuit het ‘zij’ maar vanuit het ‘wij’ ontstaan de mooiste dingen.
Door Stanley Markiet, consultant bij Towson
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.
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]”.
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!
1. Introductie
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.
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.
1. Large-scale scrum is scrum – Multiple team Scrum versus multiple Scrum Teams
2. Customer Centric – Focus op klant en klantbehoefte vormt basis voor productontwikkeling
3. Whole product focus – Focus op product en toegevoegde waarde voor de klant
4. Lean Thinking – Creëer flow, vermijd rijen en verwijder de 7 verspillingen
5. System Thinking – Denk in systemen in plaats van oorzaak gevolg
6. Emperical proces control – Inspecteer, observeer en pas aan op basis van bevindingen
7. Queing theory – Reduceer en beperk rijen, work in progress, multi-tasking en variatie
8. Transparancy – Creëer transparantie en geef inzicht in de voortgang en complexiteit van werkzaamheden
9. More with LeSS – Bouw een agile organisatie bottom-up en niet top-down met behulp van management
10. 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.
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.
1. Take an economic View – Change op basis van economische afwegingen (cost of delay)
2. Apply systems thinking – Optimaliseer ketens in plaats van (stand alone) componenten
3. Assume variability, preserve options – Ga uit van variëteit, wees flexibel en beschik over alternatieven
4. Build incrementally with fast, integrated learning cycles – Gebruik iteraties, test en evalueer periodiek (PDCA)
5. Base milestones on objective evaluation of working systems – Stel realistische doelen en vermijd tolgates
6. Visualize and limit WIP, reduce batch sizes, and manage que lengths – Creëer flow en monitor work in progress
7. Apply cadence, synchronize with cross domain planning – Hanteer een vast ritme, synchroniseer en plan delivery
8. Unlock the intrinsic motivation of knowlegde workers – Motiveer en activeer intrinsieke motivatie
9. 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.
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.
