Scaling Agile

In elk bedrijf dienen prioriteiten te worden gesteld als het gaat om welk werk het meest belangrijk is om als eerste te worden uitgevoerd. “Werk” is nogal een breed begrip en veelal wordt onderscheid gemaakt naar het primaire en secundaire proces c.q. welk werk doen we direct voor onze eindklanten en welk werk we doen om dat primaire werk mogelijk te maken.

Binnen het Scaled Agile Framework van SAFe wordt daarbij gekeken naar de “weighted shortest job first” (WSJF). De kosten van vertraging die daarbij kunnen optreden worden daarbij als leidend gezien bij het bepalen van de prioriteit van het werk.

In het model worden de prioriteiten in hoofdzaak op het portfolio niveau bepaald en het gaat daarbij om de grote ‘brokken werk’ c.q. epics. Een epic is bijvoorbeeld een nieuw product of een product verbetering voor onze eindklant. Het kan ook gaan om uitbreiding of verbeteringen in het secundaire proces en vanuit het SAFe framework gaat het dan veelal om ICT projecten en programma’s.

Duidelijk is dat onze zelfsturende scrum teams aansturing behoeven over welk ICT werkzaamheden zij als eerste moeten gaan oppakken. De voornoemde epics worden opgebroken in kleinere stukken werk c.q. die worden opgebroken in features en stories. Features zijn te beschouwen als functionele onderdelen binnen een project die vervolgens worden opgesplitst in stories. Deze stories zijn zodanig qua omvang dat ze door een scrum binnen een sprint kunnen worden gerealiseerd. Een sprint heeft een duur van 1 tot 4 weken en vanuit het SAFe model een voorkeur voor een periode van 2 weken.

Top-down kan het proces van prioriteitstelling en het opbreken van werk beginnen bij epics en vervolgens naar features en stories als een trechter worden beschouwd. Het managen van deze trechter is een uitdagende management klus waarvoor het SAFe Framework tal van ‘best practice’ voorbeelden en adviezen geeft.

De ‘kosten van vertraging’ worden binnen het Framework aangeduid als de ‘cost of delay’ en refereert aan de denkwijze van Don Reinertsen. Hij focust daarbij op de business waarde van kleine brokken werk die relatief snel kunnen worden opgeleverd. Daarvoor is uiteraard de ‘business value’ van belang die het werk oplevert naast de ‘time criticality’ ervan. Tevens wordt gekeken naar de waarde of mogelijkheden die de oplevering van het werk biedt aan ander nog op te leveren werk en welke risico’s we ermee ondervangen. Deze optelsom wordt vervolgens gedeeld door de investering die we in het werk hebben te doen en die kan worden uitgedrukt in het aantal sprints die ervoor nodig zijn of het aantal story points ervan.

Bij deze rekensom gaat het niet om het afzonderlijke geval, maar gaat het om het kunnen vergelijken van meerdere projecten in termen van epics of features. Het vergelijken daarvan is iets dat in teamverband gebeurt en waarbij de deelnemers in onderling overleg komen tot een ‘acceptabel vergelijk’. Inschatting van ‘business value’ en ‘risk reduction’ is uiteraard mensenwerk en subjectief. De objectiviteit wordt nagestreefd door het in onderling overleg eens te worden met elkaar over welke waarden waaraan kan worden toegekend.

De crux in deze werkwijze zit in het creëren van ‘een trechter met een goede doorstroom’, waarbij voor de diverse betrokkenen op portfolio en programma niveau de prioriteitstelling duidelijk is. Daarbij kan het werk (features/stories) vlot worden afgeleid vanuit de epics en worden doorgegeven aan de scrum teams op team niveau voor de realisatie tijdens de sprint(s). De transparantie van deze trechter wordt behouden door deze werkwijze frequent uit te voeren, bijvoorbeeld als voorbereiding op elke komende sprint. Zodoende is bij aanvang van elke sprint duidelijk welk werk als eerste kan worden opgepakt en dat de juiste prioriteiten nog steeds worden gesteld.

Voor het management zit de uitdaging erin om deze werkwijze steevast te blijven herhalen , zodat voor de betrokkenen op de diverse niveaus een acceptabele, herkenbare en transparante prioriteitstelling van de werkzaamheden bekend is.

Het introduceren van Agile werkvormen is de laatste decennia sterk opgekomen om oplossingen te bieden aan de problemen die zijn ontstaan door een steeds complexere en zich snel veranderende wereld. Zowel binnen als buiten de organisatie. Het is gebleken dat hiërarchische en gefaseerde ontwerpaanpakken steeds slechter presteerden. Zeker in ICT programma’s en projecten waarin sprake is van het ontwikkelen van complexe producten binnen complexe processen.

Het invoeren van Agile werkvormen moet uiteraard een heldere en logische aanleiding hebben voor de medewerkers. De behoefte aan Een aanleiding bestaat veelal uit een of meer complexe problemen en daarvan kunnen de medewerkers het beste een lijst opstellen. In samenwerking met het management kan dan tot een prioriteitstelling worden gekomen. Om de opsomming van problemen en kansen vooral bij de medewerkers te laten, geeft hen de kans hun eigen inbreng daarin te hebben. Te vaak zie ik dat het management wel ‘even’ de problemen definieert die vervolgens niet voldoende door de medewerkers worden herkent. Zij ‘kunnen’ dan geen eigenaarschap nemen om tot een oplossing te komen.

