terug naar overzicht

17/06/19

Insight insight

Agile Scaling

Maarten Hoppen

+31 6 20 62 50 92


17/06/19

Scaling & SAFe: efficiënter Agile werken met meerdere teams

Na scrum lijkt scaling (en specifiek SAFe) de volgende wave te worden in Agile werken. Niet voor niets, want veel organisaties ondervinden moeilijkheden bij het toepassen van agile werken. Met meerdere teams aan één product werken en continu in kleine stukjes opleveren. Ga er maar aan staan in een grote organisatie! Dat vereist nogal wat, van management, IT-architectuur en medewerkers. Een scaling framework kan dan een prettige oplossing zijn.rnrnHoe je de weg naar scaling kunt bewandelen, zonder je te verliezen in frameworks en methodes, leg ik je uit met dit stappenplan.

Scaling stap 1 – Scale in

Scaling ga je toepassen zodra je het werk op een product niet meer af kunt met één team. Je hebt meer mensen nodig om de klus te klaren omdat je sneller wil leveren, of meer wil leveren richting je klant. Het inzetten van extra teams lijkt een eenvoudige oplossing, maar brengt extra complexiteit met zich mee door afstemming tussen de teams. Complexiteit zorgt op haar beurt weer voor minder efficiëntie.rnrnKijk daarom niet naar buiten, naar meer teams, maar kijk naar binnen, naar je eigen team. Wat kan een team nog verbeteren? Is de Product Owner écht een Product Owner en niet een afgevaardigde of iemand die alleen de User Stories schrijft? Een Product Owner moet mandaat hebben, (gedelegeerd) keuzes mogen maken zonder teruggefloten te worden. Ook moet zij de visie op het product kunnen overdragen én de mentaliteit hebben van een echte onderxnemer. Is een van deze punten nog voor verbetering vatbaar? Mooi! Je hebt dan kans om meer op te leveren zonder extra complexiteit.

Development Team u0026 Scrum Master

Maar er is nog meer, de Product Owner staat niet alleen, er is ook nog een Development Team. Is de kwaliteit van het product op orde, of is er ‘achterstallig onderhoud’ dat keer op keer voor vertraging zorgt? Kan het team iedere keer snel software naar productie brengen? Is wat opgeleverd wordt ook echt af? Vraag het team om direct na een sprint het opgeleverde in productie te zetten. Kan dit niet, dan is er nog werk te doen om Done ook echt DONE te laten zijn.rnrnLaten we de Scrum Master hier niet vergeten. Hoe zichtbaar is die? Helemaal niet? Dan is er de kans dat het team scrum echt begrijpt. Ze werken perfect samen (u003cemu003eperformingu003c/emu003e) en de Scrum Master is u003cemu003einvisibly presentu003c/emu003e. Besteedt de Scrum Master nog veel tijd aan het onder de aandacht brengen van de theorie van scrum bij de development-teamleden? Wordt er nog gestuurd op output in plaats van u003cemu003eoutcomeu003c/emu003e of is hij aan het zorgen dat de u003cemu003evaluesu003c/emu003e doorleeft worden? Dan is daar nog winst te behalen. u003cemu003eScale inu003c/emu003e!

Scaling stap 2 – Eén product

Wat is je product? Een basale, maar moeilijke vraag. Een product moet in ieder geval iets zijn waar de klant wat aan heeft. Het liefst is een product zo klein en onafhankelijk mogelijk. Want hoe kleiner en onafhankelijker het product, des te makkelijker kun je het maken met één team. Dat beperkt weer de complexiteit.rnrnGa dus eens samenzitten met product managers, architecten en developers. Want definiëren wat een product is is één. Een product zo klein mogelijk maken, daar kunnen architecten en developers juist bij helpen. De architectuur binnen een bedrijf is in jaren tijd soms enorm gegroeid en complex geworden. Vereenvoudigen is hier de boodschap. Dat is een lastige opgave en doet beroep op de creativiteit van je architecten en developers. Architectuur veranderen kost tijd, maar het resultaat loont. Eenvoudige architectuur is beter uit te leggen aan nieuwe medewerkers, beter schaalbaar en onafhankelijker.rnrnIs je product helder en toch zo groot dat je meerdere teams nodig hebt? Is je architectuur vereenvoudigd? Top, door naar stap 3!

Scaling stap 4 – Kies een framework

Het SAFe framework is een van de vele. Less, Nexus en ‘het Spotify model’ zijn enkele anderen die worden gebruikt. Kies het framework dat past bij je organisatie. Is er behoefte aan voorspelbaarheid, heb je te maken met een grote organisatie en verandert de organisatie of de markt niet iedere maand van koers? Dan is SAFe een goede keuze.rnrnHeb je meer flexibiliteit nodig en is aansluiten op leveranciers en portfoliomanagement minder van belang, kies dan voor Less of Nexus. Wil je handvatten hoe je je organisatie moet inrichten buiten het scrum-team om, kijk dan hoe Spotify dit heeft aangepakt. Niets weerhoudt je ervan om een mengvorm van frameworks te kiezen. Dat brengt ons bij de volgende stap: u003cemu003etailoru003c/emu003e!

Scaling stap 6 – Repeat!

Ga weer terug naar stap 1, of stap 4, of 2, of… Blijf continu verbeteren! Een transformatie is nooit af, we blijven aanpassen en verbeteren. Met een getailored framework op basis van één product en een eenvoudige architectuur met meerdere teams ben je er niet. Je bent er nooit.rnrnAls je bij stap 6 bent, kijk dan eens naar de producten, kunnen ze nog kleiner of anders. Bestudeer de afhankelijkheden, zijn die er nog, kan dat anders? De architectuur, is die ondertussen gegroeid en is dat de goede kant op gegaan? Het framework, past dat nog bij de situatie, of moet het aangepast worden? Of kun je zonder? Tailor.

Delen