Door Gert Zweedijk
In de vorige blog (ShuHari: van leerling naar meester) las je dat er mensen zijn die dingen (willen) doen volgens het boekje (Shu). Mensen met meer ervaring (Ha) zijn vaak bezig met het zoeken naar handige tips en tricks vanuit de praktijk. In deze blog kijken we naar het belang van best agile practices die zijn ontstaan vanuit jarenlange praktijkervaringen (van invloedrijke (Ri-)schrijvers). Business analisten kunnen een belangrijke rol spelen bij het vinden en toepassen van (nieuwe) best practices.
Wikipedia omschrijft een best practice als “een techniek, werkmethode of activiteit die zich als effectiever heeft bewezen dan enige andere techniek, methode etc. De gedachte is dat met de juiste werkmethode een project uitgevoerd kan worden met minder problemen, minder onvoorziene complicaties en betere eindresultaten. Het is dus voor organisaties belangrijk de ‘best practices’ binnen hun branche te kennen en de eigen manier van werken hiermee te kunnen vergelijken”.
Vaak hebben best practices de gestalte van patterns, die aangeven wat wél en wat er juist niet werkt in bepaalde situaties. In het laatste geval is er sprake van een zogenaamde anti-pattern.
Scrum-patterns
Een aantal bekende Scrum-patterns zijn:
- Product Backlog: Dit is een lijst met requirements en andere to-do’s die door de Product Owner wordt geprioriteerd en waarvan de bovenste items als eerste worden gedetailleerd, zodat het ontwikkelteam kan overgaan tot het bouwen van het softwareproduct.
- Definition of Ready: Hiermee wordt vooraf bepaald hoever requirements uitgewerkt moeten zijn om een goede inschatting te kunnen maken voor de volgende Sprint.
- Sprint 0: De meeste teams besteden enige tijd aan het samenstellen van het ontwikkelteam, het inrichten van een ruimte met tools, plus het bepalen van de initiële Product Backlog.
Sommige patterns, zoals de Product Backlog, zijn standaard opgenomen als artefact[1] in The Scrum Guide. Andere practices, zoals Definition of Ready, komen weliswaar niet voor in The Scrum Guide, maar zijn algemeen geaccepteerd in de Scrum-wereld. En er zijn practices waarover de meningen onder Scrum-practitioners sterk zijn verdeeld, zoals Sprint 0. Kennelijk werken deze voor sommige teams wel, maar voor andere niet. Dan zijn er nog patterns waarvan inmiddels bij de meeste organisaties bekend is dat ze niet werken. Een paar bekende anti-patterns zijn:
- Big Requirements Up Front (BRUF): Hiermee wordt bedoeld dat je álle requirements, dus ook de gedetailleerde, uitwerkt voordat je gaat ontwikkelen. Dit was gebruikelijk in watervalprojecten. BRUF is in de meeste gevallen onmogelijk, omdat je niet alle requirements op voorhand in kaart kunt brengen. Stakeholders weten namelijk op voorhand eenvoudigweg niet wat ze precies willen.
- Een sturende projectmanager in een agile team: dit is ongewenst, omdat het de zelfsturing van het team ondermijnt.
- Het ontbreken van een (betrokken) Product Owner: dit is ongewenst, omdat hierdoor geen duidelijkheid ontstaat over (de prioritering van) het informatiesysteem.
- Het ontbreken van een goede stakeholderanalyse: dit is ongewenst, omdat dit vaak leidt tot een incomplete product vision en een foutieve ontwikkelroadmap (waardoor geen bruikbaar product kan ontstaan).
Twee stappen in patterns
In patterns zijn twee stappen te onderscheiden:
- Pattern mining: dit is het analyseren van projecten en situaties met als doel daar patronen in te ontdekken die leiden tot verbeteringen. Zoals ik in de vorige paragraaf aangaf, kan het verstandig zijn om naar patterns te zoeken in jouw eigen organisatie, maar je kunt uiteraard ook gebruikmaken van de input van invloedrijke schrijvers die met suggesties komen.
- Pattern application: het toepassen van die patronen op de werkvloer en vervolgens nagaan in hoeverre het patroon toegevoegde waarde heeft voor de organisatie.
Onthoud: Analisten kunnen een belangrijke bijdrage leveren bij zowel de totstandkoming als de toepassing van diverse (systeemontwikkelings-) patterns. Ten eerste omdat ze vaak meewerken aan agile projecten (ze zitten dicht bij het vuur), en ten tweede omdat ze een mindset hebben die gericht is op het continu verbeteren van organisaties.
Agile frameworks
Soms worden best practices gebundeld tot een nieuw framework of nieuwe methodiek. Ik noem een paar populaire frameworks:
- XP (eXtreme Programming): hoewel dit framework sterk gericht is op programmeurs, telt het enkele practices die algemeen aanvaard zijn in andere agile frameworks. Een paar voorbeelden zijn Refactoring (technical debt), pair programming, user stories, release planning en iteration planning, prioritering op basis van business value, en Test Driven Development (TDD).
- Lean software development: tot dit framework behoren onder andere de practices Voorkómen van verspillingen, Value Stream Mapping, Pull, Gemba en Poka Yoke[2].
- Scrum: bekende Scrum-practices zijn onder andere Definition of Done (DoD), Estimation, Sprint, Sprint Planning meeting, Daily Scrum, Sprint demo, Retrospective, Product Backlog, Impediment Backlog, Velocity, Burndown chart en Sprint Backlog.
- Agile Modeling: zoals de naam al aangeeft concentreert Agile Modeling zich rondom best practices in modelleren en documenteren.
Veel mensen weten niet dat Scrum diverse practices heeft geadopteerd uit andere methodieken en frameworks, met name uit XP en Lean (development). User stories bijvoorbeeld zijn een algemeen begrip geworden in een Scrum-project, maar vinden hun oorsprong in XP. Een ander voorbeeld is Planning Poker dat oorspronkelijk door James Grenning is beschreven en later sterk aan populariteit won door het boek Agile Estimating and Planning van Mike Cohn. Ook Kanban wordt veel gebruikt in Scrum en andere agile methodieken en frameworks, maar het is afkomstig van Lean.
Is dit dan een probleem? Nee, integendeel! Het helpt je namelijk om heel anders tegen het begrip framework aan te kijken (conform de Ri-fase uit de vorige paragraaf). De kracht van een framework is juist dat je uitgaat van de basisprincipes en dat je wordt aangemoedigd om daar zelf (best) practices aan toe te voegen. Als je Scrum bekijkt vanuit deze optiek, is het niet verstandig om Scrum precies volgens het boekje te doen. Toch doen de echte Scrum-puristen dit nogal eens. Sommige van hen roepen bijvoorbeeld dat een Sprint 0 niet bestaat en daarmee dus onbespreekbaar is. Dit is wellicht een gemiste kans, omdat een Sprint 0 wel degelijk toegevoegde waarde kan hebben.
Onthoud: Maak zo veel mogelijk gebruik van agile frameworks (zoals Scrum) en kijk wat wel en wat niet werkt in jouw specifieke situatie. Gebruik de basisprincipes en voeg daar zelf indien nodig (best) practices aan toe.
Drie golven
Mike Beedle, die met Jeff Sutherland het boek Agile Project Management with Scrum schreef – dit was het eerste boek over Scrum – schrijft in zijn whitepaper Enterprise Scrum – Executive summary, Business agility for the 21st century dat er drie golven zijn in de ‘agility’ van organisaties.
De eerste golf betreft Single Team Agile. Tot de eerste golf behoren onder andere de eerdergenoemde frameworks XP, Scrum, Agile Modeling en Lean Software Development. Op dit niveau is min of meer consensus bereikt door het opstellen van het Agile Manifesto in 2001.
Dit geldt nog (lang) niet voor de tweede golf, die een jaar of tien geleden is ontstaan vanuit jarenlang gebruik van Scrum in de praktijk. Hierbij gaat het vooral om het opschalen (scaling) van Scrum (Agility at scale of Scaling Scrum) voor grote teams en organisaties. Dit is momenteel een van de populairste onderwerpen in de agile-wereld. De bekendste frameworks die tot de tweede golf behoren zijn LeSS (Large Scale Scrum), SAFe (Scaled Agile Framework) en DAD (Disciplined Agile Delivery). LeSS, SAFe en DAD maken veelvuldig gebruik van best practices, waaronder Lean Thinking, Systems Thinking en Design Thinking.
Tot slot is er nog een derde golf in agile ontwikkeling en dat is Enterprise Scrum. Grondlegger van dit framework is de eerdergenoemde Mike Beedle. De basis van dit framework vormt de gedachte dat de wereld om ons heen steeds sneller verandert en dat organisaties mee moeten veranderen om te kunnen overleven. Zoals de naam weergeeft, is Enterprise Scrum een (abstracte) toepassing van Scrum op organisatieniveau. Beedle stelt op pagina 19 van zijn white paper het volgende: “But even back then, in 2001, we [Beedle & Sutherland red.] knew Scrum was used, could be used and should be used, for many things other than just software development.”
Onthoud: Scrum is van origine ontwikkeld als framework dat breder kan worden ingezet dan alleen voor systeemontwikkeling! Ook hierin zitten dus interessante elementen voor de (agile) business analist.
De bomen en het bos
Op de website Agilebuddha.com staat een overzicht van best Scrumpractices.
Het bevat een mindmap met hoofdonderwerpen (bijvoorbeeld Daily Scrum) plus daarbij horende onderwerpen (met onder andere Same time, same place every day en No interruptions). Deze lijst concentreert zich alleen op Scrum en is al erg uitgebreid. De Agile Alliance heeft ooit een overzicht gemaakt in de vorm van een metrokaart (zie figuur 1) waarin een aantal bekende frameworks (onder andere Scrum, DevOps, eXtreme Programming en Lean) zijn opgenomen.[3]
Iedere ‘metrohalte’ op de kaart kun je beschouwen als een practice. Op de kaart zijn de practices geclusterd per framework. Ieder framework wordt weergegeven als metroroute door het landschap. Dit moet je uiteraard niet te letterlijk opvatten. Daarmee bedoel ik dat je niet ergens instapt en klakkeloos de bolletjes volgt. Je zult zelf als team op zoek moeten naar wat wel en wat niet werkt in jouw specifieke situatie. Alle goede bedoelingen ten spijt, de genoemde golfbewegingen hebben geleid tot een enorm oerwoud van frameworks en patterns waarin je snel kunt verdwalen. Je zult dus zelf de bruikbare bomen in het oerwoud moeten ontdekken en leren toepassen.
Gebruik een framework waar het voor bedoeld is, dat wil zeggen, ga er niet te rigide mee om. Daniel Gagnon stelt in zijn webinar ‘The Agile Project Manager – Fact or Fiction?’: “Don’t constrain your organization to the canon of methods & frameworks. Instead look at the added value for your team/organization.”
Roisi Proven is in haar artikel ‘The Less Safe Dad – Acronyms in Agile’[4] zeer kritisch over de koers die sommige organisaties varen van framework (Scrum) naar framework (LeSS) naar framework (SAFe), in de hoop dat dit nieuwe framework ze antwoorden geeft op de vele vragen waar ze mee worstelen. Ze stelt: “Agile is what you make it, not what people tell you it should be”, en: “Agile framework has always sounded like a bit of an oxymoron to me, because if you adhere too strictly to any one framework, you’ve ceased to be agile.”
Ik ben het met haar eens. In plaats van klakkeloos een framework te gebruiken, doe je er in mijn ogen veel beter aan een soort toolbox (een practicebox) samen te stellen waaruit je in ieder project kunt putten. Start ieder project met een simpele basis, bijvoorbeeld een Product Backlog en een Kanban, en voeg daaraan elementen toe die waarde hebben voor jouw team en stakeholders. Zelfs Scrum kan voor sommige projecten te uitgebreid zijn, zoals ik laatst ervoer in een project waar een externe Topdesk-programmeur slechts af en toe tijd had om iets te bouwen. Een Backlog en een Kanban bleken genoeg voor het project: de programmeur kon op afstand af en toe een item van de Backlog halen en realiseren. Ontwikkeling op basis van Sprints bleek niet nodig (het was zelfs niet mogelijk). Het project leverde een goed resultaat binnen de afgesproken tijd en budget!
Business analisten hebben een mindset en de motivatie om de organisatie waarvoor ze werken continu te verbeteren. Ze zitten vaak in agile teams waarin ze een bijdrage leveren aan de totstandkoming van een informatiesysteem. Die bijdrage leveren ze enerzijds door de requirements op te stellen en uit te werken (samen met de Product Owner en/of de stakeholders) en anderzijds door nieuwe technieken (practices) te introduceren waarmee (agile) projectteams kunnen worden verrijkt.
Voor de verbetering van het proces van systeemontwikkeling kunnen ofwel losse practices worden gebruikt, ofwel practices in de vorm van een framework zoals Scrum, SAFe of DAD. Het voordeel van frameworks is dat je een kant-en-klare set met practices naar binnen fietst. Het nadeel is dat er dermate veel frameworks en practices zijn dat je door de bomen het bos niet meer ziet. Het kan analisten (en andere teamleden) erg helpen om bekend te raken met diverse practices, al dan niet in de vorm van methoden en technieken.
Samenvatting
Er zijn talloze boeken, artikelen en blogs geschreven met tips en tricks voor wat te doen in bepaalde omstandigheden. Deze best practices kunnen heel nuttig zijn en het is dus aan te bevelen om medewerkers (business analisten) energie en tijd te laten steken in het vinden en benutten van deze best practices. Best practices kunnen los beschreven zijn en kunnen ook ondergebracht zijn in een framework. Disciplined Agile Delivery en Agile Modeling zijn daar voorbeelden van.
[1] Een artefact is een door de mens vervaardigd, bewerkt en/of gebruikt object, bijvoorbeeld een document, werklijst of model.
[2] Gemba betekent: ‘daar waar het gebeurt’. Daarmee wordt de werkvloer bedoeld. Sluit je dus zoveel mogelijk aan op de belevingswereld van de eindgebruiker (van een systeem). Met Poka Yoke wordt bedoeld het afdwingen dat iemand geen fouten kan maken. Voorbeelden hiervan zijn de SIM-kaart in een mobiele telefoon. Die kun je er maar op een manier in doen, zodat je geen fouten kunt maken. Een ander voorbeeld is het eerst retourneren van je bankpas aan een geldautomaat voordat je je geld krijgt. Als je dit om zou draaien dan zouden veel meer mensen hun bankpasje vergeten mee te nemen.
[3] Inmiddels zijn er diverse varianten van de metrokaart in omloop. Chris Webb van Deloitte heeft er ook een gemaakt waarin zo’n beetje alle bekende frameworks zijn opgenomen (waaronder PRINCE2, Scrum, RUP, Agile Modeling, DAD, Lean, DevOps, Cynefin en Kaizen). Bron: http://i.imgur.com/NzT6Bch.jpg
[4] In de titel verwijst ze naar de agile frameworks LeSS, SAFe en DAD.
Recente reacties