Er ontstaat vaak een situatie waarin het management aan het trekken en sleuren is om de boel in beweging te krijgen: requirements niet voldoende helder, langdurige ontwikkeltrajecten zonder concrete uitkomst, uitloop en budgetoverschrijdingen. Om daarin slimmer te acteren kan het management beter gebruik maken van haar eigen medewerkers en daadwerkelijk ‘human resource management’ te bedrijven!

Het geven van ruimte door het management aan de eigen medewerkers is een cruciaal element in ‘respect for people’ en ‘continuous learning’. Twee elementen die aan de basis staan om tot structureel verbeteren te komen vanuit het Agile gedachtengoed en die ik in mijn vorige blog “De basis van elke organisatie: Medewerkers :-)!” heb aangehaald. Dat vraagt een andere vorm van leiderschap dan waar het management regulier op wordt geselecteerd. Het vraagt dus ook andere kwaliteiten van een leider c.q. de leider als “Servant Leader”.

In plaats van voorop te gaan lopen als management, wordt juist gevraagd om ‘erachter’ te gaan lopen als een ‘servant leader’. In onderstaande afbeelding is linksboven bij het “SAFe House of Lean” het “Leadership” als onderliggende factor opgenomen. En dat is voor veel managers een ‘contradictio in terminis’: want juist de manager weet toch ‘hoe het allemaal in elkaar zit’ en ‘leads the way’? Helaas blijkt die inpak in de praktijk van complexe vraagstukken (zoals automatisering) slecht te werken.

Het acteren als “Servant Leader” sluit goed aan op het Agile Manifesto (zie rechtsboven in bovenstaande afbeelding), omdat het daarbij primair gaat om het faciliteren van mensen en teams om tot een succesvolle interactie met elkaar te komen. Die interactie wordt leiden als het gaat om oplossingen verder uit te werken en succesvol te implementeren. Die interactie wordt ondersteund door processen en tools die uiteraard ook heel belangrijk zijn, maar de interactie zelf is de belangrijkste sleutel tot succes.

Maar naast een verandering bij management vraagt het ook om een verandering bij de medewerkers. Zij mogen hun eigen werk organiseren en steeds verder verbeteren in afstemming met het management uiteraard. Het is niet simpelweg vrijheid/blijheid voor de medewerker en er moet een situatie van wederzijds respect bestaan tussen hen en het management.

Het betekent voor het management het ‘loslaten’ van diverse ‘management controle mechanismen’ zoals vaststellen  van start/stoptijden van het werk, rapportage over voortgang en het opleggen van verbeteringen. En daarbij is coaching van de manager hoe die omslag te maken, vaak essentieel om tot succesvolle resultaten te komen.

“Management Tools Are Not a Pillar of Lean”

Deze uitspraak is terug te vinden in een beschrijving over “LeSS” van Greg Larman en Bas Vodde (https://less.works/less/principles/lean-thinking.html#LeanThinking:TheBigPicture).

Dit kan ‘kort door de bocht’ klinken, maar het geeft wel het belang van wat dan dus wel de pilaren van Lean Thinking zijn: “respect for people” en “continuous improvement”.

De tools zoals Kanban, Scrum, Backlog en dergelijke zijn uiteraard handige gereedschappen, maar “a fool with a tool…”.

De essentie ligt dus bij hoe je als management het fundament creëert om op succesvolle wijze gebruik te maken van de tools. Dat succes ligt opgesloten in de medewerkers zelf die deze tools kunnen gebruiken en vanuit de gedachte van “continuous improvement” zelf continu kunnen verbeteren. Dat raakt ook de kern van Agile: het flexibel en snel inspelen op problemen, kansen en klantvragen (zowel intern als extern).

De te leveren klantwaarde is het uiteindelijke doel, maar het begin ligt opgesloten in de eigen mensen. Dus als we het uiteindelijke product of dienst aan de klant willen verbeteren, dan gaat het in eerste instantie om people, dan het proces en tenslotte het product of dienst zelf. Dit is een uitdagend veranderproces voor management en medewerkers. Daarbij is externe coaching vaak een waardevolle toevoeging is om tot positieve resultaten te komen.

De conclusie is dus dat tools heel waardevol zijn, maar dat daarvoor een verantwoord gebruik noodzakelijk is. Die verantwoording ligt bij de medewerkers zelf met een faciliterende rol voor het  management in de vorm van “respect for people” en “continuous learning”!

Het logo voor a3chem is ontworpen door Joost Dikker Hupkes, grafisch ontwerper.

Wanneer je zoekt op afbeeldingen voor Agile en Scrum dan draait het om processen en pijlen. Dit heeft Joost, samen met de uitspraak ‘Alles wat in drieën komt is goed’, geïnspireerd in driehoeken te denken. Het symbool Δ betekent toepasselijk ‘verandering’ of ‘verschil’.

Met behulp van een driehoekenraster en zoekend naar de overeenkomsten in de rondingen van de ‘a’ en de ‘3’ is hij gaan schetsen. Het definitieve beeldmerk bestaat uit precies 50 driehoeken.

Het lettertype Monoid voor het woordmerk is gekozen als de persoonlijke tegenhanger van het strakke, grafische beeldmerk. Net als het magenta (paarse) kleuraccent tussen de warme blauwe en frisse groene kleuren van de driehoeken. Monoid is niet alleen een lettertype, maar monoïden worden ook gebruikt om een stevige algebraïsche fundering te geven aan de informatica.