Sommige analisten beweren dat de veranderingen door agile en scrum wel meevallen. Ik denk dat deze analisten de impact onderschatten. Of dat ze in een hybride omgeving werken die meer traditioneel dan agile is.
Agile en scrum hebben de wijze waarop we software ontwikkelen behoorlijk veranderd. De verschillen tussen een traditionele en een agile aanpak zijn groot. Dit heeft voor alle IT-disciplines grote gevolgen gehad.
Hier volgen de 5 grootste gevolgen die agile voor ons requirementsvak heeft gehad.
1. Brugfunctie
We zeiden vaak dat requirements de brug vormen tussen business en IT. Traditioneel is het de taak van analisten om de requirements uit te vragen bij de business stakeholders en deze eenduidig vast te leggen. Vervolgens gingen ontwerpers, ontwikkelaars en testers op basis van de requirementsdocumentatie aan het werk.
In agile is het achterhalen van requirements geen taak meer van een analist. Het voltallige agile team is er actief bij betrokken. De analist faciliteert hooguit de kennisoverdracht van business naar agile team. De ontwikkelaars vernemen zelf direct van de stakeholders wat hun wensen zijn. Daar hoeven ze dan geen uitgebreide requirementsdocumenten meer voor te lezen.
2. Kennisoverdracht
Analisten waren altijd verantwoordelijk voor de requirements. Zij hadden een dagtaak aan het opstellen van de requirements. Hierdoor bezaten zij de kennis over de wensen van de business. Die kennis droegen ze voornamelijk schriftelijk over aan de andere projectleden.
In agile hoeft een analist zijn kennis niet over te dragen aan het team. De ontwikkelaars gaat namelijk zelf rechtstreeks in gesprek met de product owner en andere vertegenwoordigers van de business. Tijdens refinements bijvoorbeeld vernemen alle teamleden de requirements uit de eerste hand. Daardoor is overdracht van kennis na de sessie niet meer nodig.
3. Oplossing
Analisten zijn gewend een strikte scheiding aan te houden tussen het Wat en het Hoe. Dus tussen respectievelijk requirements en (technische) oplossingen. We zeggen altijd dat de business gaat over het Wat en de IT’ers over het Hoe.
In agile geldt nog steeds dat te vroeg in oplossingen denken een valkuil is. Het is nog steeds belangrijk eerst de behoeften van de business helder te hebben. Maar in de meeste agile meetings worden requirements en (functionele) oplossingen in samenhang besproken. De vertegenwoordigers van de business en ontwikkelaars wisselen ideeën uit en denken met elkaar mee. Ze zijn sparringpartners geworden met ieder hun eigen achtergrond en expertise.
4. Businesswaarde
Bij traditionele systeemontwikkeling is alles gericht op de gedefinieerde en goedgekeurde requirements. Zo stuurt een projectmanager op basis van de gedefinieerde requirements. En implementeert een ontwikkelaar en test een tester de goedgekeurde requirements. Afhankelijk van de kwaliteit van de requirements levert het systeem meer of minder businesswaarde.
In agile zijn alle teamleden gefocust op het maximaliseren van de businesswaarde. Dit doen ze door al na enkele sprints een systeemincrement op te leveren dat toegevoegde waarde heeft voor de business. Die software breiden ze dan iedere sprint uit met meer businesswaarde.
Het systeem groeit zo van een zeer eenvoudig systeemincrement naar een volwaardig systeem. In het begin heeft de software slechts beperkte businesswaarde voor een subgroep van de gebruikers. En stap voor stap wordt de businesswaarde steeds groter en voor steeds meer gebruikers interessant.
5. Kwaliteit
De volledigheid, juistheid en eenduidigheid van traditionele requirements is erg belangrijk. We spraken vaak over SMART requirements. Analisten besteedden daar veel aandacht aan. We pasten allerlei methoden en technieken toe om de kwaliteit van de requirements te verhogen.
Door de businesswaarde gedreven manier van ontwikkelen is dat in agile projecten niet meer nodig. Het systeem en dus ook de requirements hoeven niet in één keer goed te zijn. En ook de kwaliteit is niet echt meer van belang. In agile laat je de requirements en het systeem geleidelijk ontstaan. Het agile team én de business ontdekken gaandeweg de echte behoeften van de stakeholders.
Meer verschillen tussen traditionele en agile requirements
Natuurlijk zijn er nog veel meer verschillen te noemen. Dit zijn de 5 belangrijkste die ik je mee wil geven. Welke verschillen zou je daar aan toe willen voegen? Zet je aanvullingen of opmerkingen in het reactieveld hieronder. Ik kijk ernaar uit.
Nicole de Swart
In je punt 3 geef je aan dat de informatieanlist vroeger over het WAT ging en het team ging over de “HOE”. In Agile ligt de “HOE” vraag nog steeds bij het team, terwijl de “WAT” vraag meer bij de PO ligt.
Ik durf te stellen dat de Anslist van vroeger is de PO van nu!
De PO is toch de vertegenwoordiger vna de Business. I zeg niet dat de analist deze rol niet op zich kan nemen, maar er si wel een duidelijk onderscheid. Mijn ervaring is dat de anlist optreedst in de rol van scrummaster en verantwoording heeft voor hetgeen opgeleverd moet worden.
Ik ben het grotendeels eens met Mouloud. Er is een verschuiving van IT naar de business. De business zit eindelijk aan het stuur en bepaalt de richting, de toeristische stops e.d. van de reis. IT drijft de motor aan.
Dit is volgens mij ook het grootste risico dat je bij Agile hebt. De business moet een belangrijke verantwoordelijkheid nemen maar is die daar klaar voor? Kan die dat? Lopen de discussies op voet van gelijkheid waarbij de business het laatste woord heeft of vallen we terug op oude gewoonten?
Datzelfde risico heeft ook een impact op IT. Vroeger hadden zij het in grote mate voor het zeggen. Nu moeten ze ‘macht’ afgeven. Willen ze dat, kunnen ze dat?
Daarbij komt nog dat Agile over softwareontwikkeling gaat (en dat pakt het goed aan). Wat met de rest van het project? De hardware, het change management?
Functionaliteit bepaalt niet langer de acceptatie (die vind je op elke hoek van de straat). Niet functionele behoeften bepalen het succes. Door de eenzijdige nadruk op softwareontwikkeling gaat de rest van het project verloren. Vroeger (voor internet) zat 84% van de risico’s in het functionele gebied en 16% erbuiten. Nu is dat netjes omgekeerd: 16% voor de functionaliteit, 84% voor de niet functionele kenmerken en daarvan is bijna de helft ‘bruikbaarheid’.
Het kan lijken dat ik niet voor Agile ben, niets is minder waar. Het is wel noodzakelijk dat we beseffen dat Agile maar een deel van de oplossing is. Een benadering uit meerdere gezichtspunten (wat het moet doen, hoe het moet werken en hoe we het zullen bouwen) is volgens mij noodzakelijk. Projecten zijn meer dan softwareontwikkeling alleen.
Ik zie voor de informatieanalist ook wel een rol als deelnemer aan het agile team. Er zal toch iemand de organisatie in moeten om de specs helder te krijgen en dat kan (bij grotere organisaties en systemen) veel tijd kosten. Of als rechterhand van de PO. Idealiter is de PO iemand van enig gewicht in de organisatie die toegang heeft tot stakeholders op alle niveaus en voldoende overzicht heeft om belangen tegen elkaar af te wegen en de juiste keuzes te maken. Een analist kan voorbereidend werk doen, informatie en wensen verzamelen en presenteren aan de PO zodat die weloverwogen keuzes kan maken. Ik ben het met Rik eens dat er een groot risico in de non-functionals zit. Het agile team zou minstens één persoon moeten hebben die dit goed bewaakt en zorgt dat deze voldoende zijn opgenomen in de ‘definition of done’.
Verwachten dat de PO zomaar met het team op gelijke voet kan communiceren, is dikwijls een brug te ver. De PO moet de business kant bewaken maar van technologie heeft die meestal geen kaas gegeten. Hem/haar ondersteunen met een informatieanalist, een interface designer kan wel helpen. Deze mensen kunnen deze communicatie met het team aan omdat ze voldoende technische bagage hebben. Zij hebben (of zouden moeten) voldoende feeling om wat de business wil te vertalen. De informatieanalist en/of user interface designer kunnen ook de niet-functionele behoeften bewaken. De user interface designer heeft hier het voordeel dat die vooral naar bruikbaarheid kijkt (en daar zit ook performantie, beschikbaarheid … in) en dit is het grootste struikelblok bij nieuwe systemen. Het belang ervan is trouwens sterk toegenomen.
De rol van analist komt niet voor in Scrum, maar de kennis en vaardigheden blijven belangrijk. Zowel de PO als andere leden van het agile team moeten over (een deel van) de vaardigheden van de traditionele analist beschikken. Als de PO (iemand van de business met gewicht en aanzien) of de teamleden die vaardigheden onvoldoende bezitten, dan zou ik een analist opnemen in het agile team. De PO kan eventueel werk delegeen aan het team. Andere optie is een analist als rechterhand van de PO.
Je zou kunnen zeggen dat een PO een combinatie is van de traditionele requirementsanalist, projectmanager én productmanager. Lees hierover http://www.reaco.nl/blog/product-owner/
Het belang van requirementsmanagement lijkt onderbelicht. Bij systemen van enige omvang moet duidelijk zijn wat het systeem voor de business doet. Het heeft de schijn dat het bij agile werken niet uit de verf komt en na X sprints alleen bij het scrum team goed bekend is wat het systeem kan.
Volgens mij is dat niet wenselijk voor continuiteit en onderhoudbaarheid.