december 2017 – Agile is hot. Geïnspireerd door IT teams die “standup” sessies houden bij een “taskboard” willen ook andere business afdelingen starten met agile. Daar valt ook veel voor te zeggen. Agile werken is leuk en effectief. Wat voor IT goed werkt hoeft voor andere processen echter niet goed te werken. We zetten de vijf grootste valkuilen bij agile business transities voor u op een rijtje.
Een korte inleiding tot agile
Agile is primair een manier van denken, ondersteund door een aantal principes en richtlijnen. Bij agile worden resultaten op een iteratieve wijze (met herhalende stappen) en incrementeel (steeds een stukje erbij) neergezet. Leren en verbeteren is een van de basis principes.
Om agile te kunnen werken is een werkvoorraad in behapbare brokjes nodig (de Product Backlog). De Product Owner bepaalt de inhoud van de Product Backlog en prioriteert binnen deze backlog. Een multidisciplinair team realiseert de inhoud. Een Scrum Master kijkt vooral naar de samenwerking en de kwaliteit van het agile proces zelf.
Het gewenste resultaat wordt in stapjes bereikt door iedere keer een deel van deze werkvoorraad te realiseren. Er zijn verschillende varianten van agile. Bij Scrum heb je vaste iteraties van 2 of 3 weken, waarbinnen je meerdere werkpakketten realiseert. Bij Kanban pak je de werkvoorraad per stuk op.
Een agile business transitie is dus ook een nieuwe manier van manier van denken introduceren, naast de inrichting van structuur en processen. Waar kan je dan zoal tegenaan lopen?
Valkuil 1 – Op moment x moeten we agile zijn
“We huren een agile coach of transitiemanager in en stellen een transitieplan op. Het eindresultaat moet zijn dat op moment x de organisatie “agile” is. Als dat doel bereikt is vieren we een feestje en plukken wij de vruchten van het agile werkproces”.
Voor de organisatie ontstaat het beeld dat agile een checklist is waarbij je de processen op orde moet maken zodat de vinkjes gezet kunnen worden. Daarna is het doel bereikt en kunnen we ons weer richten op ons eigenlijke werk.
De essentie van agile is niet dat de processen agile zijn. De essentie van agile is dat de organisatie wendbaar is. Waarom? Omdat een gezonde organisatie meebeweegt met de omgeving en haar inrichting, producten en processen aanpast aan wat nodig is. Stilstand is achteruitgang.
Om zo wendbaar te zijn is een agile manier van denken nodig. Het gaat niet om het aanpassen van een proces. Het gaat om het blijven zien waar veranderingen nodig zijn en het daarin meebewegen.
Een agile transitieplan legt de nadruk op het agile leren denken om het lerende vermogen van de organisatie verbeteren. De agile transitie is geslaagd als de organisatie in voldoende mate in staat is om zelfstandig te leren en verbeteren. Natuurlijk zijn er binnen de agile transitie ook veranderingen nodig in structuur en processen. Deze veranderingen zijn onderdeel van het plan, maar zijn hierbinnen alleen een hulpmiddel en geen doel op zich.
Valkuil 2 – Alles moet agile
“We kiezen voor Scrum als Agile blauwdruk voor onze organisatie. Per afdeling en team gaan we aan de slag om een product backlog op te stellen en in sprints realiseren wij onze producten”.
Agile is niet de oplossing voor alles. De realiteit is dat agile vooral goed past bij productontwikkel processen en minder (of niet) past bij andere processen. Als je steeds hetzelfde product oplevert, weinig samenwerking nodig hebt en de voorspelbaarheid van het proces hoog is, kan je beter naar Lean kijken voor inspiratie voor procesverbeteringen. Voorbeelden zijn fysieke productieprocessen, routine werk zoals het inboeken van facturen, het maken van rapportages, etc.
Ook hier geldt dat agile niet het doel is, maar een hulpmiddel. Een agile transitieplan houdt rekening met de organisatieonderdelen die niet agile zijn en het ook niet gaan worden. Waar het plan zich op moet concentreren is dat de samenwerking tussen de onderdelen die wel een verandering ondergaan en onderdelen die geen verandering ondergaan optimaal blijft functioneren.
Valkuil 3 – Je bent agile of je bent het niet
“We gaan werken met User Stories en iedere sprint brengen we een Minimal Viable Product naar onze klanten. Dat is wat agile is en voor minder dan dat gaan we niet”.
Het mooie van agile is dat er weinig wordt voorgeschreven hoe je het in praktijk implementeert. De Agile/Scrum guide bijvoorbeeld bevat zo’n 18 kantjes en beperkt zich tot rollen en procesbeschrijvingen. De guide wordt helaas vaak gelezen als de enige en ideale weergave van hoe Scrum kan werken in een team.
Het heeft echter geen zin om naar een ideaalbeeld te streven voor een geïsoleerd team. Daarmee heb je nog geen goed functionerende organisatie. Het geforceerd implementeren van een ideaalplaatje leidt tot frustratie en een falende transitie. Dat is ook helemaal niet nodig. Er zijn in agile genoeg instrumenten beschikbaar om implementatiekeuzes op maat te maken. Allerlei opties zijn mogelijk tussen het ideaalbeeld tot bijna een traditionele waterval aanpak.
Een effectieve agile transitie is een transitie naar een situatie die wel werkt, die rekening houdt met de hele organisatie. Van daaruit kan je stapsgewijs leren en verbeteren. Je bent meteen al agile en werkt aan een nog effectievere agile werkwijze in de toekomst, alleen heb je daar geen transitieaanpak meer voor nodig.
Valkuil 4 – oude organisatiebalast overboord gooien
“Nu we agile gaan werken kunnen we afscheid nemen van projectmanagers en lijnmanagers. De Product Owner stuurt samen met het team op het creëren van waarde. Die managers horen bij de oude manier van werken”.
Een lijnmanager is meestal verantwoordelijk voor de kwaliteit, kwantiteit en welzijn van de mensen in zijn afdeling. Soms is een lijnmanager ook resultaatverantwoordelijk. Een projectmanager is altijd resultaatverantwoordelijk (binnen vastgestelde grenzen), maar gaat meestal niet direct over de mensen in zijn team.
Het ligt voor de hand om te zeggen dat een Product Owner al deze verantwoordelijkheden in een combineert. Hij stuurt het team op dagelijkse basis aan en stuurt naar een specifiek resultaat. Dan heb je toch geen lijnmanager en projectmanager meer nodig?
Zo werkt het echter vaak niet. Enkel bij zeer eenvoudige organisatiemodellen is het mogelijk de rol van projectmanager en lijnmanager te combineren met de rol van Product Owner. Bijvoorbeeld bij een startup met 1 team kan het een handige keuze zijn om de Product Owner die verantwoordelijkheden te laten nemen.
Bij een gemiddelde organisatieomvang werkt het al niet meer. De Product Owner heeft al een dagtaak aan het managen van het product en kan die andere taken er niet bij nemen. Iemand anders moet de aandacht aan de medewerkers geven die ze verdienen en pakt de HR verantwoordelijkheid op.
Ook projecten blijven bestaan, of je nu agile werkt of niet. Er zijn deadlines en er zijn business cases die gehaald moeten worden. Het managen van zo’n project blijft nodig, waarbij agile een deel inkleurt van het project. Hier zijn al veel artikelen over geschreven. In de praktijk zie je dat er allerlei combinaties zijn te maken tussen traditioneel en agile. Projectmanagers pakken de complexe projecten op. Product Owners pakken zelf die rol bij eenvoudige projecten. Stuur ze niet weg!
Valkuil 5 – te enge focus op alleen productontwikkeling
“Doordat we agile gaan werken maken we ons productontwikkelproces effectiever. Onze Product Owner gaat samen met een agile team aan de slag om in stappen mooie resultaten neer te zetten”.
Op zich is er niets mis met deze doelstelling. Het is inderdaad een doel wat goed bereikbaar is met een agile implementatie. Productontwikkeling is echter 1 stap in de levenscyclus van een product. Er is ook nog zoiets als het concipiëren, beheren en uitfaseren van een product. Allemaal stappen binnen de voortbrengingsketen van een product.
In Lean noemen we het “suboptimalisatie” als 1 stap in een keten verbeterd wordt en niet de hele keten tegelijkertijd. Suboptimalisatie leidt niet tot een beter proces, maar vaak juist een minder goed proces. Een stap in de keten verbeteren kan wel als de andere stappen daar geen last van gaan krijgen.
Het is verstandig om in het transitieplan een rationale op te nemen over welke producten de transitie gaat, welke producten daar nog even buiten blijven en welke producten we op de oude manier blijven doen. Een randvoorwaarde is verder dat procesverbeteringen ook de voortbrengingsketen verbeteren. Het moet er wel beter op worden aan het einde van de streep.
“Bonus” Valkuil – De transitie faalt door teveel tegenslagen
“Iedere week komen we weer nieuwe en complexe problemen tegen. Het gaat ons nooit lukken zo. We stoppen ermee en gaan terug naar de oude werkwijze. Toen hadden we al die problemen niet”.
Als uitsmijter een nog een extra valkuil, waarbij de organisatie de transitie afbreekt omdat er teveel tegenslagen ontstaan. Hoe zit dat?
Agile heeft de mooie (en ook vervelende) eigenschap dat het agile proces beter zichtbaar maakt wat er nog niet zo goed geregeld is. Dat betekent inderdaad dat tijdens de transitie opeens allerlei problemen “ontstaan”. Het punt hierbij is dat de problemen er al die tijd al waren, maar door een ineffectief proces niet zo zichtbaar waren. Het is eigenlijk dus erg goed dat er opeens problemen naar voren komen, want dan kan je ze gaan verbeteren.
De valkuil heeft te maken met verwachtingen. Als het beeld leeft dat een agile transitie een wandeling door het park is, zal de werkelijkheid gaan tegenvallen. Ga er juist vanuit dat er problemen gaan komen. Geef aan dat je dat verwacht en dat kansen zijn om processen te verbeteren. Als er heel veel “verbeterkansen” ontstaan is wel handig om te prioriteren wat opgepakt wordt. Je hoeft niet alles tegelijkertijd te verbeteren.
Conclusie
Een agile implementatie kan best binnen een team plaatsvinden als het de bedoeling is om alleen geïsoleerd binnen dat team agile te leren. Als we echter praten over een agile transitieproject ligt de ambitie hoger want we willen de organisatie als geheel naar een hoger niveau trekken. Je zult ook gaan merken dat je bij een geïsoleerde agile implementatie tegen organisatorische grenzen gaat aanlopen.
De rode draad die zichtbaar is in bovenstaande valkuilen is dat een agile transitie een transitie is van ketens. We praten over horizontale ketens waarbij verschillende organisatieonderdelen in samenwerking een product realiseren. Ook verticale ketens worden geraakt. Het gaat hierbij om sturing, verantwoording, kennisontwikkeling, HR, etc.
Een goede transitieaanpak houdt rekening met de veranderingen die nodig zijn in beide vormen van ketens. Ook is het belangrijk ruimte en aandacht te geven aan organisatie- en procesproblemen die gedurende de transitie gevonden worden.
Het belangrijkste is echter om niet dogmatisch, maar nuchter te blijven kijken naar wat agile is. Agile is geen doel maar een hulpmiddel. Wat de organisatie aan kan en nodig heeft is maatgevend, niet de 18 kantjes in de Scrum guide.
Disclaimer
Iedere methode en model is per definitie een vereenvoudigde weergave van de werkelijkheid. Dat geldt ook voor artikelen zoals dit whitepaper. Laat u zich inspireren door onze artikelen, maar kijk vooral naar wat het beste werkt voor uw organisatie.
Result! Managers volgt in transitietrajecten een twee stappen aanpak. Eerst leren wij u kennen. Daarna voeren wij samen met u een plan op maat uit die leidt tot de gewenste resultaten.