Lean is een terminologie en een manier van werken waar sommige organisaties jaren geleden al mee begonnen zijn. Bij lean gaat het vooral om efficiënt en effectief werken met zo min mogelijk verspilling (waste). Een optimaal inzichtelijke proces-flow (kanban), waarbij we continu proberen te verbeteren (kaizen). Dat verbeteren kun je doen door te meten en de statistische gegevens te gebruiken voor het realiseren van zo min mogelijk afwijkingen (six sigma). Bij lean staan de klant en de waarde die we opleveren aan de klant centraal.

Snel en flexibel

Later kwam de agile-manier van werken opzetten, waarbij veel elementen uit lean worden gebruikt. Agile richt zich vooral op snel en flexibel resultaten opleveren. Het gaat hier om het ontwikkelen of veranderen van een product of dienst waarbij we kortcyclisch (iteratief) reageren op feedback van de klant. Hierdoor zijn we wendbaar (agile) en creëren we iets wat de klant ook echt nodig heeft in plaats van dat we blijven doen wat we initieel hadden afgesproken. Het voortschrijdende inzicht en de directe reactie hierop zorgen in eerste instantie voor een minimaal levensvatbaar product (MVP – minimum viable product). Dat MVP bouwen we verder uit in volgende iteraties (sprints) die telkens een nieuw increment opleveren. De bekendste incrementele en iteratieve agilewerkwijze is scrum.
Scrum is gericht op zelfsturende teams die met hun meewerkende teamleider, de scrum master, snel kunnen reageren op feedback. Alle nieuwe of veranderende eisen en wensen worden toegevoegd aan een werkvoorraad (product backlog). Degene die hierbij zorgt voor de juiste prioriteiten en het managen van de stakeholders is de product owner. De items op de product backlog zien we het liefst als stories, waarbij niet alleen duidelijk is wat er moet worden gemaakt en voor wie, maar vooral ook waarom (value).

Afspraken maken en richting geven

Steeds meer organisaties zijn begonnen met agile werken en willen nu doorgroeien. Opschalen naar meerdere scrum-teams en daarbij ook de lijnorganisatie betrekken bij het continue kortcyclische proces. Daarnaast is ook buiten de IT- organisatie steeds meer interesse in lean-agile werken en dat is zeker goed mogelijk. Om samenwerking over zelfsturende agileteams heen te organiseren zijn afspraken nodig en moet er richting worden gegeven. Verschillende aspecten zijn daarbij relevant, het invullen van strategische doelen, klantwaarde leveren, problemen oplossen of wet- en regelgeving implementeren.
Dit is waar lean en agile elkaar vinden: efficiënt en effectief waarde leveren op een wendbare manier door producten en diensten te leveren zoals de klant ze nodig heeft. En daarna ook nog op een goede manier te ondersteunen vanuit servicegerichte teams.
Een populair raamwerk voor het combineren van lean- en agile-methoden op operationeel, tactisch en strategisch niveau is SAFe®(Scaled Agile Framework). SAFe® implementeren is een flinke transitie en is niet geschikt voor elke organisatie. Bovendien richt het framework zich nog heel sterk op IT. Minder uitgebreide raamwerken zijn Scrum@Scale, Nexus, LeSS (large scaled scrum) of DevOps (een combinatie van agile development en operational service management). In projecten wordt agile gewerkt in combinatie met Prince2 of volgens DSDM agile-projectmanagement.

Inzicht in wat er speelt

Een van de voordelen van deze manier van werken en het gebruik van deze methoden, al dan niet gecombineerd in een overkoepelend raamwerk, is dat dezelfde terminologie gebruikt wordt. Het grootste voordeel is echter vooral dat inzicht ontstaat in wat er speelt in binnen de organisatie en het ontdekken waar de prioriteiten liggen.
Omdat er in teams wordt gewerkt is een goede communicatie onontbeerlijk. Deze communicatie verloopt zeer open, transparant en zoveel mogelijk face-to-face. Visualisatie op scrum- of kanban-borden die dagelijks wordt besproken in een 15 minuten durende daily stand-up geeft inzicht in status en voortgang.
Reviews zorgen voor de betrokkenheid van de stakeholders en geeft ze de gelegenheid om prioriteiten te veranderen en nieuwe ideeën in te brengen door middel van feedback. Retrospectives geven de teams de gelegenheid om geleerde lessen in de volgende iteratie (scrum-sprint) op te pakken en zodoende continu te verbeteren.

