Managed hosting door True

Is Agile de heilige graal?

Rondetafeldiscussie deel 2

De weg naar succesvolle projecten

 

Rondetafeldiscussie Computable

Met de klok mee de tafel rond: Ben Zwartveld, Leendert Hinds, Fred Bons, Steven van ‘t Veld, Bob van Zeist en Reza Sarshar.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5119376). © Jaarbeurs IT Media.

7,5


Lees meer over



Lees ook


 

Reacties

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.

@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 ;-)

@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....

Het hangt ook sterk af van wat je als "succes" benoemt.
Als de organisatie succes definieert als "op tijd en binnen budget", dan kan je met waterval en prince2 prima op tijd iets opleveren. De gebruikers werken dan om de problemen heen (de missende features zijn dan nice to have's), en de kosten van het extra werk in de organisatie vallen misschien best mee.
Als de organisatie succes definieert als "tevreden gebruikers", of "proces effectief ondersteund", of "beter dan dat van de concurrent" dan is het waarschijnlijk dat je iteraties - dus kosten en tijd toevoegt.
Ik denk dat dat kan verklaren dat voor commerciële producten en diensten Agile werken een must is, en voor traditionele systeemontwikkeling en in-house trajecten Prince2 vaak prima voldoet.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×