17 Jan 2017

Zijn stuurgroepen nog zinvol in een scrum en agile projectwerking ?

In de wereld van ‘Waterfall’ werd aan stuurgroepen heel wat verantwoordelijkheid toegedicht, van bewaking en toekenning van budget, over het bepalen van scope en de scope-changes tot de volledige eindverantwoordelijkheid over het projectresultaat.

Die stuurgroepen bestonden uit alle mogelijke stakeholders. Vaak ook stakeholders die zelf niet rechtstreeks begunstigden van de applicatie waren, maar wel een inbreng hadden in de context van de te ontwikkelen applicatie. We denken dan vooral aan personen met een juridische, financiële, marketing, maatschappelijke, bestuurlijke rol, enzoverder.

Stuurgroepen kregen in het verleden vaak een slechte naam omdat ze zich ook bezighielden met de inhoud, en dus de eigenlijke scope van de applicatie. Nochtans waren zij, als niet direct betrokkenen, daarvoor het minst geschikt. Met alle kwalijke gevolgen nadien.

In de Agile-wereld heeft men de Product Owner, een rol die alle stakeholders vertegenwoordigt.
De vraag rijst dan natuurlijk: Hebben we nog stuurgroepen nodig? Gaat dit niet in tegen de scrum-principes van de Product Owner als ‘master of the scope’, als de persoon die beslist over de scope en de backlog? Kunnen stuurgroepen nog zinvol zijn?

In de praktijk merken we dat je toch een orgaan nodig hebt dat geregeld samenkomt en ook personen vertegenwoordigt die niet direct betrokken zijn als gebruiker. Noem het een applicatiecontextgroep, een program of portfolio management groep. Of noem het ‘stuurgroep’.

De rol van deze stuurgroep is “het bijstaan van de Product Owner in het bewaken van de context van de applicatie”. Zeker in grotere projecten en bij de ontwikkeling van complexere applicaties, kan je moeilijk verwachten dat de Product Owner bij het realiseren van de business-value driven user stories ook nog de hele applicatie-context overziet. Daar kan de stuurgroep dan bijspringen. Deze stuurgroep bestaat naast direct betrokkenen ook uit personen die zicht hebben op de randdomeinen en in staat zijn om de impact en gevolgen daarop te begrijpen en aan te kaarten. Deze personen zijn niet betrokken bij de sprint-demo’s omdat zij zelf geen directe gebruikers zijn van de applicatie, maar zij kunnen wel oordelen dat bijvoorbeeld: 

  • de applicatie voldoende beveiligd is: Wordt owasp 10 gevolgd? Is er correcte authenticatie?
  • de applicatie conform is met maatschappelijke doelstellingen van de organisatie: vb. is de applicatie bruikbaar door mindervaliden?
  • de applicatie juridisch in orde is: Wordt de privacy-wetgeving gevolgd? Zijn de geproduceerde documenten rechtsgeldig?
  • de applicatie correct gepositioneerd wordt naar de buitenwereld toe: Wordt de buitenwereld op de juiste wijze geïnformeerd, zijn er voordrachten, blogs, … ?

De stuurgroep krijgt dus vragen voorgeschoteld en stelt zelf vragen over elementen die niet rechtstreeks bij het product zitten, of waarvoor de Product Owner ondersteuning nodig heeft.

En ja, de stuurgroep wordt ook geïnformeerd over scope/budget/tijd, de 3 elementen van de projectdriehoek, want ook Agile ontwikkeling ontsnapt niet aan de economische realiteit van tijd en geld. Want context-wensen geuit door de stuurgroep kunnen ook geld kosten en impact hebben op scope en timings.


 

 

 

 

 

Bovendien kan de stuurgroep als klankbord dienen als de product-owner worstelt met deze projectdriehoek.

 

Werkt dit ook daadwerkelijk in de praktijk ?

Ja, Qframe heeft ervaring met stuurgroepen in een Agile projectaanpak.

Een voorbeeld daarvan is het project Woningkwaliteit bij Wonen Vlaanderen, een agentschap van de Vlaamse overheid bevoegd voor woonpremies, woonsubsidies en het bevorderen van de woonkwaliteit.

In dit project komt maandelijks een stuurgroep samen. In deze stuurgroep zitten (vertegenwoordigers van) stakeholders die anders niet aan bod zouden komen, zoals personen van andere instellingen van de Vlaamse overheid, van Informatie Vlaanderen, van het kabinet voor het domein Wonen Vlaanderen, veiligheidsconsulenten van Wonen Vlaanderen, enzovoort.

Personen dus die niet rechtstreeks bij het project betrokken zijn als gebruikers, maar wel cruciaal zijn om de context van het project te bewaken. En ervoor zorgen dat de toepassing niet enkel business-value creëert voor de directe gebruikers bij Wonen Vlaanderen, maar voor alle burgers.

Zo besteden zij aandacht aan elementen als

  • de nieuwe toegankelijkheidsregels aangeleverd door Europa
  • de privacy-regels
  • beveiligingsaspecten
  • digitale handtekeningen
  • de integratie met Magda-platform van Informatie Vlaanderen
  • Oslo-standaarden

En ja, zij waken over de centjes, want ook projecten van de Vlaamse overheid hebben geen oneindig budget.