Processen ontwerpen in een agile organisatie, is dat zinvol?

Waarom zou je bij een agile aanpak een procesmodel maken? Wanneer is zo’n model goed genoeg?

Deze vragen krijg ik regelmatig van onze klanten. Een voor de hand liggend antwoord is; maak een model wanneer het agile team de behoefte van de klant niet scherp genoeg krijgt met in tekst vastgelegde requirements, zoals user stories, features of epics,en een mondelinge toelichting hierop. Met een model van een proces, en eventueel van een user interface, een complexe beslissingsregel of een system-to-system interface, kun je beter duidelijk maken wat de klant vraagt. Een procesmodel is een visualisering van het proces of onderdelen daarvan. De meeste mensen begrijpen dit beter dan een lijst met in tekst vastgelegde requirements. Onderzocht is dat 60% van de Nederlanders visueel is ingesteld; zij denken in beelden niet in woorden!

Een procesmodel komt ook tegemoet aan een andere belangrijke behoefte: inzicht in en overzicht over het ‘grotere plaatje’ of ‘waar gaan we heen?’ In een product vision en een bijbehorende backlog met een lijst requirements kun je teruglezen welke richting een bepaald product, bijvoorbeeld een App, opgaat en welke ‘dingen’ nodig zijn om dat te bereiken. Toch blijkt dit lang niet voor iedereen voldoende te zijn om het ‘grotere plaatje’ te ‘zien’. De samenhang tussen diverse processen en de gevolgen voor de uit te voeren werkzaamheden worden beter begrepen als mensen naar een procesmodel kijken.

Een derde belangrijke reden voor het opstellen van procesmodellen is om aansluiting te maken met de bedrijfsarchitectuur. In een bedrijfsarchitectuur worden de strategische doelen en keuzes van de organisatie vertaald in algemeen geldende afspraken over de bedrijfsinrichting. Een goed opgestelde bedrijfsarchitectuur bevat ook een overzicht van de belangrijkste bedrijfsprocessen en hoe deze onderling samenhangen. Ook worden hierin uitgangspunten voor processen vastgelegd en de relatie met ondersteuning door applicaties. De bedrijfsarchitectuur geeft dus een goede context voor procesontwerpers en iedereen die daarbij betrokken is. Iedereen gaat ‘het grotere plaatje’ nog beter zien.

OK, procesontwerpen dus, maar dan wel ‘just in time’, ‘just enough’ en ‘good enough’. Maar ook: “If you don’t have time to do it right, when will you have time to do it over?” [John Wooden]. Dus niet meteen alle processen, (user) interfaces of beslissingsregels uitwerken, maar alleen het bestaande onderdeel waar aanpassingen in gaan plaatsvinden. En niet alles heel gedetailleerd, maar aansluitend bij het doel van de epic of feature (just enough) en de behoefte van bijvoorbeeld de software developer (‘good enough’).

Heeft het scrum team behoefte om wat meer vooruit te kijken, dan kun je ook eerst het toekomstige proces ontwerpen. Het werkt ook heel goed om user stories, features en epics te koppelen aan het procesmodel zodat je visueel maakt waar het te maken product ‘heen gaat’. Dit helpt de business owner en product owner ook weer om nieuwe requirements te ontdekken, bestaande af te voeren en de backlog te prioriteren. Handig toch?

Met agile bedrijfsontwerp hebben wij een best practice ontwikkeld om op een agile wijze waarde toe te voegen met modellen, op een basis van architectuur en gangbare methoden zoals scrum en lean.

Benieuwd hoe? Download hier de whitepaper ‘Agile bedrijfsontwerp – vakmanschap in een agile setting’. Probeer het gewoon eens uit in je team en evalueer het achteraf!

 

Peter Buijs, Senior Business Consultant – Adviesgroep Novius

 

Voor meer informatie over dit onderwerp of over proces- en requirementsmanagement  kun je contact met mij opnemen via: pbuijs@novius.nl of via 06 16 210 515. Of anders via het secretariaat van Novius via: 0343 76 00 76.

Blijf op koers met je ethisch kompas!
Zomerblog No. 1 van 6 – Zwerven!

Geef een antwoord

Dit is een verplicht veld
Dit is een verplicht veld
Geef een geldig e-mailadres op.
Je moet de voorwaarden accepteren voordat je het bericht kunt verzenden.

Menu