Scrum is hip. Vrijwel ieder bedrijf dat software ontwikkelt, heeft wel een of meerdere Scrum-teams. Het succes daarvan wisselt per organisatie. Iedereen wil het model van Spotify of Coolblue kopiëren, maar in de praktijk blijkt dat – vooral voor langer bestaande organisaties met veel legacy systemen – nog niet zo eenvoudig.
Waarom is het ene Agile-team succesvoller dan het andere? Dat heeft dat vrijwel altijd te maken met de mate waarin de teamleden snappen wat de businessdoelstellingen zijn en zich daarmee verbonden voelen. Kijk ik in de gemiddelde organisatie naar de betrokkenheid van mensen in het Scrum-team bij de businessdoelen, dan ben ik verrast. Het enige doel dat ontwikkelaars en testers hebben is op tijd de volgende sprint opleveren. Wat de bijdrage is van die sprint aan de strategie van de organisatie kan vrijwel geen enkel lid van Agile-teams uitleggen. Maar is dat niet waar het eigenlijk allemaal mee begint?
Beschikbaarheid belangrijk
Die betrokkenheid lijkt hoger in bedrijven die een sexy imago hebben, zoals Spotify of Coolblue. Managers wijten dat verschil vaak aan het feit dat zo’n sexy organisatie nu eenmaal meer aantrekkingskracht heeft op ontwikkelaars dan bijvoorbeeld de Belastingdienst of het UWV. Wat die managers vergeten is dat het gros van de ontwikkelaars niet werkt aan de allernieuwste features, maar aan de stabiliteit en beheersbaarheid van het platform. Wijkt het werk van een tester of ontwikkelaar in het infrastructuurteam bij Coolblue significant af van dat van diezelfde functionaris bij UWV? Ik denk het niet. Toch is de beschikbaarheid van de website van Coolblue anders dan die van UWV.
Mijn ervaring is dat dit vooral komt doordat ontwikkelaars in succesvolle infrastructuurteams weten: geen enkele klant zal van onze diensten gebruik kunnen maken als de beschikbaarheid van de website slecht is. Zij snappen hoe hun werk zich relateert tot de businessdoelstellingen van hun bedrijf. Zij begrijpen dat zij werken aan een weliswaar klein, maar onmisbaar deel van het platform.
Als je van Agile-werken echt een succes wilt maken, dan begint het met het verhogen van de betrokkenheid van de teams bij de businessdoelstellingen. Als je dat deel achterwege laat, zul je merken dat je wel Scrum kunt implementeren, maar dat je nooit de beloofde businesswaarde genereert.
Rajiv Harinandansingh, Agile-specialist bij Salves
Je kunt, dat is mijn ervaring, scrum teams weinig met elkaar vergelijken. UWV is nu eenmaal geen coolblue en KPN weer geen SWV. De scope, bouw en uiteindelijke implementatie verschillen te vaak en teveel van elkaar.
De success rate is dan natuurlijk te afhankelijk van verschillende factoren. Wat ik nog steeds zie gebeuren is dat a: IT professionals veel te summier betrokken zijn bij de processen van hun klanten en b: nog steeds veel te weinig echte zorg naar hun klant toe laten zien. De klant heeft nog steeds, negen van de tien, geen enkel idee of inzicht in de IT materie wanneer het op programmeren en onderhoud aan komt.
Ik heb dat altijd een bijzonder slechte situatie gevonden.
Systeembeheerder als Schaakgrootmeester, Projectmanager, Psycholoog, Bedrijfskundige, Trendwatcher.
Met al die DevOps kan de developer natuurlijk niet achterblijven.
“Strategie van organisatie”, “business doelstellingen.”
Wat zou de productowner gaan doen?
De tester is natuurlijk ook een held. En de Computable-experts, die leren ons dat allemaal.
Waarom niet de ontwikkelaars een dagdeel mee laten lopen met gebruikers? En aan het eind daarvan een (mini) brown paper sessie houden om ervaringen gestructureerd vast te leggen.
@Johan: een interessante gedachte, maar ik vraag me af of alle ontwikkelaars daar geschikt voor zijn.
Ik heb met ontwikkelaars gewerkt die in zo’n geval de klant gaan vertellen hoe de software te gebruiken in plaats van te luisteren naar wat de klant nu eigenlijk wil.
Het verschil tussen een uwv en een coolblue is mijns inziens dat het hoe en wat van een coolblue een ontwikkelaar veel meer aanspreekt omdat hij er zelf klant is, en snapt wat er speelt en hoe het als klant werkt.
Het uwv is voor velen veel verder van hun dagelijkse doen en laten, waardoor het veel abstracter wordt. Hier ligt de grote uitdaging voor een po.