Guilds [were] social networks that generated beneficial social capital by sustaining shared norms, punishing violators of these norms, effectively transmitting information, and successfully undertaking collective action.

Sheilagh Ogilvie

Adaptive and evolutionary systems by their nature involve experimentation. Since the way ahead is a gray zone, if we want progress, we must experiment.

Mike Rother

In het boek Werken onder architectuur gaan Rob van de Wetering en Gerard van der Zaal in op het begrip werkprocessen als eerste decompositielaag binnen bedrijfsprocessen:

De identificatie en de afbakening van bedrijfsprocessen van de verschillende bedrijfsprocessen moeten aansluiten op de wijze waarop het bedrijf de buitenwereld van dienst wil zijn. De identificatie en de afbakening van de werkprocessen, als eerste decompositielaag binnen de bedrijfsprocessen, worden bepaald door de wijze waarop het werk binnen de muren van het bedrijf uitgevoerd en bestuurd moet worden. Bij de afbakening van werkprocessen moet de architect, evenals bij de bedrijfsprocessen de vraag stellen: "Waarop moet worden gestuurd?" De afbakening van de werkprocessen is in principe de eenheid waarop de proceseigenaren afspraken maken met de operationele managers (= procesmanagers).

Er zijn verschillende invalshoeken mogelijk om werkprocessen af te bakenen. De architectuurprincipes beschrijven welke invalshoek het bedrijf hanteert. [Rob van de Wetering en Gerard van der Zaal] behandelen hier twee mogelijke varianten.

Allereerst kan de procesafbakening organisatiegericht zijn. De afbakening van de werkprocessen is dan afgestemd op de huidige en toekomstige organisatiestructuur. Indien voor de uitvoering van een bedrijfsproces achtereenvolgens drie afdelingen een stuk van de uitvoering voor hun rekening nemen, dan wordt het bedrijfsproces opgesplitst in drie werkprocessen. Elke afdeling heeft de verantwoordelijkheid voor één van de werkprocessen. Met elke afdeling kunnen op die wijze eenduidige afspraken worden gemaakt, die worden bijvoorbeeld vastgelegd in een Service Level Agreement (SLA). De afdelingsmanagers hebben de rol van procesmanager.

Een andere optie is dat de procesafbakening overeenstemt met de verantwoordelijkheden van 'onafhankelijke' procesmanagers die niet gebonden zijn aan een specifieke afdeling. Deze situatie doet zich voor bij een matrixorganisatie. Er zijn procesmanagers aangewezen voor de uitvoering van een deel van de bedrijfsprocessen en elke procesmanager betrekt personele capaciteit of diensten van (andere) specifieke afdelingen in het bedrijf. Indien het personele capaciteit betref, dan hebben deze leverende afdelingen in het karakter van een 'resource pool'. De afdelingsmanager van de 'resource pool' is voornamelijk gericht op de kwantiteit en de kwaliteit van het ter beschikking gestelde personeel. Deze afdelingsmanager wordt niet afgerekend op proces-prestatie-indicatoren. Bij afdelingen die (deel)producten leveren worden de afdelingsmanagers wel afgerekend op de prestaties in het afdelingsproces. Een voorbeeld hiervan is een 'shared service center' dat de andere afdelingen de financiële afhandeling van het verkoopproces uit handen heeft genomen.

Bij 'onafhankelijke' procesmanagers bestaan in de praktijk verschillende mogelijkheden om hun verantwoordelijkheden af te bakenen. Voorbeelden hiervan zijn:

- op basis van deelproducten - In de industrie worden dit halffabrikaten genoemd. In de verzekeringswereld kunnen we denken aan een geregistreerde claim, een getaxeerde schade en een beoordeelde claim. We komen deze deelproducten vaak tegen in combinatie met een fasering in het proces: claimregistratie, taxatie en claim-acceptatie.

- op basis van bedrijfsfuncties - Hierbij moet gedacht worden aan de vijf tot tien hoofdfuncties van een bedrijf. Elke procesmanager wordt in dat geval verantwoordelijk gesteld voor (de diensten van) een bedrijfsfunctie. Voorbeelden hiervan zijn inkoop, productie en verkoop.

Kortom, elke procesmanager is verantwoordelijk voor een werkproces binnen een bedrijfsproces en vervult eventueel de rol van afdelingsmanager. De proceseigenaar is over het algemeen verantwoordelijk voor een van-klant-tot-klant-bedrijfsproces en zorgt daarbij voor (de diensten van) een goede samenwerking tsen de verschillende procesmanagers.

Zie ook: Bedrijfsprocessen volgens Van der Wetering & Van der Zaal

Bron: Werken onder architectuur, Rob van de Wetering en Gerard van der Zaal

The purpose of training is to reduce variety, to get a group of people tackling tasks in the same way; so training reduces variety. The purpose of learning is the exact opposite. Learning increases the individual’s capacity to respond to different situations; it increases variety.

Patrick Hoverstadt

Hoe ruikt verandering?
Het verstaan van veranderaars
Peter Terlouw, Mark van Twist

Bij Bol.com | Managementboek

