Het is alweer een tijdje geleden dat ik het artikel "Een reis door het agile memeplex" van Kruchten (2007) las. In dit artikel beschrijft de auteur de snelle groei van nieuwe frameworks die nieuwe taal, acroniemen, richtlijnen en governance-modellen introduceren. Contextuele behoeften aan aanpassingen genereren nuances in de manier van werken, die slimme mensen vaak gebruiken om dit te beschrijven als een "framework", "methode", "manier van werken", "governance-model", een "operationeel model" of een "patroonbibliotheek". Omdat al deze concepten gebaseerd zijn op uitgebreide theorie, ervaring of best practices, bestaat de behoefte om ze te publiceren als de 'definitieve richtlijn voor het gebruik van Agile in een bepaalde context'. Omwille van de eenvoud zal ik ze "frameworks" of "Rationale om logica na ervaring te coderen" noemen.
Verwarring en concurrentie = onproductief
Deze frameworks blijken verwarring te zaaien bij degenen die op zoek zijn naar begeleiding, en leiden tot concurrentie tussen degenen die deze begeleiding aanbieden. Het bewijs dat een framework in de ene organisatie succesvol is toegepast, garandeert niet dat het in een andere organisatie ook succesvol zal zijn. Het is eigenlijk best grappig om erover na te denken; Agile-aanhangers zijn gefocust op empirisme, wat betekent: " de opvatting dat alle concepten voortkomen uit ervaring, dat alle concepten betrekking hebben op of van toepassing zijn op dingen die ervaren kunnen worden, of dat alle rationeel aanvaardbare overtuigingen of proposities alleen door ervaring te rechtvaardigen of te kennen zijn " ( Encyclopedia Britannica ). Of, in mijn woorden: " gebaseerd op bewijs ". De zekerheid over de effectiviteit van een concept komt voort uit het feit dat die effectiviteit bewezen is. Dit is de reden waarom Agile-aanhangers het belang benadrukken van iteratiereviews, systeemdemonstraties, vroege productintegraties en frequente releases. Het is "bewijs" dat wat we beloofd hebben ook daadwerkelijk geleverd wordt en waarde biedt aan iedereen die het eindproduct gebruikt. Hetzelfde geldt voor Agile-frameworks.
Empirisch onderzoek en ontspanning = productief
Agile ondersteunt al meer dan 20 jaar kleine en grote organisaties en heeft zich daarin bewezen. De elegantie van het Manifest leert de wereld hoe een eenvoudig transformatieplan te hanteren bij de overstap naar een agile framework, enzovoort. Het is zelfs de allereerste zin van het Manifest : " We ontdekken betere manieren om software te bouwen door het zelf te doen en anderen daarbij te helpen ." In de loop der jaren hebben we geleerd dat de principes en werkwijzen van Agile ook buiten de softwareontwikkeling van toepassing zijn. Dus, beste hardwareliefhebbers: even geduld...
Het manifest leert ons een manier van werken te vinden… oh… laat me even corrigeren, 'rationeel om logica te coderen na ervaring', door te beginnen. Beginnen met welke methode, welk raamwerk of welke richtlijn dan ook, en leer hoe je van daaruit verder kunt gaan. De verschillende bestaande rationales om logica te coderen na ervaring kunnen je richting geven bij de volgende stap. Dit empirische leerproces is lang en moeilijk, omdat schaalvergroting na verloop van tijd consolidatie en standaardisatie vereist. En de enige manier om te begrijpen wat in jouw context werkt, is door het Agile-traject te doorlopen.
Uitspraken als "wij zijn absoluut niet zoals dat andere framework" wakkeren de verwarring en concurrentie alleen maar verder aan en dragen tegelijkertijd bij aan de memeplex. Het is volkomen logisch om ondersteuning te zoeken om je een weg te banen door de jungle van methoden, werkwijzen en frameworks, aangezien de lijst enorm lang is. Ik denk dat we onze strategie voor de implementatie van agile moeten aanpassen; ik denk dat we wat meer ontspannen moeten zijn.
In mijn poging om een lijst samen te stellen van veelbesproken en gebruikte argumenten om logica te coderen op basis van ervaring, ben ik een overvloed aan disclaimers tegengekomen. Zoals eerder vermeld: sommige hiervan zijn frameworks, sommige methoden, en sommige patroonbibliotheken. Hieronder een onvolledige lijst met bronnen die u kunnen helpen bij het vinden van uw eigen Agile-werkwijze, governance-model, of hoe u het ook wilt noemen...
- Acceptatietestgestuurde ontwikkeling (ATDD)
- Agile bedrijfsanalyse (AgileBA)
- Agile digitale diensten (AgileDS)
- Agile Vloeiendheid
- Agile modellering (AM)
- Agile Portfolio Management (APfM)
- Agile projectmanagement (AgilePM)
- Agile Rational Unified Process (RUP)
- AgileSHIFT
- Behendigheidsschalen
- Bimodale portefeuillebeheer (Bimodal PfM)
- Continue integratie/continue implementatie (CI/CD)
- Kristal
- Ontwerpdenken
- DevOps (inclusief varianten zoals DevSecOps en BizDevOps)
- Gedisciplineerde Agile (DA)
- Dynamische systeemontwikkelingsmethode (DSDM)
- Enterprise Scrum
- Op bewijs gebaseerd management (EBM)
- Experimentgestuurde ontwikkeling (FDD)
- eXtreme Programmeren
- Functiegedreven ontwikkeling
- Holocratie
- Kanban
- Grootschalige Scrum (LeSS)
- Lean Management
- Lean Startup
- Portefeuillebeheer (MoP)
- Methode œ
- Aangepaste Agile-methodologie voor hardwareontwikkeling (MAHD)
- Nexus
- Open Space Agility (OSA)
- OpenUP
- Praxis (voor de Nederlanders; nee, dit is niet de doe-het-zelfwinkel)
- Prince2 Agile
- Project Half Double
- Snelle leercycli (RLC)
- Recepten voor agile governance binnen de onderneming (RAGE)
- Scaled Agile Framework (SAFe)
- Scaled Agile Lean Development (ScALeD) Scrum
- Scrum op grote schaal
- Scrum voor de bouw
- Scrum der Scrums (ook al heet het tegenwoordig Scrum op grote schaal)
- ScrumBan
- ScrumXP
- Sociocratie
- Spotify-model (hoewel geen model)
- Standaard voor portefeuillebeheer (SfPfM)
- Testgestuurde ontwikkeling (TDD)
- Gedragsgestuurde ontwikkeling (BDD)
- Toyota-productiesysteem
- Losmaken
- Gebruikerservaringontwerp
En laten we benadrukken dat het vastleggen van een reeks werkwijzen in een methode in dit artikel niet wordt bekritiseerd. Sterker nog, een van de items in de bovenstaande lijst is in het verleden door mij ontwikkeld. Kun je raden (via Google) welke?