Eisen van architecten buiten het Scrum Team

Een tijdje geleden werd mij gevraagd wat ik ervan vind om de "Wijze Architecten" van een bedrijf te belasten met het technisch toezicht op de verschillende projectteams. Ik hoor namelijk vaak het argument dat deze architecten geen deel uitmaken van het team en dus ook niet zouden moeten beslissen hoe het team iets ontwikkelt…

…dat is echter geen bijzonder sterk argument, want er zijn genoeg andere externe personen die eveneens eisen stellen aan een team. Deze eisen worden echter nog steeds gefilterd door de Product Owner – hij beslist of ze belangrijk zijn of niet.

„Wijze architecten" doen geen oplossingsvoorstellen

Een "Wijze Architect" geeft het team vaak niet-functionele eisen, die ik eerder als voorwaarden of randvoorwaarden beschouw. Hij kan het team dus niet voorschrijven hoe het een probleem moet oplossen. Maar hij kan wel bepaalde kaders meegeven, zoals: "Het systeem moet schaalbaar zijn naar een bepaald aantal concurrent users (gebruikers die tegelijkertijd het systeem gebruiken)", "het moet X transacties per minuut kunnen verwerken", "het moet op Linux draaien", "het moet integreerbaar zijn met dit en dat", etc.

Niet-functionele eisen worden Product Backlog Items en kunnen door de Product Owner geprioriteerd worden – afhankelijk van hoe belangrijk hij ze vindt. Als hij het bijvoorbeeld niet doorslaggevend vindt dat het systeem op Linux draait en het net zo goed op een ander besturingssysteem zou kunnen draaien, kan de Product Owner deze eis verwijderen of in de Product Backlog naar beneden verplaatsen (zodat het team in ieder geval nog kan zien dat de architect het graag wil).

Deze tekst is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.