Goede invulling van rollen

Zijn er dan geen nadelen? Uiteraard valt een succesvolle agilemanier van werken samen met een goede invulling van rollen en verantwoordelijkheden in de processen. Bovendien moet de cultuur van de organisatie matchen met deze lean-agilewerkwijze. Als er geen consequenties zijn verbonden aan het al dan niet meedoen in deze werkwijze wordt het heel lastig om te slagen. Een goede product owner moet bijvoorbeeld heel sterk in zijn rol staan, verstand hebben van de business, de stakeholders goed managen en niet verzanden in details. Zelfsturende teams zijn ook niet altijd een vanzelfsprekendheid en wellicht is goede externe coaching iets waar je niet zonder kunt. In elk geval kost de agile-verandering tijd en geld en dat is iets waar organisaties en medewerkers in moeten investeren.



Een vraag die altijd wel wordt gesteld tijdens de trainingen die ik geef, is of er ook zaken zijn die je absoluut niet agile moet aanpakken. Ik antwoord dan altijd dat het geen kwestie is van wel of niet agile, maar eerder van meer of minder agile. Als je veel eisen en wensen hebt waarbij je van tevoren al weet dat deze een absolute must zijn, dan is het lastig om daarin flexibel te zijn. Vaak moet je dan op hoofdlijnen wat traditioneler denken en dan zit de flexibiliteit vooral in de details. Hoe meer er ‘moet’ hoe minder agile. En daarbij moet je altijd bedenken dat agile werkt bij veranderen, verbeteren of vernieuwen en niet bij business as usual in het operationele proces.



Van reactief naar proactief

Wat bij agile werken vooral belangrijk is, is een verschuiving van reactief naar proactief en van grote naar kleine stappen maken. Controllers, auditors en testers zijn van oudsher gewend om pas achteraf te beoordelen of iets volgens de afgesproken regels of requirements is opgeleverd. Bij agile maken we korte iteraties om vervolgens met de gevraagde feedback te verbeteren of bij te sturen. Dan helpt het uiteraard niet als aan het eind van een aantal iteraties iets wordt afgekeurd door een andere (derde) partij. Ofwel, testers, controllers en auditors moeten van meet af aan in het proces worden betrokken en hun expertise moet voor feedback zorgen die in het iteratieve proces wordt meegenomen. De consequentie hiervan is dat het een repeterende taak wordt om telkens weer een stukje van de puzzel te beoordelen en elke verandering opnieuw te toetsen. Een andere manier van werken! Het beoordelen en geven van feedback zal meer on-site moeten plaatsvinden en minder via desk research. Wat hierbij belangrijk wordt zijn werkwijze en de tools die kortcyclisch beoordelen mogelijk maken. Een voorbeeld hiervan zijn geautomatiseerde softwaretests die worden vastgelegd in een voor personen leesbare vorm. Op deze manier kan steeds worden beoordeeld of de juiste functionaliteit wordt getoetst. We noemen dit test-driven development (TDD). Daarnaast geldt dat alle wijzigingen gedurende het agile-traject nauwkeurig moeten worden gelogd in versiebeheersystemen. Dat geldt niet alleen voor software maar ook voor documentatie, testscenario’s en bijbehorende data. Een bron van informatie, historie en uitstekend geschikt voor controle.



Onomkeerbaar

De transitie van organisaties naar lean-agile werken is onomkeerbaar en gelukkig levert het de waarde op die organisaties en hun klanten ook echt nodig hebben. Goede procesafspraken en duidelijkheid over de verantwoordelijkheden en richting binnen en tussen teams zijn hierbij heel belangrijk. Het is een hele investering om de ommezwaai te maken, maar het loont. Waar ik de transitie begeleid en meemaak, zie ik zelfs de meest sceptische mensen enthousiast worden over de resultaten en de onderlinge samenwerking.