Large-Scale Scrum (LeSS) is more

LeSS

Vorig jaar kregen we 3 dagen Jurgen De Smet van Co-learning over de vloer om ons in te leiden in de wereld van LeSS. Wat volgde was een opeenvolging van inzichten, oefeningen, informatie, voorbeelden en workshops. Nu, één jaar na de opleiding, is het tijd om terug te blikken op de opleiding en de veranderingen die het teweeggebracht heeft.

LeSS bouwt verder op de agile ontwikkelmethodiek scrum. Terwijl scrum zich gaat focussen op het team, gaat LeSS dit breder gaan trekken naar een organisatie waar meerdere teams samen gaan werken. Het framework is opgesteld rond 10 principes die we hieronder voor jullie uit de doeken doen.

Queueing theory

De dikke Vandale vertaalt een queue als "file" of "rij". Een queue in LeSS is niet anders: het is een opeenvolging of rij van taken die in volgorde wordt afgewerkt. Het item dat bovenaan staat, wordt als eerste afgehandeld. De queueing theory beschrijft een aantal principies hoe we met deze rijen kunnen omgaan.

Er zijn 4 belangrijke punten omtrent de queueing theory in LeSS:

• Beperk het aantal queue's
• Visualiseer de overgebleven queue's
• Beperk variatie
• Beperk queue size

Beperk het aantal queue's

Meer queue's zorgt voor minder overzicht. Als verschillende teams aan 1 product werken, waarom zouden ze dan elk een aparte queue nodig hebben? Beperkt het aantal queue's door deze teams op 1 backlog te laten werken in plaats van 1 backlog per team.

Visualiseer de overgebleven queue's

De kracht van visualisatie wordt nog te veel onderschat. Door de queue's te visualiseren verhoogt de transparantie naar iedereen die op de hoogte wil blijven van het product. Wat wordt er op dit moment ontwikkeld en welke features mogen we op korte termijn verwachten,… zijn allemaal af te lezen uit een goed gevisualiseerde queue.

Beperk variatie

Deel de backlog op in verschillende stukken om de variatie te beperken: bovenaan vinden we een beperkte buffer van goed uitgewerkte items van ongeveer dezelfde grootorde die binnen afzienbare tijd zullen opgenomen en verwerkt zullen worden. Daaronder vinden we een lijst van grovere items die nog niet in detail zijn uitgewerkt en die dus nog verder verfijnd moeten worden. 

Naargelang de sprints en dus de backlogs vorderen, worden er refinement sessies georganiseerd, die de grovere items op de backlog zal verfijnen tot deze op het punt komen dat ze voldoende zijn uitgewerkt om in een sprint te worden opgenomen.

Daarnaast zorgen stabiele teams ook voor het beperken van variatie

Beperk queue size

Een andere queue-management techniek is het beperken van de queue size. Een lange lijst van in detail verfijnde stories heeft een aantal nadelen:

• Er moet tijd geïnvesteerd worden om de items te verfijnen. Hoe meer items in detail verfijnd zijn, hoe groter de kans dat de prioriteiten van de backlog verschuiven en bepaalde items pas veel later of helemaal niet meer ontwikkeld zullen worden. De geïnvesteerde tijd om die items te verduidelijken gaat dan gedeeltelijk of zelf volledig verloren.
• Een grote lijst aan verfijnde en opgesplitste items vermindert het overzicht
• Mensen vergeten details na verloop van tijd. Als er veel tijd zit tussen het verfijnen en ontwikkelen van de items, zullen de teams reeds veel van de context en details van de items verloren zijn. Dit brengt extra inwerktijd met zich mee voordat een item kan ontwikkeld worden.
   

Empirical Process control

3 kernwoorden horen bij empirical process control: inspect, adapt en transparancy. In korte cyclussen worden kleine werkbare deeltjes van het product gebouwd. Nadien inspecteren wat en hoe we deze deeltjes gebouwd hebben, passen aan waar nodig en gaan verder naar de volgende cyclus en dit alles op een transparante manier.

Systems thinking

