Follow Us on Twitter

Implementeren van agile IT projectresultaten in de business

Gepubliceerd in

Juni 2013 - Agile zit in de lift. Steeds meer organisaties kiezen voor een agile aanpak van IT-projecten, bijvoorbeeld met Scrum. De voordelen van een agile aanpak zijn o.a. het snel leveren van resultaten, waardoor eerder baten gerealiseerd worden. Ook de grotere betrokkenheid van de opdrachtgever gedurende het project levert beter passende oplossingen op.

De door het project geleverde producten moeten echter wel "landen" in de business. "IT takes two to tango". Het project voor de business implementatie kijkt vaak nog op een niet-agile manier naar het IT-project en mist daardoor kansen.

Dit Whitebook geeft aan welke uitdagingen, kansen en mogelijkheden er zijn om de resultaten van agile IT-projecten op een effectieve manier te implementeren in de business.

Business-uitdagingen bij nieuwe IT-systemen

Alhoewel vaak gesteld wordt dat IT-projecten erg complex zijn, geldt dat zeker ook voor business implementatie-projecten. Het laten landen van nieuwe producten,  systemen en/of processen raakt vaak verschillende afdelingen en processen binnen een organisatie.

Veel business implementatie-activiteiten kennen een lange doorlooptijd. Denk bijvoorbeeld aan een HRM-afdeling die tijdig een sociaal plan moet maken omdat er een reductie in de bezetting wordt verwacht. Andere business implementatie-activiteiten kunnen pas plaatsvinden als er eerst IT-producten zijn opgeleverd. Een training kan bijvoorbeeld pas plaatsvinden als er een systeem beschikbaar is om mee te trainen.

Vanwege de complexiteit van de business implementatie wordt deze implementatie vaak projectmatig ingericht. Naast het IT-project draait er dan een tweede project, verantwoordelijk voor de business implementatie.

Samenwerking en een waterval-aanpak

In een traditionele waterval-aanpak werken beide projecten hun afhankelijkheden uit middels "product based planning” (een breed toegepaste PRINCE2-techniek). Simpel gezegd werken beide projecten de door hun te realiseren producten uit in "wat, hoe en door wie" en benoemen zij de onderlinge afhankelijkheden tussen deze producten. Hieruit ontstaat een planning per project waarbij rekening gehouden is met de onderlinge afhankelijkheden.

Beide projecten zullen vervolgens hard gaan sturen op het tijdig afronden van de afgesproken producten, omdat alle projectactiviteiten daarop afgestemd zijn.

Samenwerking en een agile aanpak

Agile IT-projecten plannen op een andere manier. In een agile project kunnen, net als bij een waterval-aanpak, ook op hoofdlijnen afspraken gemaakt worden over te leveren producten. Tijd en/of scope zijn echter variabel. Er kan dus wel een afspraak gemaakt worden over een specifieke datum, maar dan staat niet vastgesteld wat je precies krijgt. Of andersom, je weet wel wat je krijgt maar niet precies wanneer.

De producten worden stapsgewijs gerealiseerd. Met Scrum worden in iedere Sprint (een vaste periode tussen een of vier weken) extra functionaliteiten toegevoegd.  De opdrachtgever kan na iedere Sprint aangeven of die functionaliteiten genoeg toegevoegde waarde bieden om in productie te nemen.

Andere manier van denken

Agile denken is fundamenteel anders dan waterval-denken.

Waterval-denken kent een deterministische grondslag. Hierbij gaat men er van uit dat door goed na te denken, op basis van analyses en ontwerp, bedacht kan worden hoe de oplossing er uit moet zien. De gerealiseerde oplossing moet alleen nog getoetst worden of deze conform het ontwerp is gebouwd.

De agile manier van denken kent primair een empirische grondslag. De filosofie hierbij is dat kennis groeit door te ervaren. Door het in kleine stapjes realiseren van de oplossing kan getoetst worden of deze software voldoet aan de behoeften en kan in een volgende stap bijgestuurd worden.

In de praktijk zijn beide werkwijzen vaak niet zuiver deterministisch of empirisch, maar de basishouding is dat wel. Als vanuit de business implementatie vastgehouden wordt aan waterval-denken ontstaan spanningen. Het IT-project kan niet precies voorspellen welke functionaliteiten gereed zijn op welk moment. Het implementatietraject wil dat wel weten want hun werkwijze is daarop gebaseerd. Alle business implementatieproducten moeten gerealiseerd worden conform een van te voren vastgestelde scope en planning.

