Stel je hebt 3 agile teams die volgens Scrum werken en nu wil je – opschalen Scrum is niet meer genoeg. Wat is de volgende stap? Daar zijn verschillende frameworks voor, waaronder SAFeNexus, en vele anderen. Vandaag nemen we LeSS onder de loep.
LeSS is SCRUM (definitie)
De LeSS-kader probeert de principes en idealen van Scrum zo eenvoudig mogelijk toe te passen in een grote bedrijfscontext door middel van gedefinieerde regels en richtlijnen. Vanwege zijn eenvoud heeft LeSS de definitie of het label gekregen van een "nauwelijks adequaat" framework –, maar dit is niet om het in een negatief daglicht te stellen.
7 Voordelen van het LeSS-raamwerk
De fundamentele focus van LeSS is niet het creëren van een nieuw raamwerk. In plaats daarvan worden de Scrum principes toegepast op veel teams.
Enkele voordelen van LeSS kunnen worden bereikt zijn:
- Lagere implementatiekosten door werkwijzen te implementeren die teams al gebruiken in Scrum
- Een producteigenaardie het raamwerk en de principes begrijpt en vervolgens de brug slaat tussen het bedrijf en de technische teams.
- Voor de Levering van een product, zullen minder mensen nodig. LeSS voegt niet exponentieel meer rollen en overhead toe
- Het biedt een volledig productoverzicht in het aandachtsgebied
- De Teams staan in direct contact met de klant en andere belanghebbenden
- Voortdurende verbeteringen worden gefaciliteerd door regelmatige retrosessies en andere bijeenkomsten, die fundamentele processen zijn van het Agile Manifesto
- Voor veel bedrijven kan de LeSS-aanpak voor het schalen van Scrum-teams het volgende zijn de volgende logische stap op hun weg naar wendbaar schalen.
Voordat we dieper ingaan, een korte opmerking. Onlangs hadden we 11 internationale agile experts te gast in een webinar – over een vraag: Hoe schaal je agile methoden goed op?
Het resultaat is deze fantastische video-opname (Engels), waarin bijvoorbeeld de volgende vragen aan bod komen:
- Is het beter om bottom-up of top-down te beginnen?
- Hoe krijg je leiders op één lijn over een gemeenschappelijke visie?
- Hoe kies je het juiste agile framework – en waarom is dat eigenlijk niet zo belangrijk?
Mijn warmste aanbeveling: neem een kijkje! Het duurt relatief lang, maar het is elke minuut waard.
Hoe is LeSS opgebouwd? Een definitie
Per definitie is Large Scale Scrum gebouwd op principes, raamwerken, richtlijnen en experimenten. De illustratie (bron: LeSS website) laat het zien. Laten we dit uitleggen met een voorbeeld:
Principes: Team X ontwikkelt een mobiele telefoon. Het principe van transparant handelen is belangrijk voor hen. Daarom werken ze transparant en maken ze regelmatig dagopnames. Aan de andere kant willen ze erachter komen waar de materialen die belangrijk zijn voor de productie van de mobiele telefoon precies vandaan komen, zodat ze dit later transparant aan hun klanten kunnen communiceren. Transparantie door en door.
randvoorwaarden: Tegelijkertijd werken ze voortdurend aan het creëren van de randvoorwaarden die het SCRUM-raamwerk ideaal maken met de agile waarden definieert: Openheid, Moed, Respect, Focus & Commitment.
Leidende principes: Leidende principes voor ontwikkeling zijn de productvisie, de technische eisen voor het product, maar ook de manier van samenwerken in het team.
Experimenten: Als er onzekerheden ontstaan, bevinden we ons in het experimenteergebied, waar het draait om testen en dingen uitproberen. Bijvoorbeeld als we een nieuwe functie willen ontwikkelen of een compleet nieuwe doelgroep willen aanboren. (Bron: LeSS website)
De 10 LeSS-principes
LeSS gedefinieerd 10 Principes. Ze helpen – als we vasthouden aan ons voorbeeld – om een mobiele telefoon te ontwikkelen die het meest overeenkomt met de waarden en ideeën van de klant. Hier is de lijst met de 10 principes in één oogopslag:
- Scrum op grote schaal is Scrum: De mobiele telefoon kan niet door één maar door meerdere teams worden ontwikkeld, zodat de klant tevreden is en de ontwikkelingstijd redelijk is.
- Empirische procesbesturing: Op basis van kortstondige ervaring worden individuele functies van de mobiele telefoon voortdurend aangepast en herzien.
- Transparantie: Ons Team X besluit om de wekelijkse teamdoelen voortaan transparant te delen op hun interne platform. Dit helpt enorm om te begrijpen waar iedereen nu eigenlijk mee bezig is.
- Meer met minder: In principe moet je experimenteren met nieuwe ideeën en ervan leren voordat je inerte regels opstelt en dus "ballast" toevoegt.
- Productgerichtheid: Teams hebben een nog grotere neiging om hun doelen te onderoptimaliseren dan individuen. Daarom is de grootste uitdaging voor teams om hun werk te integreren in een product. Het "doel" van het hele product moet daarom zo duidelijk mogelijk zijn. De teams en individuen worden zo in staat gesteld om zelf de juiste subdoelen te definiëren als dat nodig is.
- Klantgerichtheid: Alleen teams die direct met de klant werken, kunnen de echte waarde van het product maximaliseren. Helaas hebben organisaties de neiging om teams los te koppelen van de klant zodra ze beginnen te groeien. Om dit tegen te gaan worden klanten regelmatig uitgenodigd op teambijeenkomsten om bijvoorbeeld feedback te geven.
- Voortdurende verbetering naar perfectie: LeSS is voor veel organisaties een ingrijpende verandering. Merk op dat het niet automatisch verbetering betekent. LeSS stelt de organisatie in staat om beter te worden – en vanaf dat moment moet je continu optimaliseren. LeSS is een proces!
- Lean denken: LeSS benadrukt vooral het zien van de plaats van de gebeurtenis zelf (Gemba), het leerconcept in drie fasen ShuHaRi (Shu = imiteer, Ha = varieer, Ri = bepaal je eigen regels) en respect voor mensen.
- Systeemdenken: Alle acties, veranderingen en verbeteringen moeten altijd systematisch of in overeenstemming met het systeem worden bedacht om de doelen te bereiken. Voorbeeld: Als ik theoretisch financiële bonussen aanbied in één team – wat betekent dat dan voor andere teams (dus voor de rest van het organisatiesysteem)?
- Wachtrijtheorie: Het basisidee is dat we in de softwarewereld veel onzichtbare wachtrijen opbouwen (bijv. documenten met eisen, ongeteste software) en ons nauwelijks zorgen maken over de optimale afhandeling van deze wachtrijen. Wist je bijvoorbeeld dat wanneer het gebruik van een resource toeneemt van 50% tot 90%, de wachttijd voor nieuwe taken niet ongeveer verdubbelt, maar verveelvoudigt? Bepaal dus WIP-limieten (onderhanden werk), vermijd multitasking en grote werkpakketten.
De LeSS-raamwerken
LeSS biedt twee configuraties: Basis LeSS voor Twee tot acht teams (10 tot 50 personen) en Groot LeSS voor Meer dan acht teams (50 tot 6.000 mensen en meer).
Bron: Minder.werkt
Het wordt aanbevolen om te beginnen met Basic LeSS om te experimenteren, ervaring op te doen en feedback te krijgen voordat je direct naar LeSS Huge gaat. Er zijn twee voorgestelde benaderingen voor de introductie van LeSS Huge:
- Begin met één vereist gebied per keer binnen het grotere product en richt je daar in eerste instantie alleen op.
- Of breid geleidelijk de scope van het werk van het team, de Definition of Done en de Product Definition uit.
Op deze manier kan een bedrijf teamervaring opbouwen met LeSS, uitbreiden in één productgebied, een eerste succes – boeken en zo managementondersteuning krijgen voordat LeSS in het hele bedrijf wordt opgeschaald.
Trouwens, een korte opmerking in de context van agile transformatie: Wil je ervoor zorgen dat je op dit moment de juiste prioriteiten in je agile Transformatie?
Doe dan onze volwassenheidstest voor je agile transformatie – duurt slechts 3 minuten. Je krijgt zelfs een benchmark op basis van meer dan driehonderd andere deelnemers. Zie knop 🙂
Rollen en planning in LeSS
Basis LeSS richt zich op het team en de belangrijkste Scrum rollen:
- De Scrum Product Owner, die verantwoordelijk is voor de productvisie en -richting.
- de Scrum-ontwikkelteams die verantwoordelijk zijn voor het maken en afleveren van producten
- De Scrum Master, die het team ondersteunt bij continue verbetering.
- De rol van de manager en hoe hij/zij het team ondersteunt bij het wegnemen van obstakels of "belemmeringen" voor continue verbetering en autonomie (uitbreiding op SCRUM).
Huge LeSS vult Basic LeSS aan met de volgende rollen:
- De LeSS Huge Regional Product Owner ondersteunt Product Owners en is cruciaal in het verbinden van zakelijke vereisten (financiën etc.) met de ontwikkelteams.
- De Area Product Owner is gespecialiseerd in klantgerichte taken en fungeert als product owner voor productgerichte feature teams.
De meeste Agile Coaches gaan rond in cirkels....
...en oppervlakkige symptomen behandelen. Het is tijd om psychologie – te gebruiken voor een duurzame mentaliteitsverandering.
Bijeenkomsten in LeSS
De Product Backlog Verfijning (PBR) Bijeenkomst
PBR-bijeenkomsten breiden de sprintplanning uit over focusgebieden door middel van een reeks parallelle LeSS sprintuitvoeringen. De voortdurende cadans van deze bijeenkomsten is nodig in elke sprint om elementen te begrijpen, te bespreken en te verfijnen en om toekomstige sprints voor te bereiden. De belangrijkste activiteiten van PBR-bijeenkomsten zijn:
- Creatie van Epics – d.w.z. clusteren van grote overeenkomende onderwerpen; in ons voorbeeld zou dit het samenvoegen van de sprints van het Design & Usability Team zijn.
- Verduidelijking en beantwoording van open vragen: iedereen moet hetzelfde begrip hebben van het product en de ideeën van de klant en collega's.
- Inschatting van de omvang van de user story, de risico's, de afhankelijkheden: Quasi de afleiding en gedetailleerde planning van de afzonderlijke onderwerpen
De Sprint beoordeling
Vergelijkbaar met Scrum: De sprint review is een bijeenkomst aan het einde van een sprint om het werk dat is gedaan te beoordelen in relatie tot het sprintdoel. Dit gaat over het product zelf. De voortgang wordt zichtbaar gemaakt en nieuwe actiegebieden worden geïdentificeerd. Het maakt de voortgang ten opzichte van het product en het doel transparant.
De Retrospectief
Vergelijkbaar met Scrum: De retrospective is een bijeenkomst die gaat over de samenwerking binnen het team. Het gaat over het verbeteren van de samenwerking binnen het team en dus over het verbeteren van processen en inhoud. Het gaat ook over de interactie tussen individuele ontwikkelaars, het werk van de Scrum Master en de communicatie met de Product Owner. Dit maakt de retrospective een belangrijk onderdeel van een continu verbeteringsproces (CIP).
Bij grootschalige Scrum wordt soms aanbevolen om een "retro of retros" uit te voeren, d.w.z. over veel teams.
Grootschalige Scrum – Scrum Master Ratio
Hoeveel teams moet een Scrum Master hebben? Je kunt stellen dat één Scrum Master per team het beste is – hoewel dit ook Nadelen heeft. In de regel de verhouding Scrum Master op grote schaal is 1:1 tot 1:3 – een Scrum Master heeft één tot maximaal drie teams.
Wanneer is Large Scale Scrum LeSS de juiste Agile methode?
Large Scale Scrum kun je gebruiken als je al met SCRUM werkt en Scrum wilt opschalen. Maar ook om de balans te vinden tussen zelforganisatie en regels.
Bas Vodde zei ooit dat hij en Craig Larman Ik denk dat LeSS een heel goede aanpak is omdat het het midden houdt tussen zoveel begeleiding als nodig en zo weinig mogelijk.
Net als Scrum zelf is het slechts een procesraamwerk dat nog steeds zeer individueel en divers kan worden vormgegeven door de teams die het gebruiken. Dit argument lijkt plausibel en onderscheidt Large Scale Scrum (LeSS) van sommige andere schaalframeworks.
Illustratie: Zwoele Plek
Vergelijking: Grootschalige Scrum versus Scrum
LeSS bouwt voort op Scrum om het gebruik ervan in een bredere context te ondersteunen en om het op te schalen in grotere organisaties en voorbij het ene team. Er is dus geen sprake van of of. LeSS is de uitbreiding van SCRUM. Dus om LeSS te introduceren, heb je altijd SCRUM nodig. Het is zinvol om eerst SCRUM te introduceren en dan over te stappen op LeSS.
Vergelijking: Grootschalig Scrum versus Geschaald Agile Framework SAFe®
Hoewel LeSS steeds populairder wordt in bedrijven met grote softwareontwikkelingsteams, hebben andere geschaalde agile frameworks zoals Scrum of Scrums of Scrum @ Scale ook aan belang gewonnen. Een van de toonaangevende raamwerken is het Geschaald Agile Framework® (SAFe).
Er zijn veel overeenkomsten tussen Large Scale Scrum en het Scaled Agile Framework SAFe®. Beide beginnen bijvoorbeeld met het schalen van een Scrum team en het toepassen van principes zoals lean denken, continu verbeteren en klantgerichtheid.
3 Kernverschillen tussen Large Scale Scrum en Scaled Agile Framework SAFe®.
- Organisatie: LeSS richt zich op het vereenvoudigen van de organisatiestructuur door flexibel en aanpasbaar te blijven.
- Rollen: SAFe heeft extra rollen (sommigen zeggen daarom meer "overhead"), waaronder de Release Train Engineer (RTE), de Solution Train Engineer (STE) en de Epic Owners.
- Implementatie: Het Scaled Agile Framework SAFe® bevat processen, artefacten en organisatorische veranderingen die sommige organisaties misschien niet kunnen overnemen. Je moet dus altijd kijken welk framework bij jou en je organisatie past.
Voor een succesvolle introductie van Scrum op grote schaal
Succesvolle implementatie van Large Scale Scrum vereist het breken met aloude aannames en het veranderen van de bedrijfsstructuur – met alle explosieve mogelijkheden op "baasniveau" en "gezichtsverlies" die een overeenkomstige verandering met zich meebrengt.
De basis is daarom dat iedereen zich klaar verklaart voor deze verandering – zie ook de Model voor verandermanagement volgens Kotter of ons artikel over de Stappenplan voor Agile Transformatie.
Creëer een aantrekkelijke visie om naar – toe te werken en start veel veranderingsprojecten tegelijk, in de geest van experimenteren.
Als het oorspronkelijke doel is bereikt, is de verandering klaar en past de organisatie zich aan een nieuwe status-quo aan totdat de volgende verandering op handen is.
Deze klassieke benadering is vergelijkbaar met de sequentiële en "Aanpak Big Batch (zie Afbeelding) van softwareontwikkeling, waar veranderingen een uitzondering zijn, strikt beheerd door controleorganen.
In LeSS adopties is er geen veranderinitiatief, dus zijn er geen verandermanagers. In LeSS is verandering continu door experimenteren en verbeteren – de verandering is de status quo.
Wat zijn de stappen voor een succesvolle implementatie?
1. de teamcultuur verschuiven, aanpassen of veranderen
We raden aan om eerst met een Scrum-team te beginnen, totdat het team en de organisatie voldoende ervaring hebben opgedaan met de nieuwe, agile cultuur en de verantwoordelijke besluitvormers de volgende stap initiëren. Dit verkleint ook het risico op een verkeerde ontwikkeling.
2. de samenwerking binnen de teams verbeteren
Het geschaalde werk van meerdere teams aan één product vereist de introductie van agile werkwijzen. Vooral praktijken die het voor teams gemakkelijker maken om met elkaar af te stemmen zijn belangrijk. De eerste teams moeten nog veel experimenteren als pioniers voor de rest van de organisatie.
Als de teams echt losgekoppeld zijn van de rest van de organisatie, kunnen ze daarin navenant snel vooruitgang boeken. Dit kan sneller en met minder risico binnen een beheersbaar kader.
3. veranderingen in de bedrijfsstructuur
Verdere groei van de wendbare organisatie betekent herstructurering op alle niveaus. Uiterlijk nu moet de initiatiefnemer van de verandering het management erbij betrekken. Alle niveaus tussen teams en het topmanagement worden uitgedaagd – en de organisatiestructuur wordt erg slank. Dit is waarschijnlijk het meest "pijnlijke" deel van het proces, vooral voor het management.
4. verschuiving in bedrijfscultuur
Door het toepassen van de raamwerken Scrum en LeSS en de juiste agile praktijken in alle gebieden van de onderneming, ontstaat een organisatiebreed leren van de agile cultuur. Het proces komt nooit tot stilstand, omdat er geen optimale agile organisatie bestaat.
Een Agile overgang met Scrum, LeSS en LeSS Huge vereist een vooruitziende strategie. Deze moet daarom gepaard gaan met passend advies en training.
Als je nog op zoek bent naar een geschikt retro bord, kan ons artikel je helpen met het onderwerp: De beste retro boards in vergelijking.
