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.
@Felix Dat is een leuk artikel over methodieken, van SDM naar Agile/Scrum. SDM bekeken en dat ziet er concreet uit vergeleken met wat ik zie van agile/scrum. Juist over inhoudelijke documentatie en fasering, de miletones. Vond dat wel sterk maar wel veels te gedetaillieerd. Maar in dat stukje stond ook, het mechanisch toepassen van methodes is het ook niet. De term bureaucratie viel ook in combinatie met SDM. Dat was ook wel weer voorstelbaar als je het leest:
http://nl.wikipedia.org/wiki/System_Development_Methodology
Dat inhoudelijke mis ik bij scrum/agile. Dat gaat over het proces. Kan ook bureaucratie geven.
@PaVaKe Is het geen organisatorisch probleem wat je daar beschrijft, dat er een afstand is ondanks dat technisch zo nauw verbonden zijn (bv ontwikkeling,integratie,systeemtest)?
@Anko Als salon communist ben ik toch geen voorstander van deze vorm van arbeiderszelfbestuur waar bij het team samen verantwoordelijk is. Er zal toch iemand uiteindelijk een beslissingen moeten nemen over hoe en wat. Dus ben benieuwd hoe dat dan gaat, want er zullen natuurlijk inhoudeljke verschillen van mening zijn. Vind trouwens dat je verantwoordelijk voor je eigen werk bent ook al kan je verantwoordelijk voor het geheel voelen.
@Ewout Het lijkt me geen moeilijke keus als je moet kiezen tussen snelheid en zekerheid. Inderdaad, er is ook heel veel continu werk met het doorvoerenvan wijzigingen en ander onderhoud. De lopende zaken zeg ik maar, de change managent. Dat zal je bij de infra hebben maar dat heb je ook met software beheer. Maar ok, geen projecten, er zijn wel taken. Dat is heel prettig, daar heb je scrum en agile helemaal niet bij nodig. Dat is met software ontwikkelingen misschien wel niet veel anders. Niet alles hoeft inderdaad een project te zijn.
@louis: klopt, sluit dan ook aan bij wat Reza zegt: je organisatie moet er ook klaar voor zijn
@Leendert
PRINCE2 staat voor PRoject In Controlled Environments, dat daar governance in zit is een beetje als zeggen dat boekhoudpakket ook een grootboek bij kan houden. Maar uiteindelijk komt elk project ten einde en dan?
Agile en governance hoeven niet strijdig met elkaar te zijn maar zijn het vaak wel om de simpele reden dat het niet alleen skilled resources vraagt maar ook multidisciplinaire skills, gedurende de hele lifecycle welteverstaan. Wat ik nog vaak zie is dat dit gedurende het project nog wel ingevuld wordt maar dat de kwaliteit al snel terug loopt als er weer een rondje aan kostenbesparingen is geweest. En projectmatig werken is dan precies wat er staat, matig.
Zoals ik al eerder stelde in een opinie over open source hebben ontwikkelmethoden wel degelijk hun impact op de governance zoals we reeds zagen met openSSL. In reactie naar Anko stelde ik dat 1/5 van de onopgeloste punten voor 4/5 van de kosten kan zorgen en ik meen ergens gelezen te hebben dat er verbazing was over hoge beheer(s)kosten na oplevering van een project. Mij verbaasde dat dus niet want met name bij de overheid zijn er meer baasjes dan beheerders.
Altijd grappig om die scrumborden vol met post-it notities te zien, doet me vaak denken aan het keuzebord met weektaken van Dalton systeem op de lagere school. Vul de rol van scrummaster verder zelf maar in.
@Louis
De keus tussen snelheid en betrouwbaarheid is dus wel moeilijk want kijk naar onze overheid waar politici ambitieuzer zijn dan wat er mogelijk is omdat proces, organisatie en klant meer tijd nodig hebben om de veranderingen te adopteren. Las iets over een minister die nog meer ICT in de zorg wil hebben, zeg maar het nog verder ontmenselijken ervan door weer voor de paarse zee te kiezen. Dit maakt duidelijk dat postmoderne residu van de maakbare samenleving en het geloof in alles regulerende systemen nog steeds niet verdwenen is. Maar over de zelforganisatie in de zorg had ik al eens wat geschreven in Zelfhulp en Kameradenhulp, hoorde dat ze dat in Finland (en nog wat Europese landen) in ieder geval beter voor elkaar hebben.
@PaVaKe Blijft lastig, technische afhankelijkheden, waar de organisatie en projectstructuur haaks op kan staan. Maar je zou denken, het onderkennen daarvan zou je al een oplossing kunnen brengen. Of die oplossing Agile heet en dat een organisatie daar klaar voor moet zijn? Daarvoor vind ik Agile te vaag en onduidelijk zodat ik me afvraag of men wel weet waarvoor men klaar moet zijn? Ik denk het niet. Concreter kan zijn: bv als project en organisatiebureaucratie in de weg staan, pak dat dan aan en zorg dat de juiste mensen bij elkaar aan tafel komen. Hoeft de organisatie niet eens geweld aan te doen, want die kan op zich best logische in elkaar steken. Zolang overschreidende ict activiteiten maar niet gedwarsboomd worden.
@Ewout Ik denk dus dat je altijd moet gaan voor betrouwbaarheid, snel en niet betrouwbaar zou niet eens een optie moeten zijn. Denk wel eens, de ondersteunde ict in al zijn facetten gedraagt zich als een olietanker, bijsturen kan maar je zet hem niet zomaar even dwars. Wel iets om rekening te houden bij politieke beslissingen, dat de praktische ict uitvoering ook tijd kost en een randvoorwaarde is. Maar ik neem aan politici goed geinformeerd worden of dat hoop je althans.
Iets anders is Schippers met de ICT oplossingen. Misschien best mooi maar is het inderdaad niet onpersoonlijk en brengt het je wel een kostenbesparing? Dat is toch waar het om gaat en daar twijfel ik aan. Of zou het echt om de kwaliteit en inhoud gaan?
@Louis
Snelheid en minder betrouwbaar gaan wel samen, kijk naar het fenomeen van Consumerization of IT. Dat de ‘wegwerp’ attitude niet altijd opgaat voor een heleboel andere services is wat anders maar zal de minister een zorg zijn, het is een ongeschreven regel dat een termijn op een ministerie nooit langer duurt dan 4 jaar.
En dat politici goed geïnformeerd worden blijkt uit de lijst van ‘voortschrijdend inzicht’ projecten die nu onderzocht worden. Ergens gaat er dus wat mis in de communicatie naar de burger en ik laat in het midden waar maar de journalistieke kwaliteiten van Sander zijn evengoed als die van Elias, het is rectaal onderzoek waar vooral de koe in de kont gekeken wordt. Driemaal raden welke melkkoe uiteindelijk naar de slacht gaat.
Jammer dat discussies vaak uitdraaien op het uitwisselen van argumenten door voor- en tegenstanders van een methode of filosofie. Waarbij bovendien niet duidelijk is of ze een methode bedoelen of een filosofie.
Agile, als filosofie of leidend principe, is wat anders dan de diverse methoden en best practices die gestoeld zijn op deze filosofie of kunnen worden aangepast aan deze filosofie. Zo zijn Scrum en Atern voorbeelden van methoden die volledig gebaseerd zijn op Agile, maar ze verschillen onderling aanzienlijk. Verder zijn meer traditionele methoden als PRINCE2 en PMBoK in hun laatste versies aangepast, zodat deze ook volledig Agile zijn te gebruiken. Discussie over welke methode het beste is is dan ook zinloos en sterk situatie-afhankelijk. Iedere projectmanager zou comfortabel met meerdere methoden overweg moeten kunnen.
Datzelfde geldt voor de discussie over agile versus waterval (of front-end loading versus iteratief ontwikkelen). Zinloos, want volkomen situatie-afhankelijk. Je moet als projectmanager beide filosofieën in je arsenaal hebben.
@PaVaKe helemaal eens. Agile, in combinatie met Lean, levert pas echt waarde als je naar de hele keten kijkt. Samenwerking tussen de diverse stakeholders en ontwikkelteams is cruciaal om succesvol te zijn.
Samenwerken is m.i. een kwestie van willen en kunnen. De drive moet er zijn, het vertrouwen dat alle betrokkenen bij zullen dragen. En regelmatig kijken wat er al goed gaat en waar het nog beter kan. Gelukkig zit dat al ingebakken in de Agile filosofie en werkwijze 🙂
Na selectief googelen kwam ik op een leuk artikel over Agile en ontwikkeling, van een iemand die Agileman is.
http://blog.cutter.com/2013/12/10/2014-the-failure-of-agile-software-development-is-taken-seriously/
Vroeg me af, moet het soms niet incrementeel zijn waar iteratief straat? Dat is nog een nadenker.Het is natuurlijk ook wel wat zweverig, het is een motivator, de schrijver, dat is oppassen maar de totale vrijheid voor ontwikkelaars spreekt wel aan. En dat hij over documentatie begint.
Een project kan alleen succesvol worden als het op een realistische manier is begroot. Dit geldt ook voor Agile uitgevoerde projecten. Helaas is de software industrie, in tegenstelling tot andere industrieën, nog niet volwassen genoeg om gebruik te maken van Cost Engineering technieken. Software Cost Engineering, het meten van de omvang van de te leveren software in combinatie met het gebruik van relevante historische data, levert altijd een beter onderbouwde begroting op en daarmee een veel hogere kans op slagen dan begrotingen die zijn gebaseerd op de optimistische verwachtingen van ‘experts’. Ieder project dat alleen is begroot op basis van ‘de mening’ van een of meer experts heeft een hoog risico om te mislukken.
Leuke vergelijking van Agile met de heilige graal.
Niemand van ons heeft deze ooit gezien, niemand weet wat de heilige graal is of zou moeten voorstellen (beker, kelk, schaal, kom, steen, edelsteen, pijlpunt, vlies, et cetera). Niemand weet hoe heilig de graal dan wel zou zijn, als deze er (ooit geweest) is. Is er maar één, of zijn er meerdere (geweest)? Is de oorsprong Keltisch of Joods? En indien heilig, zou de graal dan heilig zijn voor alle christenen, of voor alleen Katharen, katholieken of zelfs nazi’s? En is het sec een relikwie of zijn er ook magische krachten aan verbonden?
Na de vele verbasteringen, commerciële, religieuze en politieke bemoeienissen, weten we dus niet echt waarover we spreken. Net als Agile. Ergo….