Waarom ook alweer agile?

Goed samenwerken vanuit beide visies is best mogelijk als er aan beide kanten wat water bij de wijn wordt gedaan. De vraag is echter of dit de meeste effectieve samenwerkingsvorm is. Waarom is er eigenlijk gekozen voor een agile IT-aanpak? Valt hieruit iets te leren voor de business implementatie?

Snel waarde creëren

Een agile IT-project levert snel waarde voor de opdrachtgever omdat de belangrijkste functionaliteiten als eerste worden opgeleverd en meestal al vroeg in het project.
Een waterval business implementatie verwacht pas aan het einde van het IT-project resultaten. Het is een gemiste kans voor de business als deze niet in staat is om de vruchten te kunnen plukken van eerdere opleveringen. Eén van de belangrijkste voordelen van de agile werkwijze wordt zo teniet gedaan.

Risicobeheersing

Agile projecten werken iteratief en incrementeel. Het product wordt ontwikkeld in stapjes. Hierdoor zijn technische- en business-complicaties snel zichtbaar en kan er corrigerend opgetreden worden.

Zeker vanuit businessperspectief geldt dat "the proof of the pudding is in the eating". Pas als het product gebruikt wordt is de business er zeker van of het product voldoet (of niet). Ook hierom zou het een gemiste kans zijn om te wachten met het in gebruik nemen van een oplossing tot het einde van het IT-project.

Aanpasbaarheid

Agile projecten zijn erg flexibel. Doordat het eindproduct in kleine stapjes wordt gerealiseerd kan na iedere Sprint opnieuw de scope voor de komende Sprint(s) vastgesteld worden. Het project is niet per se gebonden aan een van te voren vastgestelde scope, budget of doorlooptijd.

In een traditionele samenwerking tussen het IT-project en de business wordt strak gestuurd op change management. In principe (en soms uit principe) stuurt de projectmanager zoveel mogelijk op het voorkomen van veranderingen. De business is hieraan gewend (en er zelfs op ingesteld) en zal meestal alleen de discussie aangaan op "offspecs", op het niet voldoen aan eerder gestelde eisen.

De gemiste kans hierin is, dat het niet nodig is om "veranderingen van inzicht" tegen te gaan. Agile projecten zijn inherent adaptief en kunnen (binnen redelijke grenzen) meebewegen met veranderende inzichten. Omdat de buitenwereld niet stilstaat gedurende de levensduur van een project, zou het zonde zijn om nieuwe inzichten en veranderende omstandigheden niet mee te nemen gedurende het IT-project. Dan moet de business echter wel actief gebruik maken van deze mogelijkheid (een uitdaging op zich omdat de business case van veel projecten niet gedurende de levensloop van een project wordt getoetst).

Verbondenheid met klant/opdrachtgever

In een agile aanpak worden de requirements gedurende een Sprint uitgewerkt middels een intensieve samenwerking met de klant/opdrachtgever en meteen vertaalt naar werkende software. Dit leidt tot meer wederzijds begrip en beter passende oplossingen. Wat er aan het einde van een Sprint wordt opgeleverd is geen verassing voor degenen die tijdens de Sprint hebben meegedacht. Het is misschien wel een verrassing voor de "rest" van de business. De demo aan het einde van de Sprint is dan ook bedoeld om ook de overige stakeholders kennis te laten maken met de opgeleverde resultaten.

In de watervalaanpak vindt de functionele afstemming aan het begin van het project plaats middels het opstellen van ontwerpen. Pas aan het einde van het project krijgt de business te zien wat het IT-project gedaan heeft met de requirements. Als de business vanuit deze ervaring omgaat met agile projecten, is mijn ervaring dat er te laat serieus gekeken wordt naar de tussentijdse opleveringen. Het is voor veel mensen moeilijk om een waardeoordeel te geven over software die nog in ontwikkeling is. Dat is een gemiste kans, want hoe meer software gemaakt is, hoe duurder het wordt om deze software aan te passen.

Agile business implementatie

Hoe werkt het dan wel? Wat is een goede manier om optimaal gebruik te maken van de voordelen van een agile IT-project?

