AGILE WERKEN

Het Agile werken in scrumteams heeft de afgelopen jaren een grote vlucht genomen. In vrijwel iedere organisatie ontstaan kleinschalige teams die los van de bestaande processen opereren en in korte iteraties snel successen laten zien.

Het grote voordeel van Agile werken is dat gedurende het hele ontwikkelproces voor iedereen transparant is wat geleverd wordt door wie. Daarnaast biedt Agile werken direct feedback (Plan, Do, Check, Adjust) waardoor je echt kunt ontwikkelen wat de klant wil. Het doel van Agile werken is waarde te creëren door een snellere time2market met meer kwaliteit, meer engagement binnen de organisatie en een hogere productiviteit.

In tegenstelling tot de watervalmethode staan bij de scrummethode de hoeveel tijd en het budget vast, maar de scope (uitkomst) is variabel.

Scaling Agile

Een logische stap is om met meer teams op een Agile manier te gaan werken. Dit vindt vaak eerst plaats binnen de IT-organisatie, maar in de afgelopen jaren zijn de Agile principes ook goed toegepast binnen andere afdelingen. Afhankelijk van de organisatieomvang ontstaat bij een groeiend aantal Agile teams vaak ook de behoefte of noodzaak de werkzaamheden tussen deze Agile teams te coördineren. Dit hele proces noemen we ‘Scaling Agile’: het op grote schaal toepassen van Agile principes in een organisatie.

Kun je de Agile principes op grote schaal – met meer dan een paar teams –  toepassen?

 

Agile uitgangspunten

Het Agile manifesto gaat uit van waarde creatie door de volgende uitgangspunten te waarderen:

  • Individuen en interacties zijn belangrijker dan processen en tools
  • Werkende software is belangrijk dan uitgebreide documentatie
  • Klant samenwerking is belangrijker dat contract onderhandelingen
  • Reageren op wijzigingen is belangrijker dan het volgen van een plan

Als je onderstaande principes toepast op meerdere teams dan blijkt dat het Agile Manifesto ook kan werken voor meerdere teams.

  1. Onze hoogste prioriteit is om de klant tevreden te stellen door vroege en continue aflevering van waardevolle software
  2. Welkom veranderende eisen, zelfs laat in de ontwikkeling. Agile processen verwelkomen verandering vanwege concurrentievoordeel van de klanten
  3. Lever regelmatig werkende software, van een paar weken, met een voorkeur voor een kortere tijdschaal
  4. Mensen uit het bedrijfsleven en ontwikkelaars moeten dagelijks samen te werken gedurende het project
  5. Bouw je project rondom gemotiveerde individuen. Geef ze de omgeving en ondersteuning die ze nodig hebben en vertrouw hen om de klus te klaren
  6. De meest efficiënte en effectieve methode om informatie over te brengen binnen een development team is face-to-face gesprek
  7. Werkende software is de belangrijkste maatstaf voor de vooruitgang.
  8. Agile processen bevorderen van duurzame ontwikkeling. De sponsors, ontwikkelaars en gebruikers moeten in staat zijn om een constant te houdentempo voor onbepaalde tijd.
  1. Continue aandacht voor technische uitmuntendheid en een goed ontwerp verhoogt de wendbaarheid.
  2. Eenvoud; -the kunst van het maximaliseren van de hoeveelheid werk niet klaar- is essentieel.
  3. De beste architecturen, requirements en ontwerpen komen uit zelf- organiserende teams.
  4. Op gezette tijden reflecteert het team hoe ze effectiever worden, en past het gedrag dienovereenkomstig aan.

De scrummethodiek, die door veel bedrijven wordt gebruikt om te Agile te werken, biedt echter toch minder houvast zodra verschillende teams naast elkaar werken aan hetzelfde eindproduct. Door een gebrek aan overkoepelende coördinatie en overleg, ontstaat er al snel frustratie en inefficiëntie.

 

Frameworks voor Scaling Agile

Bedrijven moeten dus op zoek naar een framework om Agile op te schalen. Van dit soort frameworks lijkt er iedere dag weer één bij te komen. Een aanpak zoals die van Spotify, initieel niet eens bedoeld als model, gaat door de grote media-aandacht een eigen leven leiden. Het is goed om de voor- en nadelen van de verschillende modellen te kennen om zo tot een basis framework keuze voor je bedrijf te komen en die op maat te maken.

De verschillende frameworks die we kennen en waarderen zijn:

  1. Spotify model
  2. LeSS
  3. Scrum of Scrums
  4. SAFe

Schermafbeelding 2016-07-30 om 21.44.50

 

Het Spotify model is vooral van toepassing voor organisaties met een cultuur waarin initiatief en zelf verantwoordelijkheid nemen al is ingebed. Daarnaast is de markt waarin het bedrijf zich bevindt sterk competitief en dient het bedrijf direct te kunnen reageren. Verder moet de architectuur al dermate ver ontkoppeld zijn dat er sprake kan zijn van autonome releases.

 

Het Scrum of Scrums model is handig als de organisatie al bekend is met de scrummethodiek. Scrum of Scrums is dan een logische vervolgstap. Het aantal scrumteams dat werkt aan een grotere, gezamenlijke visie/product is niet al te groot (maximaal negen teams met onderlinge afhankelijkheid). Wanneer sprake is van meer dan negen teams die onderling moeten afstemmen, wordt de Scrum of Scrums opgesplitst en wordt gewerkt met een scrum-of-scrums-of-scrums voor coördinatie tussen de Scrum of Scrums.

LeSS is handig als er veel flexibiliteit gedurende de ontwikkeling is bij grote projecten. LeSS streeft namelijk een veel frequentere communicatie met afvaardigingen van de verschillende teams na dan bijvoorbeeld het SAFe framework.

SAFe is nadrukkelijk ontwikkeld als antwoord op de problematiek van zeer grote organisaties bij het inzetten van agile en minder geschikt voor kleinere organisaties met een beperkt aantal teams.

Een van de belangrijkste zichtbare verschillen is dat SAFe echt gericht is op periodiek face-to-face overleg met alle leden van alle teams te faciliteren, terwijl LeSS een veel frequentere communicatie met afvaardigingen van de verschillende teams nastreeft. LeSS zou daardoor misschien iets beter passen in een omgeving waar veel flexibiliteit (en agility) nodig is en SAFe iets beter bij grotere traditionele organisaties met meer legacy systemen die langzaam veranderen en meer afstemming noodzakelijk maken.

Door de kennis van deze modellen en de voor- en nadelen kiezen we veelal een basis framework waarna we de tools en processen ‘op maat’ organiseren.