Development is always self-development. For the enterprise to assume responsibility for the development of a person is idle boast. The responsibility rests with the individual, her abilities, her efforts.

Peter F. Drucker

In het boek Werken onder architectuur gaan Rob van de Wetering en Gerard van der Zaal in op het begrip bedrijfsprocessen:

Een bedrijf staat niet op zichzelf, maar bevindt zich in een omgeving die de verwachting heeft bepaalde producten van dit bedrijf te kunnen afnemen. Per definitie start een bedrijfsproces als reactie op een 'event' en heeft een bedrijfsproces de levering van een product tot doel. Een 'event' is een gebeurtenis die plaatsvindt in het leven of de ontwikkeling van een klant (een 'life event') of het passeren van een bepaalde datum (een 'clock event'). Voorbeelden van 'life events' zijn de geboorte, een huwelijk, een ongeval en het winnen van een loterij. Een bedrijf kan op een 'event' reageren, zodra deze daarvan kennis neemt. Dat kan een binnenkomende melding zijn of een waarneming door het bedrijf zelf. Deze melding of waarneming vormt de 'trigger' voor het proces. Door in reactie op het 'event' een bedrijfsproces te starten (via de trigger) en deze volledig uit te voeren, worden een of meer producten geleverd. Afhankelijk van de procesinrichting, zijn per 'event' (bijvoorbeeld verhuizing naar het buitenland) dus verschillende 'triggers' (melding door emigrant of melding door de gemeente) voor de feitelijke start van het hetzelfde bedrijfsproces (stopzetten huurtoeslag) denkbaar. Maar voor hetzelfde bedrijfsproces (stoppen huurtoeslag) kunnen in principe ook verschillende 'events' (verhuizing naar het buitenland of overlijden) aan de orde zijn.

De afbakening van de bedrijfsprocessen in de procesarchitectuur is er primair op gericht om naar aanleiding van een 'event' (in- en externe) producten te leveren aan van te voren gedefinieerde (in- en externe) afnemers. Deze afbakening is bedoeld om als manager of medewerker op processen te kunnen sturen. De sturing op de processen is bepalend voor de waardering door de afnemers (tijdigheid, kwaliteit en kosten). Met de procesafbakening wordt zo een basis gelegd voor een besturingsmodel dat uitgaat van de te onderscheiden product-marktcombinaties.

Er is dus een expliciete relatie tussen de procesarchitectuur en de productarchitectuur. De definitie van de product-marktcombinaties (welke producten maken we voor welke klantgroepen) is mede bepalend voor de afbakening van de bedrijfsprocessen.

[Van de Wetering en Van der Zaal] geven een klein voorbeeld uit de uitvoeringspraktijk van een overheidsinstelling om deze relatie toe te lichten. Op het moment dat iemand werkloos is, wordt beoordeeld of deze persoon recht heeft op een werkloosheidsuitkering. [Een mogelijke manier om dit uit te werken in de product- en procesarchitectuur is door te stellen dat] er sprake (is van) één 'life-event', één 'clock-event' en twee producten. Het 'life-event' is 'werkloos worden' en het 'clock-event' is de maandelijkse trigger om uit te betalen. De twee producten zijn: 'de beschikking dat iemand recht heeft op een uitkering' en 'de daadwerkelijke uitkering'. Het eerste product is in principe eenmalig en het laatste product wordt maandelijks geleverd. Er is sprake van twee bedrijfsprocessen: de beoordeling en de uitbetaling. Dit laatste proces wordt 12 keer per jaar uitgevoerd voor de duur van de uitkering.

Zie ook: Werkprocessen volgens Van der Wetering & Van der Zaal

Bron: Werken onder architectuur, Rob van de Wetering en Gerard van der Zaal

I am always doing that which I can not do, in order that I may learn how to do it.

Pablo Picasso

In het artikel Agile is geen haastwerk leggen Rini van Solingen en Henk Jan Huizer uit hoe agile constante kwaliteit biedt bij het ontwikkelen van software:

De klassieke benadering van kwaliteit in software kenmerkt zich door een uitgebreide testfase. Het product is pas af als het uitgebreid getest is en alle gevonden fouten zijn verwijderd. Doordat het product pas ‘af ’ is aan het einde, vinden het testen en de kwaliteitsverhoging plaats aan het einde. Vandaar ook dat het noodzakelijk is de ‘scope’ te bevriezen.

Veranderingen in de scope leiden namelijk tot extra werk waardoor testactiviteiten in het gedrang komen – met nadelige gevolgen voor kwaliteit. Daarnaast wordt kwaliteit in de klassieke benadering bewerkstelligd door processen en richtlijnen. De verwachting is namelijk dat een goed proces een randvoorwaarde is voor een goed product

