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.

Hoe 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.

Kijk 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 ondernemer. Is een van deze punten nog voor verbetering vatbaar? Mooi! Je hebt dan kans om meer op te leveren zonder extra complexiteit.

Development Team & 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.

Laten 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 (performing) en de Scrum Master is invisibly present. 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 outcome of is hij aan het zorgen dat de values doorleeft worden? Dan is daar nog winst te behalen. Scale in!

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.

Ga 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.

Is je product helder en toch zo groot dat je meerdere teams nodig hebt? Is je architectuur vereenvoudigd? Top, door naar stap 3!

Scaling stap 3 – Elimineer afhankelijkheden

Met een eenvoudige architectuur kun je bij een groot product nog steeds afhankelijkheden hebben. Afhankelijkheden met interfaces buiten je bedrijf, maar ook afhankelijkheden tussen een team dat een feature maakt voor een albumhoes en een team dat aan de slag gaat voor het opnieuw vormgeven van de playlist. Een albumhoes kan voorkomen in de playlist. Breng die afhankelijkheden in kaart!

Een gezamenlijke planning met teams en een bord met stories, features en afhankelijkheden kan daarbij helpen (een Program Board in SAFe). Als de door de teams naar voren gebrachte afhankelijkheden transparant aan de muur hangen, kun je deze aanpakken.

Achterhaal waar afhankelijkheden zitten, waarom die daar zitten en hoe je deze kunt elimineren. Hoe minder afhankelijkheden, hoe minder complexiteit, hoe minder overhead en hoe hoger de efficiëntie. Het is niet voor niets dat ik hier SAFe noem. Het Scaled Agile Framework is een enorm framework. Program Increment planning en een Program Board zijn goede onderdelen uit SAFe die je kunt gebruiken op weg naar een agile organisatie. Zie het SAFe framework dan ook vooral als een framework dat je kan helpen in een transformatie naar agile werken. Een volledig geïmplementeerd SAFe framework is juist niet het eindpunt…

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.

Heb 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: tailor!

Scaling stap 5 – Tailor

Agile werken is maatwerk, vooral omdat de wereld om ons heen steeds verandert. Mensen veranderen, techniek verandert, de markt verandert en je verbetert als organisatie. Wat eerst goed werkte, werkt nu misschien niet zo goed meer. Pas dus vooral je werkwijze aan aan de situatie, tailor!

Kies een specifiek framework of een mix van frameworks. Ieder framework heeft waarden en principes, die zijn er niet voor niets. Het Scrum framework kent de volgende waarden:

• Commitment
• Courage
• Focus
• Openness
• Respect

SAFe kent 9 principes en deze core values:

• Built-in Quality
• Transparancy
• Program Execution
• Alignment.

Deze principes en waarden vormen de basis voor alle processen en rollen die beschreven zijn, de achterliggende gedachte. Door die te begrijpen kun je aanpassingen doen in het framework en onderdelen samenvoegen of weglaten en nog steeds de waarden en principes in stand houden. Pas het aan zodat het past bij jouw organisatie!

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.

Als 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.