Als it-directeur zit je met regelmaat in een onmogelijke positie, want kosten, hoge eisen aan kwaliteit om maar geen ‘mislukt it-project’ te krijgen en veranderende behoeften dwingen tot flexibiliteit. De vraag is alleen hoe geef je dat vorm.
Er is geen gebrek aan tegengestelde belangen. Ict moet inhoudelijk perfect draaien, want de voorbeelden van Belastingdienst, politie en OV-chipkaart schrikken af. Het publieke geheim is dat ook in de private sector dit soort problemen spelen. Een beetje cio wil dus goed de vinger aan de pols houden. Daarbij is ook oog voor veranderende omstandigheden belangrijk. Wie had durven dromen dat tablets zo snel geadopteerd in het dagelijks leven zouden worden? Flexibiliteit of Agility is dus een must.
Aan de andere kant blijven bedrijven en maatschappij ict als een kostenpost zien en die visie zal niet snel veranderen. Sterker nog, dat budgetten bij de meeste bedrijven de komende jaren onder druk zullen blijven staan, lijkt wel zeker te zijn. Toch kunnen we niet zonder en dat merken we inmiddels weer op de arbeidsmarkt waar de eerste tekorten weer beginnen te ontstaan. Dat dit niet goed is voor de kosten kan iedereen bedenken.
Scrum
Voor mij is dit speelveld niet anders, want mijn klanten verwachten een antwoord op de problemen. Met nearshoring mag je dan wel een antwoord bieden op kosten en met ervaren academisch geschoold personeel mag je dan wel de kwaliteit waarborgen, toch is dat geen antwoord op de overige vragen. Om dat antwoord wel te krijgen heb ik fors geïnvesteerd in Agile Development en werk al enige tijd met Scrum.
Het prettige daarvan is dat ontwikkeling wordt opgedeeld in kleinere, overzichtelijke projecten van zo'n twee tot vier weken. Dit geeft dus een antwoord op al die onderzoeken die keer op keer uitwijzen dat grote projecten mislukken door een gebrek aan overzicht. De stappen zijn ook iteratief, waardoor het hele Scrum-proces ook vertrouwd is.
Maar misschien is het prettigste nog wel dat de relatie met de klant nauw is, omdat deze binnen het Scrum-proces een rol heeft en bij korte overleggen (digitaal) aanschuift. Dit helpt met het vinger aan de pols houden, terwijl meteen wordt voorkomen dat in valkuilen wordt getrapt. Ook is er opeens ruimte voor veranderingen, zodat het eindresultaat goed aansluit bij de echte wensen. Scrum helpt dan ook vooral zaken goed beheersbaar en flexibel te houden, terwijl je procedures toch goed borgt.
Niets is volledig zaligmakend dus ook Scrum niet, maar ik merk in de dagelijkse praktijk wel dat goede methodieken wel helpen. De worsteling met projecten die volledig uit de hand lopen, oplossingen die achter de feiten aanlopen heb ik niet. Dat neemt veel van de pijn voor een cio, die vaak tussen wal en schip zit, weg. Het is net een pijnstiller, die stilt tijdens de operatie terwijl de klant als patiënt volledig bij bewustzijn is.
Hallo Bernhard,
Heldere bijdrage en uiteraard helemaal mee eens, maar dat moge duidelijk zijn als we het over Scrum hebben.
Ik vraag me wel af hoe jij hier precies mee omgaat in de praktijk? Leg je Scrum op aan je klanten? En zo ja, staan ze wel open voor een leverancier die een werken via Scrum vraagt? Of ga je binnen een traditionele manier van werken (met bijvoorbeeld een fixed-price watervalcontract) gewoon zelf iteratief met Scrum aan de gang omdat je uit ervaring weet dat je dan sowieso veel effectiever bent?
Goed artikel en ook goede vragen van Rini. Ik denk dat er inderdaad een bottleneck zit in de aansluiting tussen de processen van een opdrachtgever en de processen van de leverancier. Scrum lijkt een goede oplossing voor veel problemen, maar het moet aansluiten bij de manier van werken aan klant-kant. Ik vraag me ook af of de algemene notie van ‘scrum’ wel afdoende helder is. In de IT industrie en zeker in offshoring/nearshoring lijkt het alsof iedereen agile en scrum hanteert. Maar kan een opdrachtgever hier iets uit opmaken? Volgt een bedrijf een standaard, heeft het een eigen versie van ‘scrum’ bedacht (en werkt die dan) of wordt de term scrum als marketing term ingezet?
Erg herkenbaar. Agile development kan inderdaad prima resultaten opleveren. Echter, er bestaan ook veel vooroordelen over de achterblijvende kwaliteit die de ‘snelle agile (cow)boys’ opleveren. Een aantal uitgangspunten zijn van belang voor het bereiken van een tevreden klant:
– in lijn met de strategie van de klant moet met steun van het management de kaders van de functioneel op te leveren brokken worden afgetikt;
– begin met nieuwe functionaliteit en lever echte business value met functionaliteit die belangrijke (delen van) bedrijfsprocessen ondersteunen;
– de bouwers moet in direct contact staan met de gebruikers. Dit maakt near-/offshoring uitdagender. Moderne communicatiemiddelen bieden soelaas, mits de tijdszones niet te veel uit elkaar lopen. Bij near-/offshoring is het van belang dat er hechte teams worden gevormd en in stand gehouden worden;
– architectuur en beheer moet actief worden betrokken in het agile proces om ‘hakken in het zand’ te voorkomen;
– ook bij een agile werkwijze is het van belang transparant aan het management te rapporteren over productiviteit, kwaliteit en risico’s. Dat is niet old school!
– agile werken vergt een andere wijze van inkopen. Niet meer fixed price/fixed date, maar afspraken maken over op- en afschalen van capaciteit;
– agile is niet geschikt voor alle soorten IT-projecten. Integratieprojecten zijn beter met een andere aanpak aan te vliegen.
Ik zie wel wat in scrum, maar wie heeft vervolgens het grote overzicht om al die deelprojecten tot een goed geheel te krijgen en hoe ga je om met gestelde deadlines van buitenaf?
De vergelijking met een pijnstiller geeft al aan dat je Scrum niet ziet als de holy grail voor ontwikkeltrajecten.
Ontwikkelprojecten hebben de reputatie om altijd langer te duren dan gepland. Developers zijn namelijk onverbeterlijke optimisten (ik kijk even in de spiegel).
Het voordeel van Scrum is dat je die uitloop eerder ziet aankomen, en dus maatregelen kunt nemen. In de praktijk is die maatregel vaak: accepteren dat het langer duurt, of genoegen nemen met een afgeslankt eindproduct dat wèl op de afgesproken tijd gereed kan zijn.
Beide opties doen zeer, en of Scrum ook die pijn stilt valt te betwijfelen.
Dit neemt niet weg dat ik veel zie in agile werken. Als het gedisciplineerd wordt toegepast biedt het veel voordelen.
Dat is de beste oplossing!
Niet iedereen is even goed gespecialiceerd in een bepaalde richting, maar deste meer aanvullend gespecialiceerd in een richting wat bij de ander weer minder is.
Zo maak je optimaal gebruik van de beste resultaten.
Agile/scrum is mijns inziens niet DE oplossing, maar slechts EEN ANDERE oplossing. Ook met de waterval methode kun je immers werkpakketten van 2-4 weken opstellen. Agile is dus inderdaad een pijnstiller, maar bij verkeerd gebruik is het op zijn best een placebo of een verdovingsmiddel.
Agile vereist nauwere betrokkenheid van de klant (die hij niet altijd kan geven) en brede inzetbaarheid van een kleine groep developers van de leverancier. Als de klant-betrokkenen onvoldoende visie over de gewenste functionaliteit (scope) en/of onvoldoende mandaat voor de projectbesluiten (budget en planning) hebben, dan blijft het eindresultaat onvoldoende.
Als de developers geen brede kennis/ervaring hebben, ontstaan – door de bewust beperkte teamomvang – problemen, zowel tijdens de realisatie als bij de overdracht naar beheer. Deze problemen zijn nog groter wanneer de teamleden samen onvoldoende in staat zijn om de gebruikerswensen te vertalen in te bouwen componenten (bijvoorbeeld door taalproblemen bij near/offshore staff).
Het blijft een grote uitdaging om tussentijds de voortgang te meten en te rapporteren, en ook om het vertrouwen te blijven houden dat de must- en should-have functionaliteit gerealiseerd wordt.
De crux van de kwaliteit ligt vooralsnog – nog meer dan in ouderwetse ontwikkelmethoden – bij de betrokken mensen, en minder bij de methoden, processen en tools.
Het vraagt CIO’s met visie (en een goed HR beleid), zowel aan de klantzijde als bij de leverancier, om de voordelen van agile te plukken. Visie en vertrouwen verkleinen de (kans op) hoofdpijn beter dan welk medicijngebruik dan ook…
Wat is het verschil tussen de Agile/scrum-methode en DSDM??? Want ook bij DSDM is een intensieve deelname van de klant vereist. Ov heeft het beestje weer een andere naam gekregen om te doen alsof er een nieuwe allesoplossende methode is gevonden?
Zelf heb ik de programmatuur geschreven t.b.v. de automatische bevoorrading van de Honkemuller-winkels. Via de watervalmethode. Van te voren alles tot op de minuut nauwkeurig gepland (240 mandagen begroot incl. testen) en uiteindelijk 10 uur eerder opgeleverd. Daarbij ben dwars ik tegen alle politieke regels ingegaan die er maar zijn. Zelfs tot op directieniveau aan toe.
@Robin
Agile = Filosofie
Hieronder vallen methodes zoals:
XP
SCRUM
Kanban
DSDM
Het DSDM Consortium Benelux heet nu Agile Consortium Benelux omdat ze zich niet willen beperken tot alleen DSDM.
(Hopelijk correct) DSDM ligt tussen SCRUM en RUP in.
RUP is wel iteratief is, maar gaat niet flexibel met documentatie om.
DSDM wordt omschreven als een Agile Project Framework genoemd.
Iemand correcties of aanvullingen?
@Robin: respect voor je aanpak.
In mijn ogen wordt Agile veel te veel gehyped en, en zal dit hopelijk snel weer afvloeien. Onzin natuurlijk.., alle requirements op van die ‘post it’jes te plakken.,..