Agile Informatie Technologie

en hoe Scrum toe te passen

Grootschalig Scrum

Zodra meerdere Scrum teams moeten samenwerken aan een gemeenschappelijk product ontstaat de noodzaak tot coördinatie. Het is een kwestie van vertrouwen in de teams, de Scrum masters en de product owners of daarvoor extra rollen moeten worden gecreëerd of bestaande gehandhaafd.


Het SAFe framework

SAFe framework
klik op het plaatje voor een grote afbeelding

Zie dit webinar met Dean Leffingwell and Drew Jemilo voor een toelichting. Het Scaled Agile Framework is een product dat moet worden geimplementeerd. In feite wordt de organisatie opnieuw ingericht. Dat kan een langduring proces zijn dat goed moet worden begeleid door gecertificeerde consultants. Agile puristen hebben kritiek op deze aanpak. Zie de video "Is SAFe Evil?" van Lars Roost & Henrik Kniberg voor een nuchtere kijk op dit onderwerp.

Wat opvalt is dat SAFe aansluit op wat in staande organisatie gebruikelijk is: budgetrondes op portfolio niveau, prioriteitstelling op programma niveau en tenslotte de backlogs voor de teams. Managers zorgen voor de coördinatie tussen deze werelden.

Het LeSS framework

Less framework
klik op het plaatje voor een grote afbeelding

Large-scale Scrum as Scrum is een set van aanvullende regels en een verzameling van tips die hun waarde hebben bewezen in grote multi-team, multisite, en offshore agile ontwikkel initiativen. Deze tips zijn experimenten om te proberen in de context van het klassieke Scrum framework.

In tegenstelling tot SAFe kent LeSS maar één backlog per product waarbij dit begrip ruim moet worden opgevat. Dus, voor een bank, één backlog voor alle spaarproducten. LeSS drijft op het vertrouwen dat de teams die aan een product werken zelf voor de ondelinge afstemming zorgen. Hiervoor zijn geen andere rollen nodig dan die van team, Scrum master, product owner en bij LeSS huge, de area product owner. De rol van het management bestaat bij LeSS uit:

Managers’ role is to improve the product development system by practicing Go See, encouraging Stop and Fix, and “experiments over conformance”.

Ook interessant om te lezen is deze blog: Managers doen precies waarvoor zij niet zijn aangenomen.

De Spotify ontwikkelcultuur

Spotify engineering culture part 1
klik op het plaatje voor een grote afbeelding

Henrik Kniberg geeft in twee video's inzicht in de ontwikkelcultuur bij Spotify. In de eerste video beschrijft hij de uitdagingen waar Spotify voor staat en hoe de ontwikkelcultuur hier op inspeelt. De tweede video start met de wijze waarop Spotify omgaat met fouten. Hier geen extra controlemaatregelen en rapportageverplichtingen. Wel een fout-vriendelijke omgeving waar snel geleerd wordt maar ook de impact van fouten zijn geminimaliseerd. Dit is geen framework maar eerder een bron voor inspiratie. Zie ook dit artikel van Jasper Verdooren.

Ten slotte

SAFe en LeSS zijn beide bij Nokia ontstaan. Ari Tikka constateert in deze vergelijking dat LeSS het lerend vermogen van de organisatie veel beter ondersteunt dan SAFe. Uiteindelijk is het een strategische keuze waarvoor de onderneming gaat. Kiezen voor LeSS is wel ingrijpender en vereist meer moed.

Peter Stevens heeft in dit artikel SAFe, DAD en LeSS vergeleken. LeSS komt er het beste uit. Zie ook dit artikel in het Nederlandstalige Managers-online.

Dit artikel met de titel "Frameworks for Scaling Agility; A Cautionary Tale" waarschuwt voor het feit dat nog weinig onderzoek is gedaan naar de effectiviteit van genoemde frameworks. Wel blijkt het volgende:

The characteristics shared by organisations that perceive themselves to have been successful in this regard are:
  • An understanding that the biggest challenges are likely to be around people, perceptions and concepts rather than technical
  • A willingness to iteratively experiment and to learn
  • A culture that engages and empowers both employees and customers to be part of the experiment and learn cycle
  • Transparency in everything, including things which don’t work
  • Patience; being willing to start small, measure and build on small improvements in customer value, and employee satisfaction

Wanneer meerdere Scrum teams moeten samenwerken ontstaat de behoefte aan coördinatie. De Scrum guide gaat hier niet op in maar beperkt zich tot één team. Door de jaren zijn een aantal frameworks ontstaan die de coördinatie tussen teams faciliteren. Geen van die frameworks geven een blauwdruk die alleen nog maar moet worden uitgerold! Iedere organisatie is anders. Adoptie betekent een proces dat vele experimenten vereist en dat maanden tot jaren kan duren voordat een werkend model ontstaat waarin tientallen teams optimaal samenwerken. Mijn advies is dan ook klein te beginnen en organisch te groeien op basis van vrijwilligheid.

SAFe en LeSS zijn elkaars tegenpolen. SAFe vertrouwt niet op het coördinerend vermogen van de teams en de product owners maar creëert een aantal management rollen. LeSS daarentegen heeft dat vertrouwen wel en kan toe met een eenvoudige organisatiestructuur. De andere frameworks, zoals Nexus, zitten hier tussenin.

Het ligt voor de hand te leren van andere organisaties die dit proces al grotendeels hebben doorgemaakt. Spotify is hier een goed voorbeeld van. De auteur geeft zelf aan dat het niet aan te raden is het model to kopiëren. Het is door vallen en opstaan ontstaan in de Spotify organisatie. Het zou toeval zijn als het zonder meer past op een andere organisatie. Gebruik dit model als inspiratiebron om zelf te experimenteren. Beter kan de hulp van experts worden ingeroepen die een framework als SAFe of LeSS helpen adopteren.

© 2006-2017 | Created by Erik Verheul