Beweeglijk
Dit is de Nederlandse vertaling van het Engelse ‘Agile’. De Engelse omschrijving vind ik in dit geval mooier; ‘able to move quickly and easily’. Verder geeft het woordenboek nog aan dat het zelfstandig naamwoord ‘agility’ kan worden vertaald door beweeglijkheid. De term Scrum komt uit het rugby en er is eigenlijk geen goede Nederlandse vertaling voor
Scrum en Agile worden vaak in een adem genoemd. Agile is concept. Scrum is een aanpak volgens het Agile concept. Bij TJIP hebben wij er voor gekozen om nieuwe software zo veel mogelijk Scrum te ontwikkelen. Scrum is op zich helemaal niks nieuws, al in 1984 werd de aanpak gebruikt bij Toyota en sinds 1995 is het geformaliseerd. Vele grote bedrijven, zoals Apple en Microsoft hanteren Scrum om software te ontwikkelen. De laatste paar jaar komt er steeds meer aandacht voor.
Voordelen voor de klant
Scrum biedt ten opzichte van andere manieren van software ontwikkeling een aantal voordelen. Omdat experts dit veel beter onder woorden kunnen brengen dan ik, maak ik maar even gebruik van de zeer bekende copy/paste functionaliteit. De belangrijkste voordelen zijn:
- Snel kunnen inspelen op veranderende wensen, eisen of omgeving
- Veel betere samenwerking met de klant, je bent gezamenlijk verantwoordelijk voor het eindresultaat
- Altijd werkende software
Het vertrekpunt van een project is, net als meestal, een goede business case en een visie. Je gaat eerst bedenken “wat” je wilt hebben en “waarom”. Daarna bedenk je het “hoe”. Vervolgens wordt er gewerkt in korte periodes van 1 tot 4 weken. Deze periodes worden sprints genoemd, en zijn eigenlijk een serie miniprojectjes. Na iedere sprint wordt er werkende software opgeleverd en dat is dan een deel van de eindoplossing. De belangrijkste zaken, met de hoogste prioriteit worden als eerste opgepakt. Dus sneller, doelgerichter en hoge kwaliteit.
Nieuw, nieuw, nieuw
De keuze voor Scrum is nieuw voor TJIP en ook zeker voor mij. Gelukkig hebben wij een uitstekende Scrum coach (Gertjan Oude Vrielink) gevonden die zowel de afdeling operations als sales & marketing op allerlei vlakken helpt en ondersteund. In korte workshops gaan we steeds dieper op de materie in en kunnen we het goed verankeren in onze interne processen. Bezwaren tegen Scrum zijn er ook genoeg. De meeste vallen denk ik in de categorie onbekend maakt onbemind. Wij geloven in ieder geval in de aanpak en zien na een paar maanden al de zeer positieve effecten, zowel intern als extern.
Ik zie er naar uit om in mijn volgende innovatie project zoveel mogelijk gebruik te maken van Agile en Scrum. Wil je een keertje een leuk boekje lezen over Scrum dan kan ik “De kracht van Scrum” aanbevelen (schrijvers: Rini van Solingen en Eelco Rustenburg). Leest als een roman, lekker snel en makkelijk en geeft je een goed beeld van de mogelijkheden.
Ik hoor ook graag jullie (eerste) ervaringen met Agile en Scrum.

Leuk stukje. Wij hebben ook goede ervaringen met scrum. Werkt uitstekend in innovatie projecten.
Zeker een leuk artikel. En met Henk ben ik het ook zeker eens. Scrum werkt prima in innovatieve projecten waar nieuwbouw centraal staat. In onderhoudstrajecten vind ik dat de methode zich een stuk minder goed leent aangezien daar een stuk minder dynamiek gewenst is en lange termijn visie en planning centraal staan.
Leuk artikel Martijn! Agree met Thijn dat bij onderhoud ook een blik ruimer dan de korte termijn gewenst is.
Ook agile softwareontwikkeling leidt uiteindelijk tot onderhoud. Het doel van incrementele agile softwareontwikkeling is om werkende software zo snel mogelijk uit te kunnen leveren aan de klant en zorgen dat deze er mee aan de slag gaat. Hiermee ontstaan tijdige feedback loops. Op een bepaald moment, wanneer de klant op de software vertrouwt om hun business te ondersteunen, gaat het team over van ontwikkeling naar onderhoud. Maar er is geen reden waarom teams hun werkwijze fundamenteel zouden moeten wijzigen eenmaal in dit stadium aanbeland.
Agile methodieken zijn ontworpen om kleine teams te helpen om te gaan met verandering, onzekerheid en het snel opleveren van software. Deze eigenschappen zijn minstens zo belangrijk in de onderhoudsfase.
Echter voor teams die zich de aanpak in de ontwikkelfase niet eigen gemaakt hebben, is er een extra uitdaging in de onderhoudsfase. Er wordt een groter beroep gedaan op reactievermogen en flexibiliteit. Niets beperkt ons om releases, zoals in de ontwikkelfase, te plannen voor een ‘pool’ van onderhoudswerk. Uiteraard laten niet alle issues zich keurig verzamelen en inplannen. En in een slecht geval blijven bugs over een langere periode opduiken. Hoe gaan we hier mee om, anders dan de oorzaken eens goed onder de loep te nemen?
De mate waarin teams slagen zich een aanpak als Scrum eigen te maken en het proces goed in te richten, draagt bij aan de nodige mythen rondom de aanpak. Dit neemt niet weg dat startende teams voor een uitdaging staan in onderhoudstrajecten, waar issues soms bijna dagelijks kunnen optreden. Het scrum team moet, ook in een onderhoudsfase, steeds aan de hoogste prio problemen werken. Het sprintplan wordt helaas voortdurend onder druk gezet (met al of niet echte!) showstoppers, met als gevolg dat taken toegevoegd worden midden in een sprint.
Een paar korte tips.
1) Zorg voor een korte sprint. Hiermee zet je de inhoud van de sprint minder onder druk.
2) Neem meer buffertijd bij het plannen van de sprint – een geëscaleerde issue zou zo maar geplande issues kunnen herroepen. Door bijvoorbeeld 20% buffertijd op te nemen, kun je showstoppers afhandelen zonder impact op het sprintplan. Als er zich geen showstoppers voordoen, gebruik je de begrootte tijd aan extra (high prio) items uit de buffer met issues.
3) Bewaak je kwaliteit en leg goede nadruk op agile testwerk voor oplevering.
4) Structureer het team zodat sommige teamleden zorgen voor 2de lijns support, terwijl de rest werkt aan de issues in de backlog.
5) Zorg voor voldoende overzicht i.p.v. het strikt werken aan een wachtrij. Kijk naar technische en operationele afhankelijkheden en naar beperkingen en risico’s.
6) Kijk naar het Scrum framework en tailor het naar onderhoudsbehoeften. Hoe zijn retrospective, daily scrum, planning, demo het beste in te richten? Scrum is geen keuzemenu, maar je moet het wel zinvol tailoren!
7) Als je met bovenstaande geen oplossing kunt vinden, kijk dan ook eens naar Scrum-ban. Het is een combinatie van Scrum en Kanban. Zie http://leansoftwareengineering.com/ksse/scrum-ban/ voor leuk artikel. De mindset en het analyseren van de bron van je problemen is echter belangrijker dan welke tools of methode je gebruikt!!