Persoonlijk geloof ik niet in een "silver bullet". Er bestaat geen recept om de business implementatie agile aan te pakken dat altijd goed werkt. Toch is er wel een empirische stelregel waar ik in geloof en die in de praktijk bewezen is. Vanuit deze stelregel maak ik op maat inrichtingskeuzes per project, afhankelijk van de projectopdracht en de omgeving.

"Je weet pas wat je krijgt als je het hebt".

  • Je weet pas wat je aan een oplossing hebt als je er mee werkt 
    (in tegenstelling tot een functioneel ontwerp).
  • Je weet pas hoe je software moet gebruiken als je achter de knoppen zit 
    (in tegenstelling tot een training vooraf met Powerpoint en een gebruikershandleiding).
  • Je weet pas wat de technische risico’s zijn als de risicovolle onderdelen zijn gerealiseerd 
    (in tegenstelling tot eerst een technisch ontwerp maken).
  • En ga zo maar door.

De beste manier om het meeste te halen uit een agile project is een manier waarbij de business implementatie volledig agile meebeweegt met het project, inclusief acceptatie, training en inproductiename.

Een voorbeeld

Een aanpak die ik graag toepas is het iteratief proefdraaien. Proefdraaien is het zo goed mogelijk nabootsen van de feitelijke productie in een beperkte hoeveelheid tijd met een voorbereide scope en bezetting:

  1. In een proefdraaiplan is uitgewerkt welke mensen welk deel van het bedrijfsproces en voor welk business product gaan proefdraaien. Omdat het project meerdere keren software op gaat leveren, komen er ook meerdere proefdraaisessies.
  2. Iedere sessie wordt van te voren voorbereid met een aantal “cases” uit de productieomgeving.
  3. Tijdens een proefdraaisessie wordt de productiesituatie geoefend met de voorbereide cases. Een begeleider houdt toezicht op de sessie en ondersteunt waar nodig.
  4. Aan het einde van de sessie bespreken de deelnemers het proces en de resultaten. Op basis van de opgedane ervaringen wordt vastgesteld wat de meest effectieve werkwijze is om met het systeem te werken. Tevens wordt deze werkwijze vastgelegd als "best practice". Deze vastgelegde "best practices" maken een document met gedetailleerde werkinstructies overbodig. Eventuele bevindingen op het systeem worden teruggekoppeld aan het IT-project.

De proefdraai-aanpak heeft de volgende voordelen:

  • Een aparte opleiding is overbodig geworden. De proefdraaisessies fungeren mede als handson opleiding.
  • Proefdraaien is een vorm van accepteren geworden. In een agile project is de ultieme vorm van acceptatie de constatering van de business dat de gerealiseerde oplossing in de praktijk voldoet aan de behoeften. Door middel van proefdraaien kan dit geconstateerd worden.
  • Hierdoor worden ook vroegtijdig risico’s gemanaged omdat de oplossing getoetst wordt in een bijna-productieomgeving.
  • Ook kan vroegtijdig, op basis van ervaringen met het systeem, door de business geconstateerd worden of de oplossing goed genoeg is om in productie te nemen en waarde te creëren.
  • Proefdraaien is een erg goede manier om de business vroegtijdig en op een erg serieuze manier bij het project te betrekken. Demo’s zijn niet overbodig geworden en hebben nog steeds waarde om een brede groep aan stakeholders te betrekken bij het project.
  • Doordat ook andere onderdelen van de business intensief bij de voortgang van het project betrokken zijn en hierin feedback kunnen geven wordt de organisatie in zijn geheel meer wendbaar. Er komt meer feedback terug en het project kan hier meer mee doen.
  • Meten is weten. Het proefdraaien levert cijfers op over efficiency en doorlooptijden die gebruikt kunnen worden om de impact op de bestaande bezetting te berekenen.

Bezwaren

De meeste bezwaren die gemaakt worden tegen het iteratief proefdraaien gaan over het niet kunnen missen van de mankracht. Organisaties die al gewend zijn aan agile projecten weten dat de investering in samenwerking zich terugverdient bij de inproductiename. Zeker als daarmee tegelijkertijd de acceptatietest en trainingsbehoefte is ingevuld. Bij meer traditioneel ingestelde organisaties is het soms nodig de spiegel voor te houden over de effectiviteit van de gebruikelijke business implementatie aanpak.

