Best Agile Practices

In de vorige blog is de term ShuHaRi beschreven. We zagen 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 & tricks’ vanuit de praktijk. In deze blog kijken we naar het belang van agile ‘best 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 dit geval is er sprake van een anti-pattern).

 

Een aantal bekende Scrum-patterns zijn:

• Product backlog: 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 opdat het ontwikkelteam kan overgaan tot het bouwen van het softwareproduct.

• Definition of Ready: Hiermee wordt vooraf bepaald hoever requirements uitgewerkt dienen te 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 plus tools, plus aan het bepalen van de initiële product backlog.

Sommige patterns, zoals de Product Backlog, zijn standaard opgenomen (als artefact) in de Scrum Guide. Andere practices, zoals Defintion of Ready, komen weliswaar niet voor in de Scrum Guide maar zijn algemeen geaccepteerd  in de ‘Scrum-wereld’. En er zijn practices waarover de meningen sterk zijn verdeeld bij Scrum-practitioners, zoals Sprint 0. Kennelijk werken deze wel voor sommige teams, maar voor andere niet. En 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 alle requirements (dus ook de gedetailleerde) uitwerkt voordat je gaat ontwikkelen. Dit was gebruikelijk in waterval-projecten. BRUF is in de meeste gevallen onmogelijk omdat je niet alle requirements op voorhand in kaart kúnt brengen. Stakeholders weten namelijk op voorhand eenvoudigweg niet weten 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 m.b.t. (de prioritering van) het informatiesysteem.

• Het ontbreken van een goede stakeholder analyse: dit is ongewenst omdat dit vaak leidt tot een incomplete product vision en een foutieve ontwikkelroadmap (waardoor geen bruikbaar product kan ontstaan).

 

Twee stappen

Met betrekking tot patterns zijn er 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 al aangaf in mijn vorige blog kan het verstandig zijn om naar patterns te zoeken in jouw eigen organisatie, maar je kunt uiteraard ook gebruik maken van de input van invloedrijke schrijvers die met suggesties komen.

• Pattern application: het toepassen van die patronen op de werkvloer.

Analisten kunnen een belangrijke bijdrage leveren in zowel de totstandkoming als de toepassing van diverse (systeemontwikkelings) patterns. Ten eerste omdat ze vaak deelnemen in 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 methodiek. Ik noem een paar populaire frameworks:

• XP (eXtreme Programming)

  Hoewel dit framwork sterk gericht is op programmeurs, telt het enkele practices die algemeen aanvaard zijn in andere agile frameworks. Voorbeelden zijn : Refactoring (technical debt), pair programming, user stories, release planning & iteration planning, prioritering o.b.v. business value en Test Driven Development (TDD) om er een paar te noemen.

   

• Lean software development

  Tot dit framework behoren o.a. de practices: Voorkómen van verspillingen, Value Stream Mapping (dit is een vorm van procesmodellering waarmee de waarde van iedere processtap in kaart kan worden gebracht), Pull en Poka Yoke.

   

• Scrum

  Bekende Scrum-practices zijn o.a. Definition of Done (DoD), Estimation, Sprint, Sprint planning meeting, Daily Standup, Sprint demo, Retrospective, Product backlog, Impediment backlog, Velocity, Burndown chart en Sprint backlog. Zie onderstaande mind map voor een overzicht van Scrum-practices.

   

   

      _{Klik op de afbeelding voor een vergroting}

• Agile modeling

  Zoals de naam al aangeeft concentreert Agile modeling zich rondom best practices met betrekking tot modelleren en documenteren (zie onderstaande figuur).

 _{Klik op de afbeelding voor een vergroting}

 

Niet iedereen weet 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 (meer info) 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).

 

Is dit dan een probleem? Nee integendeel, het helpt je namelijk om heel anders tegen het begrip framework aan te kijken! 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, dan is het niet verstandig om Scrum precies volgens het boekje te doen. Toch gebeurt dit nogal eens door de echte Scrum-puristen. Sommigen 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 van toegevoegde waarde kan zijn. In een volgende blog zal ik hier meer aandacht aan besteden.

 

 

Drie golven

Mike Beedle, die met 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 21^st century'  (meer info) dat er 3 golven zijn met betrekking tot de ‘agility’ van organisaties.

 

De eerste golf betreft ‘single team agile’. Tot de eerste golf behoren o.a. 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 van Scrum (‘Agility at scale’ of ‘Scaling Scrum’) voor grote teams en organisaties: dit is momenteel een van de meest populaire 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). Zowel LeSS, SAFe als DAD maken veelvuldig gebruik van best practices, waaronder ‘Lean Thinking’, ‘Systems Thinking’ en ‘Design thinking’. Ook aan deze frameworks en practices zal ik in de toekomst regelmatig refereren.

 

Tot slot is er nog een derde golf met betrekking tot 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 zullen moeten meeveranderen om te kunnen overleven. Zoals de naam al 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’. Van origine is Scrum dus ontwikkeld als framework dat breder kan worden ingezet dan alleen systeemontwikkeling. Ook hierin zitten dus interessante elementen  voor de (agile) business analist. Meer in een volgend blog.

 

De bomen en het bos

Tijd voor een kritische kanttekening. Alle goede bedoelingen ten spijt, bovengenoemde golfbewegingen hebben geleid tot een enorm bos van frameworks en patterns waarin je snel kunt verdwalen! Het is verstandig om zelf de bruikbare bomen te ontdekken en te leren toepassen. Iedere ‘metrohalte’ op de onderstaande metrokaart van Deloitte kun je beschouwen als een practice. Wat werkt wel en wat werkt niet? Het is een vraag die veel agile teams dagelijks bezighoudt. En terecht.

 

 

_{Klik op de afbeelding voor een vergroting}

  

In de metrokaart 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. Gebruik een framework waar het voor bedoeld is, d.w.z. 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 zijn artikel ‘The Less Safe Dad – Acronyms in Agile’ 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 men mee worstelt. Hij 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 hen eens. In plaats van klakkeloos een framework te gebruiken, doe je er in mijn ogen veel beter aan een soort toolbox (of practice-box) samen te stellen waar je in ieder project uit kunt putten. Start ieder project met een simpele basis, bijvoorbeeld een Product Backlog en een Kanban en voeg daar elementen aan toe die van waarde zijn 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 items van de backlog halen en realiseren. Ontwikkeling op basis van Sprints bleek niet nodig. Het project leverde een goed resultaat binnen de afgesproken tijd en geld.

 

 

Tot slot

Business analisten hebben een mindset en motivatie om de organisatie waarvoor ze werken continu te verbeteren. Ze nemen vaak deel 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 stakeholders) en anderzijds door nieuwe technieken (practices) te introduceren waarmee (agile) projectteams kunnen worden verrijkt.

 

Met betrekking tot 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. Voordeel van frameworks is dat je een kant-en-klare set met practices naar binnen fietst. 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 (in de vorm van methoden en technieken). Ik zal hierover in toekomstige blogs verder uitweiden.