It-projecten hebben al langere tijd een negatief imago. Het feit dat de mislukte it-projecten bij de overheid momenteel breed uitgemeten worden in de Nederlandse media, draagt hier natuurlijk ook niet aan bij. Cerios, expert op het gebied van it-projecten, gelooft dat zelfs de meest complexe projecten succesvol kunnen verlopen. Daarom organiseerde het bedrijf samen met Computable een rondetafeldiscussie, waar experts uit alle hoeken bijeen kwamen om eens van gedachte te wisselen over succesvolle it-projecten en om van elkaar te leren.
De rondetafeldiscussie werd door Cerios en Computable geïnitieerd. Vertegenwoordigers van Ordina, Tata Steel, Cerios, Agentschap BPR, IonIT, en A/I/M namen deel. Verslag van deze discussie verschijnt in een driedelige artikelenreeks, waarin de startfase van het project, de uitvoering en techniek en de vorm van het project aan bod komen. Het eerste deel verscheen al eerder. Hieruit bleek al dat de term ‘succes’ moeilijk te definiëren is en van veel verschillende factoren afhankelijk is. Businessanalyse en een goede business case bleken key in de weg naar een succesvol project, maar moeten niet in alle gevallen leidend zijn. De uitvoering van het project bleek ook een belangrijk component. Agile is de laatste jaren in gebruik, en dit bleek ook een belangrijk onderwerp in relatie tot succesvolle it-projecten.
Continuous delivery
‘We kunnen wel stellen dat Agile ons de laatste tijd veel heeft gebracht’, meent Bob van Zeist, managing director bij Cerios. ‘Alles wat je nodig hebt is wendbaarheid in deze tijd, en dat realiseer je met Agile.’ Projectleider Reza Sarshar van IonIT geeft aan dat om succes te realiseren, het wel noodzakelijk is om de adoptiegraad te verhogen. Er zit doorgaans nog veel werk in ontwikkeling en beheer, maar binnen de organisatie is er sprake van weinig adoptie. Een succesvol project zonder adoptie binnen de organisatie? ‘Onmogelijk’, aldus Reza Sarshar.
Om de adoptiegraad op te krikken, blijkt Agile-werken erg belangrijk. ‘Juist kleine stukjes sneller opleveren waar de business meteen mee aan de slag kan, zal leiden tot meer adoptie’, concludeert Van Zeist. ‘Ik zie in de praktijk dat nieuwe software middels Agile wel snel ontwikkeld wordt, maar dat er problemen ontstaan bij het in productie nemen ervan. De kleine losse releases worden door beheer vaak opgespaard tot één grote release, aangezien de productiegang een zeer foutgevoelig proces is. Continuous delivery adresseert dit probleem. In feite richt continuous delivery zich op het continu en met een zo kort mogelijke doorlooptijd in productie nemen van wijzigingen. Met continuous delivery worden zo veel mogelijk taken, die verricht moeten worden om in productie te gaan, geautomatiseerd. Denk daarbij aan testautomatisering. Continuous delivery gaat in op een hele andere benadering van de keten van software-ontwikkeling en -beheer en past perfect binnen een Agile-werkwijze. Het is een actueel thema waarmee je het niveau van Agile-werken naar een hoger niveau tilt.’
Agile niet het toverwoord
Toch is Agile niet de heilige graal volgens projectmanager Leendert Hinds van Tata Steel. In zijn optiek heeft iedereen het te snel over Agile, terwijl dit niet altijd de beste methode is. Bij Tata Steel worden diverse methodieken, zowel waterval als Agile, toegepast. Dit is afhankelijk van het soort project, de technische omgeving en het ontwikkelteam. Van Zeist vult aan: ‘Agile is zeker niet het toverwoord en er zijn ook zeker Agile-projecten die mislukken. Organisaties waarbij wendbaarheid centraal staat en die verandering als onderdeel van hun bedrijfsstrategie hebben, hebben absoluut baat bij Agile.’
Van Zeist wijst op het verschil tussen overheidsinstanties en commerciële organisaties. ‘Waar de overheid vooral stabiliteit en continuïteit nodig heeft, zijn commerciële organisaties veel meer gebaat bij wendbaarheid en flexibiliteit om te kunnen concurreren.’ Ben Zwartveld van Agentschap BPR vindt dat Agile ook de overheid veel voordelen kan bieden. In sommige situaties is het volgens hem zeker nuttig om middels Agile te werken. ‘Ook voor projecten die middels waterval worden ontwikkeld, maar ondertussen helemaal vastgeroest zijn, kan Agile een enorme uitkomst zijn’, vult directeur projecten Fred Bons van Ordina aan. Hij maakt in de praktijk vaak mee dat vastgelopen projecten middels Agile weer vlotgetrokken kunnen worden.
Kritische noot
Naast de vele voordelen van Agile die ter tafel komen, is er ook ruimte voor een kritische noot. Ben Zwartveld ziet dat Agile soms ‘misbruikt’ wordt om zomaar wat te rommelen. En ook Reza Sarshar constateert dat sommige organisaties soms aan een Agile-project beginnen zonder een visie. Hoe kun je onzekerheden binnen een Agile-project wegnemen als je niet vooraf weet wat je precies wilt maken, aldus Sashar.
‘Wat veel mensen vergeten is dat het tijdspad, het budget en de requirements bij Agile ook gewoon vooraf worden vastgelegd’, antwoordt Fred Bons, directeur projecten bij Ordina. ‘Door een goede business case en doelstellingen kan je flink wat onzekerheden wegnemen, maar onzekerheid blijf je altijd houden door het proces en mechanisme.’
Voedingsbodem voor wendbaarheid
Het is opvallend dat in de discussie rondom succesvolle it-projecten, Agile vrijwel direct aan bod komt. Ondanks de verschillende meningen erover, zijn de deelnemers het wel over één ding eens: wil je wendbaarheid, dan is Agile een prima voedingsbodem. Agile dient toegepast te worden waar dat geschikt is. Kennis over wat Agile nu precies is, blijkt nog wel een heikel punt. Maar maakt Agile zijn belofte wel volledig waar en is het geschikt voor hele grote, complexe it-projecten? In het laatste deel van deze artikelenreeks is terug te lezen hoe kopstukken uit de markt hierover denken.
Deelnemers
Reza Sarshar, projectleider bij IonIT
Leendert Hinds, projectmanager en business consultant bij Tata Steel Europe
Fred Bons, directeur projecten bij Ordina Nederland en bestuurslid van IPMA Nederland
Ben Zwartveld, business architect bij agentschap BPR
Bob van Zeist, managing director bij Cerios
Steven van ‘t Veld, business & information analist bij A/I/M
Gespreksleider: Sander Hulsman, hoofdredacteur a.i. bij Computable
Lees ook deel 1 in deze serie.
De term Succes is inderdaad moeilijk te definiëren. Dat is ook het geval met Kwaliteit. Subjectiviteit is echter moeilijk te elimineren.Belangrijk uitgangspunt voor het meten van Succes is echter de businesscase of investering voorstel. Dit document geeft de basis voor het meetbaar maken van Succes. Maar wie bepaalt het Succes? Ook bij ICT projecten kun je stellen dat het succes bepaald wordt door drie stakeholders: de opdrachtgever, de gebruiker en de opdrachtnemer/projectmanager.
Agile is geen methodiek. Agile is een visie verwoord middels een manifesto ( http://agilemanifesto.org/ )
Scrum is de meest voorkomende implementatie van Agile.
Agile richt zich op 1 primair doel ; Werkende ****software**** Als je allerlei projecten dus Agile noemt, is dat vaak uit naam, of door wat te lenen uit het gedachten goed.
In mijn ogen lijkt het me lastig om Agile te werk te gaan en toch compliant te zijn.
Agile is in mijn ogen vooral een injectie van vitamine A: Aandacht. En door eigenlijk werk op te delen in hele concrete brokken en hier dagelijks kort over te communiceren, kan er ineens sneller resultaat gemaakt worden wat ook nog eens zichtbaar is.
Agile als de heilige graal maar de waarheid zit wat mij betreft in de laatste alinea. Daarin wordt gesteld dat wat Agile precies is een heikel punt is. We willen allemaal Agile werken maar weten eigenlijk niet wat het is. Wendbaarheid lees ik. Agile is geen methode maar een filosofie zoals beschreven in het Agile manifesto, zoals Henri schrijft. Toegegeven, van dat manifesto word je ook niet veel wijzer daarvoor is het te vaag en onduidelijk.
Dus je moet er zelf een draai aan geven. Wendbaarheid wordt genoemd maar schreef het een moment terug ook in de software ontwikkeling ben je maar beperkt wendbaar. Je maakt keuzes die ook weer je mogelijk -en onmogelijkheden bepalen. Agile gaat naar mijn mening meer over onzekerheid. Je weet op voorhand niet precies waar het heen moet en hoe je we er wilt komen. Voortschreidend inzicht moet het doen. Zo werkt het met softwareontwikkeling. Je vangt aan maar al doende wordt het probleem en de oplossing steeds helderder, je gooit wat weg, je herschrijft eens wat en zo wordt de software opgebouwd. Hetzelfde zal gelden voor de gebruiker/klant/bussiness, ook daar zal in de tijd steeds duidelijker worden wat je wilt hebben. Deze onzekerheid ruimte geven is naar mijn mening de clou van Agile. Wil je wendbaar zijn dan zul je moeten weten waar de rek in moet zitten en daar rekening mee houden bij het ontwikkelen. Agile is geen synoniem voor van de hak op de tak springen of zomaar het roer omgooien.
Scrum is de methode die in één adem met Agile wordt genoemd en waarbij hoort dat er in stapsgewijs opgeleverd wordt. Dat is zinvol om stapsgewijs naar een resultaat toe te werken maar Scrum gaat naar mijn mening niet over de inhoud (hoe ontwerp en bouw je, wat moet er geleverd worden) maar gaat meer over het proces. Zie ook dat de invulling hiervan alle kanten op kan, van de meewerkend voorman die middels scrum de gang erin houd tot scrummasters en productowners die geen affiniteit met ICT hebben die leidend zijn. Wat dat betreft is scrum net zo vaag als de term agile. Nou ja, wel iedere ochtend bij elkaar staan, gele postit papiertjes verplaatsen en de grote todo lijst afwerken. De zoektocht naar de ware scrum is nog een hele opgave en moet je oppassen dat het niet belangrijker dan de inhoud wordt. Scrum en de andere procesbegeleidings methodes (de leans, kanbans en wat het ook mag zijn) gaan ook meer over het controleren en monitoren van een softwareontwikkelingsproces. Maar ik denk er meer controle gesuggereerd wordt dan het in werkelijkheid is en software inhoudelijk levert het niets. Begrijp wel dat zinvol is middels deze methode de gang erin te houden maar een goede projectleider zou dat niet nodig hebben denk ik.
Nu spreken de woorden van Ben Zwarveld me aan, agile wordt ook misbruikt om wat aan te rommelen. Nu heb je daar denk ik geen agile en scrum voor nodig om wat aan te rommelen. De JBF methode en gezond verstand kunnen ook prima werken.
Ik zie agile als een gedachtegoed, een concreet gemaakte attitude waar je veel voordeel van kunt hebben in gevallen dat de Agile werkt. Je moet wel na blijven denken. Je kunt met een schroevendraaier een spijker in de muur proberen te rammen maar efficient is dat niet. In dat geval gebruik je beter een hamer en daarom heeft een timmerman een kist met diverse gereedschappen.
Henri, 3 opmerkingen van mijn kant:
1) Het concept achter Agile is zelforganisatie. Daarbij draait het om een (vaak) multidisciplinair dat mandaat heeft om zelf beslissingen te nemen (binnen kaders). Dat heeft an sich niet zo veel met software te maken – je kunt het ook ’tastbare resultaten’ noemen. Voor mij is een project Agile als het een multidisciplinair team betreft, dat frequent tastbare resultaten laat zien en frequent interacteert met een klantvertegenwoordiger (product owner).
2) Agile en compliant zijn is helemaal niet tegenstrijdig, want je kunt gewoon als eis stellen dat de oplevering aan het eind van de sprint voldoet aan alle compliancy regels. Soms is het wel lastig om bijv. audits per sprint te laten uitvoeren, maar de maatregel is dan om een auditor een rol te laten spelen binnen de sprint, zodat de kans dat het team niet voldoet aan die richtlijnen geminimaliseerd wordt. En pas in een later stadium doe je dan een formele (externe) audit. Idem dito voor bijv. complexe ketentests: organiseer een behapbare (80/20 regel!) feedback loop in de sprint, dan minimaliseer je de risico’s.
3) Jazeker, de mensfactor is een belangrijke. Maar er is meer: ook visualisaties zoals het Scrumboard werken krachtig. En korte feedback loops ook. En een gezamenlijk doel werkt ook. En een klantvertegenwoordiger met mandaat ook. Agile is meer dan alleen het opdelen in brokken.
Inderdaad de laatste alinea stelt een leuke vraag:
Maar maakt Agile zijn belofte wel volledig waar en is het geschikt voor hele grote, complexe it-projecten?
Mijn idee -als overtuigd agilist- hierbij is dat er GEEN ENKELE methode geschikt is om hele grote, complexe IT-projecten te doen. Agile leert ons 1 ding: knip het op, beperk de complexiteit en ga wat DOEN terwijl je denkt. Ieder groot en complex IT-project is gedoemd te mislukken, ongeacht de methode. Volgens mij wordt ons dit feilloos aangetoond in de politieke rondedans rondom mislukte IT-projecten.
Zoals Henri al aangeeft is agile geen methodiek, verre van dat zelfs als ik kijk naar manifesto welke kort samengevat neer komt op:
1. Mensen gaan boven de processen
2. Werking gaat boven documentatie
3. Samenwerking gaat boven contracten
4. Veranderingen gaan boven een plan
Volgens mij conflicteren bovenstaande punten met elke wijze van governance, niet de complaincy is het probleem maar het ‘in control’ zijn als van plan tot proces alles ondergeschikt is gemaakt aan de bezigheidstherapie van agile. Fred Bons is blijkbaar een evangelist van agile want ook al worden de dingen vooraf vastgelegd het blijft uiteindelijk een kruiwagen vol met kikkers welke er nog weleens onderweg uit willen springen als deze in beweging komt. Agile is dus zeker niet de heilige graal omdat de mensen zelf allesbehalve heilig zijn en leuk voor software ontwikkeling maar totaal ongeschikt voor project management.
Betreffende de 80/20 regel van Anko kan ik stellen dat het vijfde deel vaak voor de hoogste kosten zorgt omdat er nog te vaak met een ‘point of no return’ gewerkt wordt in dit soort projecten, er wordt aan het begin nog weleens wat vergeten dat achteraf belangrijk blijkt te zijn. Zo is Continous Delivery een leuke ontwikkeling maar kent ook iets als Continuous Integration, volwassenheid is hier soms nog ver te zoeken wat agile devalueerd tot ’trail-and-error’ met dus alle daar bijbehorende frustraties. Om even terug te komen op mijn reactie naar Reza bij eerste deel, als ik me niet vergis is uit die frustratie een ontwikkeling als DevOps voortgekomen welke de Continuous Delivery in moet vullen.
Gezien het feit dat telkens het woord continuous terug komt kan ik wel stellen dat het niet aan de definitie van een project voldoet, het is meer beheer waarbij processen, documentatie, contracten en een plan nodig zijn. Ik zal niet in gaan op het door Anko genoemde aspect zelforganisatie als het om de overheid gaat maar wendbaarheid werkt alleen als ook de organisatie daarvoor geschikt is, kras het vakje ongeschikt in dat geval maar aan als het om de overheid gaat. Reden daarvoor is even simpel als logisch want de overheid is een publieke organisatie die weliswaar geen concurrentie kent maar wel democratische controle.
Grappig om te lezen is dat kopstukken uit de markt gevraagd worden terwijl agile mensen boven processen zet en samenwerking boven contracten. Dat past prima bij de participatiesamenleving, de doe-democratie waar politiek nu mee kokketeert. Helaas is het een scheet in een netje want vaak blijkt er dus sprake te zijn van (w)obstructie omdat de documenten, contracten en plannen niet terug gevonden kunnen worden. De administratie wordt blijkbaar met het manifesto van agile ingevuld waardoor ambtelijke top als de kapitein van de Costa Concordia zijn, ze verlaten het schip snel nadat ze er een puinhoop van hebben gemaakt.
Succesvol project management is heel simpel, breng gewoon het ouderwetse eigenaarschap weer terug nu project management vervallen is tot het ontlopen van verantwoordelijkheid.
Anko, ik snap je antwoord en er zit wel wat in, maar ook delen waar ik het niet mee eens ben.
Als we Agile gebruiken, neem ik niet aan dat we daarmee “Behendig” bedoeld, maar doelt op het Agile manifesto, en die is wel degelijk gericht op software ontwikkeling. En uiteraard is het meer dan brokkenpap. Maar mijn ervaring is dat agile en compliance wel degelijk elkaar in de weg, zeker als je al in productie zit.
Verder ben ik het heel erg eens met Ewout. Daar zitten zeer sterke inzichten in.
@Ewout Kan me goed vinden in je reactie. Vooral de laatste zin is aansprekend, eigenaarschap en verantwoordelijkheid nemen. Te vaak gezien, verantwoordelijkheid ontlopen en afschuiven. Outsourcing van ontwikkeling vind ik daar ook onder vallen. Over de schutting. Ook wat je zegt over het manifesto, heb daar al een tijdje terug ook al over lopen oreren. Vooral dat, werkende software boven documentatie. Nu denken hele volksstammen dat documentatie niet meer zo belangrijk is. Je weet pas of de software werkt als je vastgelegd hebt of het werkt! Mensen boven procesen, juist de bijbehorende methodes doen in de praktijk het omgekeerde.
Continous delivery & integration, devops, zie die voortkomen doordat projecten afdeling overlappend zijn. Met de bijbehorende frustraties. Maar je ziet het, heel snel en in kort periodes software live gooien. Ik heb bij een organisatie gewerkt die dit op een welhaast religiueze wijze doorvoert, het is ook bijna een geloof. En maar nieuwe aanpassingen live gooien en dan maar afvragen waarom er storingen zijn. Maar ja, ik ben ook zeer conversatief als het om computers en software. Afblijven als het werkt, niet te drastisch in je projecten en uitgaan van wat je hebt en voorzichtigheid is de moeder van de porseleinkast. Het gaat toch eigenlijk altijd mis.
De kracht van scrum is dat de klant/leider/owner constant betrokken is het proces en kan bijsturen ipv dat een clubje nerds/nitwits bepaald wat er gebouwd wordt. (Wie kent het plaatje met de schommel niet?)
Die klant moet daar dan ook volledig in opgaan en zich desnoods verdiepen in de ICT materie. Al dan niet via ondersteuning.
Het sluit ook beter aan bij het feit dat een organisatie als levend organisme altijd in ontwikkeling is en dat het zich niet aan starre ICT hoeft aan te passen maar andersom. (Wat in de praktijk vaak behoorlijk lastig lijkt te zijn.)
En natuurlijk niet te veel hooi op de vork en het opdelen in behapbare brokken. Maar dan heb je weer regie nodig om die onderdelen aan elkaar te knopen. Op dat nivo heb je dus ook kundige mensen nodig waar het dan ook nog wel eens aan wil ontbreken of het een trapje hoger alsnog wordt gesaboteerd vanwege belangen die het project kunnen schaden. Als bijvoorbeeld de doorlooptijd te lang wordt bevonden en er in een korte tijd iets af moet wat afgeraffeld is en dus voor je ogen uit elkaar valt.