Soms wordt als bezwaar genoemd dat mensen niet goed tegen veranderingen kunnen en het niet prettig vinden iedere keer met gewijzigde software geconfronteerd te worden. In mijn ervaring vinden de meeste mensen veranderingen niet prettig als zij geen invloed uit kunnen oefenen op die veranderingen. In een agile aanpak is er juist alle gelegenheid om invloed uit te oefenen op die veranderingen.

Vaak wordt de business implementatie onderschat. Gewoon even trainen en procedures aanpassen is dan het beeld. Het proefdraaien wordt dan als een erg zwaar middel gezien om een beperkt risico te managen. Natuurlijk is het mogelijk dat de business implementatie inderdaad niet moeilijk is. Echter, mijn stelling is dat je dat pas weet als je het uitprobeert. Het proefdraaien zou ik dan als risicomaatregel voorstellen in een beperkt aantal sessies. Eventueel kan het proefdraaien in een afgeslankte vorm ingezet worden als hulpmiddel bij de acceptatie.

Conclusie

Agile wordt steeds populairder, maar de agile aanpak komt vaak niet voorbij de grenzen van IT. Dat is een gemiste kans want de voordelen van een agile aanpak komen pas echt tot hun recht als de business "agile" kan meebewegen met het IT-project. Dat is uiteindelijk ook waar ieder IT-project voor bedoeld is, het creëren van waarde voor de business.

Dit Whitebook geeft vooral aan wat de andere manier van denken is wil je als business agile mee kunnen bewegen: "Leren door te doen". Het proefdraaien is een mooi voorbeeld van zo’n aanpak, maar bij ieder project zal de aanpak voor een agile business implementatie op maat moeten worden vastgesteld.

Waardering:
 

Reacties

Dag Martin,

'Leren door te doen' aan de business zijde sluit inderdaad goed aan bij Scrummen.

Aan het begin van je artikel haal je ook de brede context van de business implementatie aan. Ik denk naast jouw HRM-voorbeeld ook aan communicatie, stuurinformatie of huisvesting. In de verdere uitwerking van het artikel focus je op training en ingebruikname van de software vanuit business perspectief.

Hoe kijk je naar scrummen in relatie tot de brede scope van een business implementatieproject? Deze activiteiten buiten scope plaatsen, lijkt mij niet wensenlijk. Of de scrumresultaten 'stapelen' totdat je vanuit proefdraaien meent een nieuwe mijlpaal te hebben bereikt om deze business implementatie-activiteiten te starten?

Groet, Sven Koopmans

Hoi Sven,

De vraag die gesteld wordt (of zou moeten worden) bij ieder agile project is hoe je snel waarde kan creeren. Primair kan waarde alleen gecreerd worden als jouw product of dienst daadwerkelijk wordt afgenomen door een klant. Door het beantwoorden van deze vraag wordt automatisch vastgesteld in welke breedte de tussentijdse implementatiestappen uitgevoerd moeten worden.

Voorbeeld:
Er wordt een nieuwe winkelformule opgezet met nieuwe producten, locaties, personeel, etc. Een COPAFIJTH brede implementatie. Een agile keuze kan dan zijn om eerst één locatie in te richten en op basis van de geleerde lessen daarna steeds een locatie uit te breiden. Een andere agile keuze kan zijn alle locaties in te richten maar eerst met een beperkte selectie aan producten te beginnen.

Zoals je ook zelf aangeeft is er vaak een verschil in tempo in het realiseren van de verschillende deelproducten. Je hebt dan soms geen keuze om te 'stapelen' totdat een gemeenschappelijke mijlpaal is bereikt en een minimaal 'werkend business product' is gerealiseerd. Het buiten scope plaatsen is inderdaad geen goed idee. Er wordt minder goed gestuurd wordt op de samenhang en het belang van samen snel optrekken naar een werkend tussenresultaat is minder zichtbaar. Met een agile aanpak zou het doel moeten zijn dat alle belanghebbenden iedere keer samen werken naar dat tussentijdse resultaat.

Specifiek voor communicatie, zeker als het gaat om interne belanghebbenden, zou ik zeggen dat iedere agile iteratie een communicatiekans is. Ook als het onderhanden product nog niet goed genoeg is, is het wel belangrijk om de voortgang te delen en betrokkenheid vast te houden.

Mijn antwoord is noodgedwongen wat generiek van aard. Neem gerust contact op als je nog een vraag hebt dan nemen we de context door.

groet,

Martin

 

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.