In kleine groepen komen problemen sneller aan het licht en zijn ze eenvoudiger om te begrijpen. In grotere omgevingen is dit lastiger. Systems thinking is het zien van de connecties tussen verschillende situaties om beter te begrijpen hoe zaken zich ontwikkelen over tijd. Een manier om deze verbanden te vinden is het maken van een causal loop diagram:

Lean thinking

Lean thinking heeft veel raakvlakken met agile werken. Lean thinking rust op pilaren van respect voor mensen en continuous improvement met als doel value op te leveren op een zo kort mogelijke tijd met een zo hoog mogelijke kwaliteit

Lean kent 14 principes:

• Base management decisions on a long-term philosophy, even at the expense of short-term financial goals.
• Move toward flow; move to ever-smaller batch sizes and cycle times to deliver value fast & and to expose weakness and hidden problems.
• Use pull systems to avoid overproduction of WIP or inventory; decide as late as possible.
• Level the work---reduce variability and overburden to remove unevenness.
• Build a culture of stopping and fixing problems to ultimately build quality in; teach everyone to methodically study problems.
• Standardized tasks are the foundation for continuous improvement and employee empowerment.
• Use visual controls (visual management) to reveal problems—and to coordinate.
• Use only reliable thoroughly-tested technology that serves your people and process.
• Grow leaders from within who thoroughly understand the work, live the philosophy, and teach it to others.
• Develop exceptional people and teams who follow your company’s philosophy.
• Respect your extended network of partners by challenging them to grow and helping them improve.
• Go see for yourself at the real place work to thoroughly understand the situation and help.
• Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly.
• Become and sustain a learning organization through relentless reflection and kaizen.
   

Continuous improvement towards perfection

In LeSS zijn we continu op zoek naar perfectie. Vandaar dat we onze processen, gebruiken, gewoontes continu moeten bijsturen gezien de definitie van perfectie ook verandert en praktisch onhaalbaar is.

Customer centric

Een klein team organiseren op basis van klantgerichtheid is relatief eenvoudig en voor de hand liggend. Maar hoe meer teams, hoe belangrijker het wordt dat iedereen een bepaalde rol in het geheel speelt.

Dus in LeSS is de uitdaging: hoe ben je als groot bedrijf/team toch klantgericht? LeSS concentreert zich op volgende visie: Zonder tevreden klanten, is er geen bedrijf en hoe meer iedereen verbonden is en geeft om de uiteindelijke klant, hoe beter.

Aan de hand van “System modelling” werd bepaald wat voor DX-Solutions klantgericht zijn inhoud en hoe zich dit vertaalt in de praktijk.

Whole product focus

Klanten kopen geen onderdeel van het product, maar het hele product. Dit lijkt vanzelfsprekend, maar het is belangrijk om te onthouden. Het leidt tot een aantal belangrijke richtlijnen:

• Delen van software die niet in het volledige product zijn geïntegreerd, hebben nog geen waarde.
• Teams die 'hun steentje hebben bijgedragen' zijn pas klaar als het onderdeel is geïntegreerd.
• Wanneer er een keuze is om een teamoutput of het hele product te optimaliseren, kiezen we altijd voor het hele product.

In veel grote productontwikkelingsgroepen is het een van de moeilijkste onderdelen van Scrum om iedereen te laten focussen op het hele product in plaats van op hun individuele onderdelen/ taken.

Hou altijd een focus op het hele product, blijf iedereen eraan herinneren dat er geen waarde is in afzonderlijke delen of half werkende delen. Hierbij speelt de “Product Owner” een heel belangrijke rol. Het is zijn of haar taak de visie & strategie van het product steeds bij alle stakeholders duidelijk te maken.

More with LeSS

Het “More with LeSS”-principe vormt de kern van LeSS. Het is het besef dat de nadelen van de complexe organisatorische oplossingen die worden gebruikt voor complexe productontwikkeling vaak slechter zijn dan het probleem dat ze proberen op te lossen. Complexe productontwikkeling vereist geen complexe oplossingen. Het vereist een diep begrip van de essentie van de problemen, die vervolgens kan worden opgelost met eenvoudigere oplossingen.