Agile werken is gebaseerd op een totaal andere benadering. Feitelijk dwingt agile werken af om kwaliteit te leveren (zie kader). Agile werken vraagt om telkens het product af te maken. Afmaken betekent: werkend én getest. In de praktijk betekent dat dus dat teams elke ‘sprint’ een product hebben dat leverbaar is. Kwaliteit vanaf het allereerste moment. Dus niet pas aan het einde testen, maar vanaf het begin al. Hoe eerder je fouten ontdekt, hoe meer tijd je krijgt om ze goed op te lossen. Agile vereist dat het product op elk moment in de tijd het kwaliteitsniveau heeft om uitgeleverd te worden. Om de kwaliteit constant te toetsen worden testen daarom zo veel mogelijk geautomatiseerd. Een testfase aan het eind is daardoor overbodig geworden, want kwaliteit is er op elk moment in de tijd. Daarnaast is er minder noodzaak voor uitgebreide procesbeschrijvingen en richtlijnen. De nadruk ligt bij agile namelijk veel meer op samenwerking en kennisuitwisseling tussen mensen, in plaats van op procedures en richtlijnen.

(...)

De essentie van agile werken is niet zoveel mogelijk werk in een korte iteratie proppen. Agile is niet quick & dirty. Geen haastwerk dus. De kunst zit in het slim doorvoeren van aanpassingen die maximale waarde opleveren en in het minimaliseren van risico’s door de aanpassingen zo klein en simpel mogelijk te houden en volledig geautomatiseerd te testen. Altijd aangetoonde kwaliteit dus. Niet aan het einde, maar vanaf het allereerste moment.

(...)

Zeven redenen waarom agile werken kwaliteit afdwingt

1. Ritme en regelmaat: agile zorgt voor een vast, terugkerend en visueel proces dat elke sprint wordt herhaald. Herhaling zorgt voor ritme en brengt een stabiel tempo. Dit verkleint de kans om onder druk slechte kwaliteit te leveren. Teams weten precies wat ze moeten doen om een product op te leveren. En de teams leren wat de hoeveelheid werk is die ze aankunnen zonder concessies te doen aan kwaliteit.

2. Kwaliteit is expliciet en staat vast: agile dwingt om zaken af te maken. Aan het eind van elke sprint is het product namelijk klaar: werkend én getest. Testen is niet een slotactiviteit die onder druk komt te staan, maar krijgt al alle aandacht die het verdient. Kwaliteit vanaf het allereerste begin. Dit wordt expliciet gemaakt in de Definition-of-Done: het is pas klaar als het aan alle acceptatiecriteria voldoet: elke iteratie opnieuw. Daardoor doen teams juist minder concessies aan kwaliteit, zij doen concessies aan de scope.

3. Continu leerproces: korte iteraties zorgen ervoor dat je sneller leert en deze ervaringen direct in de praktijk kunt brengen. Constante aandacht door regelmatige retrospectives zorgen voor procesverbetering vanaf het begin, zodat leerervaringen direct worden omgezet in acties. Teams leren daarnaast ook waarom bepaalde functionaliteit gewenst is of juist niet. Eerder leren wat de klant nu écht nodig heeft en waarom.

4. Waarde als stuurinstrument: agile helpt om direct waarde te leveren én te toetsen. Er wordt constant gestuurd en bijgestuurd op de vraag: maken we wel de juiste dingen? Agile dwingt om nauw samen te werken met de klant en continu zijn feedback te vragen. Requirements worden ‘vers’ besproken met betrokkenen. Er wordt alleen gekeken naar de benodigde details voor de komende sprints, en niet naar details voor werk dat nog lang niet aan de beurt is. Teams leren ontdekken waar de échte waarde zit. Liefst door minder software te maken, want hoe minder software hoe minder te testen en te onderhouden, dus hoe groter de kans op kwaliteit.

5. Geen grote projecten meer: agile dwingt om grote dingen op te knippen in kleine. Grote projecten gaan altijd mis. Changes zijn veel kleiner, het risico is daardoor ook kleiner. Teams hebben focus en werken maar aan een beperkt aantal dingen en maken dat écht af. Hierdoor verkleint de kans dat ontwikkelaars elkaar dwars zitten en dat ingewikkelde combinaties van changes leiden tot moeilijk vindbare defects.

6. Automatisering van kwaliteit: de businesscase voor testautomatisering is vele malen beter/sterker bij agile. Immers, integrale keten- en regressietesten worden veel vaker gedaan, namelijk elke sprint. Continu geautomatiseerde toetsing van kwaliteit is daardoor haalbaar en ook financieel interessant. Dit is overigens niet het enige herhaalbare werk dat veel beter geautomatiseerd kan worden. Onder het label van Continuous delivery wordt het hele OTAP-proces van ontwikkeling tot en met het in productie nemen geautomatiseerd. Dit legt de focus op vakmanschap, want de rest wordt geautomatiseerd.

7. Autonome teams: agile dwingt om in cross-functionele zelfverantwoordelijke teams te werken. Disciplines zitten dicht op elkaar. Kwaliteitsverantwoordelijkheid ligt in het team. Normaal zit hier afstand tussen, waardoor er minder verantwoordelijkheidsgevoel is en veel kennisverlies ontstaat in de overdracht. Nu hebben teams een gezamenlijke verantwoordelijkheid tot en met productie. Als je zelf ’s nachts wakker gebeld kunt worden omdat de kwaliteit onvoldoende is, dan is een bochtje afsnijden opeens een stuk minder interessant.

Bron: Agile is geen haastwerk, Rini van Solingen, Henk Jan Huizer