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.
@Louis
Op eerste deel had ik wat aanmerkingen op één van de deelnemers aan rondetafel discussie. Ik stelde hierin dat niet alles een project is maar dat er – zeker binnen de infrastructuur – ook nog zoiets is als change management. Kijkend naar ontwikkelingen van DevOps is release management een belangrijk element daarin waarbij het verschil tussen beide naar mijn opinie het viewpoint is, release management richt zich meer naar de business functionaliteiten terwijl change management zich vooral richt op de continuiteit. En dat dit soms conflicteert hoef ik hopelijk niet uit te leggen, het is een strijd tussen progressief en conservatief.
Henri stelde dat agile vooral een injectie aandacht is waar ik het mee eens ben maar dan met name aan de bovenkant van de stack. Snelle wisseling van software releases werken vooral in de B2C sector maar worden volgens mij verfoeid in de B2B sector omdat dit een grote wissel trekt op het change management proces. In voorgaande reactie stelde ik dat Continuous Integration vaak nog een uitdaging is, al meer dan 15 jaar als ik kijk naar de meer gereguleerde sectoren. Kijkend naar de problemen met patch management in menig agile georienteerde omgeving bedenk ik me dat er eigenlijk maar weinig compliant zijn.
Terug naar progressief versus conservatief is het allemaal gewoon een keus tussen snelheid zonder zekerheid en zekerheid zonder snelheid, hedendaagse problemen zitten vooral in de op verschillende snelheden draaiende lagen van de ICT stack. Want om terug te komen op opmerking van Henri over Heavy Metal bij mijn reactie op deel 1 is het toch vooral nog klassieke muziek die met ‘distortion’ en versterking gespeeld wordt. En opmerkelijk is de afwezigheid van Reza in deze discussie, blijkbaar heb ik een gevoelige snaar bij hem geraakt;-)
Ewout,
Dank dat je aan mij dacht 🙂 Je hebt zeker geen gevoelige snaar bij mij geraakt 🙂 sterker nog ik ben tegenwoordig helemaal draadloos!
Mijn afwezigheid heeft te maken met het feit dat ik in deze periode zeer weinig tijd heb. Mijn werktijden beëindigen helaas niet rond 16:17 om een boekwerk als reactie achter te laten en/of alles van iedereen te lezen. Ik scan de discussie en ik vind het leuk om door deze reacties tot nieuwe inzichten te komen.
De relatie tussen release management/continous delivery/ continous integration aan een kant en change management aan de andere kant was een discussiepunt van een bijeenkomst die ik een tijd geleden heb meegemaakt.
Agile/Scrum -liefhebbers zeiden dat:
1) “je organisatie en processen moeten Agile/scrum ready zijn”
dus ik vertaal het naar “accepteer dat je vaker en sneller de zaken moet veranderen en vergeet de ouderwetse change management dan ben je Agile/Scrum ready!
Je ziet ook dat aan het eind van dit artikel wordt gezegd “Agile dient toegepast te worden waar dat geschikt is”
2) Je sprints moeten klein zijn om kans op grote vergissingen en fouten te verkleinen. Komt er iets naar voren dan kunnen we de sprint snel re-schedulen en de impact klein houden.
Uiteraard waren genoeg mensen die het niet eens waren met deze werkwijze en gedachten.
Ik kan me herinneren dat Leendert Hinds in dat gesprek bij Cerios zei dat er projecten bij Tata zijn die hun producten met hoge betrouwbaarheid (dus 99.9999% correct) moeten opleveren. Dit is zeker tegen de regels van Agile/Scrum en daarom doen we dat volgens een andere werkwijze.
Terug naar wat ik eerder zei,release management/continous delivery/ continous integration aan een kant en change management aan de andere kant zijn misschien o.a. de onderwerpen die de werkwijze voor de uitvoering van een project kunnen bepalen. Het is aan de organisatie om de keuze te maken!
Tijd om mijn mails te gaan beantwoorden! Succes met de discussie verder, ik zal mijn reactie achter laten als ik er aan toe kom 🙂
http://www.zbc.nu/ict/informatiemanagement-ict/agile-scrum-en-de-methode-doet-het-nog-steeds-niet/
Naar mijn idee is Agile (Scrum) een tool/werkwijze die je inzet onder bepaalde condities. Deze condities zouden tevens voldoende moeten/kunnen zijn om hetzelfde te kunnen doen volgens waterval, maar bij waterval zie je vaak dat men al met zaken bezig gaat terwijl de condities nog niet zijn ingevuld. Agile (Scrum) zorgt er dus eigenlijk voor dat je als team je condities duidelijk krijgt op het juiste moment. Wat het wel als wezenlijk voordeel heeft is het tussentijds aanpassen van die condities. Dit heeft een relatief lage impact, doch schuilen daar ook grote risico’s! Het blijven aanpassen kan namelijk ook een gedrocht opleveren en de effort gigantisch doen toenemen.
Let wel, ik ben zeker niet tegen Agile (Scrum), maar ik ben ook niet per definitie voor. Agile moet je dus Agile inzetten.
Moet ik toch even denken aan een semi-overheid project waarbij de betreffende klant geen goedkeuring durfde te geven omdat dit politiek te gevoelig lag en hij bang was om op de schopstoel te komen zitten.
Dan wordt het vrij lastig om een sprint af te ronden en Agile heeft dan ook geen meerwaarde.
Overigens is het project wel goed afgerond maar flink over tijd en meer kosten dan geraamd. Vrij traditioneel dus.
Ewout, ik denk dat ik je begin te begrijpen. Maar ik ben het niet met al jouw opvattingen over Agile eens.
Ik ben het niet met je eens dat Agile en governance niet samen gaan. Dat kan prima, mits we bereid zijn om governance-zoals-we-dat-binnen-traditionele-kaders-hebben-ingericht op een aantal punten willen aanpassen zodat governance effectief gaat worden voor een Agile omgeving. Toelichting: Veelal is governance nu (dus traditioneel) gericht op het verifiëren of aan de oorspronkelijke uitgangspunten wordt voldaan. Veel focust zich dan op de initiële planning, scope en werkproducten. Zonder lerend vermogen. Governance op een Agile manier zou zeer veel meer richten op de doelen van het project/programma en de waarde die de verschillende onderdelen voor de business vertegenwoordigen. Dus niet fixeren op ‘wordt de beoogde scope opgeleverd’ maar ‘levert het project minimaal gelijkwaardige of misschien zelf meer waarde op dan initieel ingeschat’.
De mening die je verkondigt dat Agile geen documenten oplevert is niet juist. Ongetwijfeld zullen er nono’s zijn die onder het mom van Agile geen documenten meer opleveren, maar de focus in Agile ligt (naast tastbare resultaten) op documenten die WAARDE toevoegen. Dus geen documenten om de documenten schrijven. Ieder zichzelf respecterend Agile team (note de nuance) levert per sprint zijn documentatie op. Punt.
Over eigenaarschap denk ik simpel, maar niet makkelijk. Als je met elkaar een goed product wil neerzetten, ben je met elkaar verantwoordelijk. Net als met een voetbalelftal: als je wil winnen moet je met z’n allen verdedigen en met z’n allen aanvallen. En met elkaar de wedstrijdstrategie delen. En met elkaar de corners doornemen, etc. Dat betekent niet dat er geen specialisten zijn!
Door 1 iemand aan te wijzen, letten er 10 niet meer op, want er is toch iemand verantwoordelijk (“not my job” syndroom). Been there, done that, didn’t work.
@Reza
Typische reactie van je, als ‘night owl’ reageer ik inderdaad meestal rond de middernachtelijke uren maar dan hebben we het over de vorm en niet de inhoud. Tenslotte had ik het niet over ensemble van rondetafel sessie in mijn reactie maar de muziek die er gespeeld werd en waar jij nu dus ‘distortion’ aan toevoegd. Toch een gespannen snaartje blijkbaar;-)
Even resumerend stelde ik in voorgaande deel dat niet alles een project is, bezigheidstherapie van projectmanagers is dat ze alles moeilijker maken dan het in werkelijkheid is met hun PRINCE2 methodiek. Je opmerking dat het de organisatie is die de keuzen maakt is precies de kern van mijn oplossing, breng het eigenaarschap terug. Terug dus naar de bestuurskamers waar bepaald wordt of het een innovatief project gericht op vernieuwing (blauwe zee) of kostenverlaging (rode zee) is volgens INSEAD bedrijfsstrategie.
En hiermee bedoel ik dus niet de regeerakkoorden die in achterkamertjes tot stand komen want een paarse zee is er niet.
@Anko
Ik sla het een beetje plat maar de kern is dat wendbaarheid niet altijd wenselijk is, als je gaat voor kostenreductie is een kruiwagen vol kikkers het laatste wat je wil. Dat leidt meestal tot allemaal kleine bedrijfprocessen met ieder hun eigen ICT oplossingen, zeg maar de Consumurization of IT. Governance op een agile manier lijkt me onzin zoals we nu zien bij andere parlementaire onderzoeken want dan gaat de slager zijn eigen vlees keuren, wie bepaald welke documenten waarde hebben en welke niet?
Je verhaal van ‘not my job’ heeft niets met methodieken te maken maar alles met organisatiecultuur, precies dat stukje eigenaarschap waarover ik het had. Succes kent vele vaders maar mislukking blijft meestal een wees wat het gevolg is van een zoekgeraakte balans tussen bonus en malus. Zeg maar het mengen van innovatie en kostenverlaging waardoor je een samentrekking krijgt in de vorm van een paarse bolus.
Ik volg net als bij deel 1 de levendige discussie bij dit artikel en aangezien mijn naam genoemd is bij de reactie van Reza, voel ik mij aangesproken om enige toelichting te verschaffen.
Bij Tatasteel en volgens mij bij meerdere organisaties worden meerdere methodieken, manifesto’s, concepten, of hoe wij het ook willen noemen, toegepast. Welke men dient toe te passen is afhankelijk dan diverse factoren als organisatie, soort project en skills van de beschikbare resources.
Ik ben niet tegen of voor agile en ook niet tegen of voor waterval, maar alleen van mening, dat het toegepast moet worden afhankelijk van de hierboven genoemde factoren.
Tevens ben ik van mening dat agile en governance niet strijdig met elkaar hoeven te zijn. Governance is niet afhankelijk van de ontwikkelmethode, maar meer afhankelijk van de projectmethode.
Door het toepassen van Prince2 kan governance gewaarborgd worden.
Agile heeft absoluut een aantal goede dingen in zich. Maar (zover ik tot nu toe ervaren heb) zou de kracht van Agile moeten zijn dat de hele organisatie (dus niet alleen het lopende project) een cultuuromslag in gaat, welke efficiëntere productontwikkeling ondersteund.
Agile wordt pas een succes als de hele ontwikkelketen, van idee tot uitvoering, als methodiek wordt gebruikt.
Wanneer teams als eilandjes opereren in een groot en complex project is succes vaak ver te zoeken. Dito als disciplines (bijv. ontwikkeling, integratie, systeemtest) afzonderlijk gaan opereren.
Successen in Agile vergen niet alleen het “volgen” van het manifesto, maar ook een andere denk- en handelswijze.
@Leendert:
Mooie toevoeging! Ik heb je verhaal in die late avond/nachturen beetje samengevat verteld. Je uitleg maakt dit verder mooi duidelijk.
@Pa Va Ke:
Zeer mee eens! Ik had in mijn reactie naar twee punten verwezen:
1) Je organisatie moet klaar zijn voor Agile/Scrum,
2) Agile dient toegepast te worden waar dat geschikt is
Ik denk dat deze twee punten zeer overeen komen met wat je hierboven zei.
Leuk te zien dat er reacties zijn waarin eenvoudig eigen ervaring en ook de analyse van dit artikel worden besproken.
Persoonlijk houd ik van toegankelijk en (voor iedereen) begrijpelijk communiceren. Ik zie geen nut in zware termen en wollige verhalen die als reactie achter gelaten worden waardoor de complexiteit en misverstand verder toenemen. Geen nut! Maar ja, je kunt ook deze wijze gebruiken voor je eigen marketing ……. Ieder heeft zijn eigen werkwijze 🙂
Ik ga strax mijn Libelle lezen 😉