We kregen de opdracht om a.d.h.v. vooraf gedane opdrachten m.b.t. “systems thinking” aan de slag te gaan met wat volgens DX-Solutions wat meer kan zijn door minder …

Volgens LeSS:

In empirical process control

More learning & adaptation, less prescription & following
More root-cause countermeasures, less quick fixes
More safety & transparency, less fear & opacity
More on principles, less on practices

In scaling

More system, less parts
More customer-feature teams, less roles, silos, overhead, handoff, scatter

In Agile values

More organisational agility & learning, less working the plan

In Lean thinking

More teaching, less telling
More value, less muri, muda, mura

In impact mapping & value-driven management

More outcomes, less output

Transparency

Zonder transparantie is het moeilijk om te sturen of aan te passen. 

Transparantie is ook sterk gerelateerd aan de Definition of Done. Het formeel definiëren van de betekenis van 'klaar' vermindert variabiliteit en de waarschijnlijkheid van ongedaan gemaakt werk en het ondubbelzinnig meten van de voortgang ('klaar' of 'niet gedaan') vergroot de transparantie.

Het hebben van een onvolmaakte definitie van klaar houdt in dat er ongedaan gemaakt werk in uw systeem zit. Dit Undone Work veroorzaakt ook een gebrek aan transparantie. Risico's zijn erin verborgen. Als prestatietests bijvoorbeeld niet worden gevolgd, vertraagt dit het risico van een niet-werkend systeem tot bijna bij het loslaten - wanneer het het meest pijn doet.

Large-Scale Scrum is Scrum

Large-Scale scrum, is net zoals gewone Scrum, een raamwerk voor ontwikkeling waarin de functionaliteiten moeten worden ontwikkeld door de verschillende teams, iteratie per iteratie. Het weerspiegelt de “lean” pijler van continue verbetering. Het is een verzameling suggesties voor het inspecteren en aanpassen van het product en processen wanneer er veel teams zijn, minimaal twee teams en maximaal groepen van 500 of 1000 personen. 

Wat betekent dit voor Dx-Solutions

Om onze groeiambities waar te maken, zijn we ervan overtuigd dat onze organisatie een flexibele structuur nodig heeft die deze groei ondersteunt en die de teams voldoende autonomie geeft om zelf beslissingen te kunnen nemen. Meer mensen betekent meer communicatielijnen en een grotere kans op miscommunicatie. Om te anticiperen op deze uitdagingen, zijn we met DX-Solutions verschillende frameworks aan het bekijken die ons kunnen helpen een efficiënte, klantvriendelijke en aangename manier van werken te bewerkstelligen.

LeSS wordt vooral toegepast in product georiënteerde omgevingen terwijl DX-Solutions project georiënteerd is. Dit maakt het niet evident om volledig LeSS te implementeren doch hoeft dit ons niet tegen te houden om enkele van de principes toe te passen binnen onze werking.

Zo hebben we onze backlogs vermindert naar 1 backlog per team in plaats van 1 backlog per project (queueing theory). Daarbovenop hebben we onze backlog opgesplitst in 3 delen waarbij het eerste deel (Top level) de meest uitgewerkte en onmiddellijk implementeerbare taken en het laatste deel de nog zeer high level en lager geprioriteerde items bevat die nog niet in de eerstkomende maanden dienen ontwikkeld te worden. Naargelang items worden opgeleverd, zullen nieuwe items naar de top level schuiven die dan verder uitgewerkt en gedetailleerd worden. Dit systeem helpt ons om de juiste prioriteiten te leggen en helpt ons te focussen op de hoogst geprioriteerde zaken zodat geen tijd verloren gaat aan items die later of helemaal niet meer gaan geïmplementeerd worden. De taken zelf trachten we steeds zo klein en eenvoudig mogelijk te houden, die we steeds zo snel mogelijk trachten op te leveren.

Om deze conclusie af te ronden kunnen we spreken over een heel interessante opleiding die ons veel skills, tools en tips & tricks heeft bijgeleerd en onze organisatie nieuwe stappen heeft laten zetten om zo onze groeiambities waar te maken.