Agile is al jaren erg hot. Was het in het begin nog iets bijzonders, vandaag de dag claimt iedereen Agile te zijn. Maar is dat ook echt zo? En hoe belangrijk is dat eigenlijk? Helpt Agile echt bij het realiseren van onze doelstellingen? Draagt een Agile werkmethode echt bij aan oplossingen bedenken en die realiseren of is het slechts het volgende excuus? Laten we maar gewoon doen, dat is al gek genoeg. Het is hoog tijd om software op te leveren.
Vanuit mijn rol als softwareleverancier (ik ben mede-oprichter van een softwarehuis), maken we het in gesprek met potentiële klanten dagelijks mee. Er bestaat een zeer grote wens om Agile te werken. Wij ontmoeten veel softwareteams aan de klantzijde die beweren al Agile te zijn. Toch heerst er vaak aan beide kanten van de tafel, dus zowel bij de business als it, ontevredenheid. Softwareprojecten leveren niet op wat men er van verwacht had.
Een impasse is vaak het gevolg, verwijten worden over en weer gemaakt. Frequent horen wij verhalen dat de businesszijde maar niet snapt dat ze niet geleverd krijgen wat ze vragen. De it-zijde moppert over al het onbegrip en de vele verstoringen van hun ontwikkelproces door allerlei klantprioriteiten.
Methodes niet zaligmakend
Om de situatie te verbeteren, nemen it-afdelingen het heft steeds vaker in eigen hand. En dat is van harte toe te juichen. Men kiest ervoor om op een andere manier te gaan werken en daarmee flexibeler te kunnen zijn richting de business. Veelal verkiest men om Scrum te implementeren. Op deze manier proberen ze om eindelijk wel die beloofde nieuwe release op te leveren. Maar als een dergelijke wijziging in isolement plaatsvindt, dan is dat gedoemd te mislukken.
Geforceerd gaat de it-afdeling zich namelijk afsluiten van de business. Er worden openingstijden ingesteld om de business zo veel mogelijk buiten de deur te houden. Maar alternatieven worden niet gepresenteerd richting wat in principe toch de klant is. Hierdoor krijgt de businesszijde het gevoel dat het serviceniveau nog verder is gedaald, want hij kan zijn verhaal nu ook niet meer kwijt.
Wederzijds onbegrip
Recent besprak ik dit probleem tijdens een keynote bij een PMI-conferentie. Een grote groep ervaren projectmanagers hield massaal de hand omlaag toen ik vroeg of zij een goede overlegrelatie hadden met de businesszijde in hun projecten. Behoorlijk schokkend vond ik dit. En het bevestigt wat wij in de praktijk vaak zien. De businesszijde heeft een verzoek ingediend, maar krijgt vervolgens niet wat gewenst werd. Navraag bij de it-afdeling leert dat ze het eigenlijk niet goed begrepen hebben, maar toch maar iets opleveren.
Dergelijke problemen los je niet op door bijvoorbeeld Scrum binnen de it-afdeling te introduceren. Intern veranderen er dan wel processen, rituelen geven de dag vorm en kortdurend leidt het wellicht tot meer focus en daarmee plezier. Maar op de langere termijn zal er helaas niet veel veranderen. De klant blijft ontevreden. En dit alles door het simpele feit dat de business zich niet begrepen voelt en de it-zijde waardering zal blijven ontberen.
Extra capaciteit
Een volgende oplossing die regelmatig verkozen wordt is een capaciteitsuitbreiding om alle wensen van de business te gaan realiseren. Achterstanden dienen te worden weggewerkt. Er wordt een externe it-partner in het proces betrokken die extra resources mag gaan leveren. In het slechtste geval is dit de start van een veel groter probleem.
We kennen allemaal het fenomeen ‘garbage in is garbage out’. Een onvoldoende geoptimaliseerd proces is niet uit te besteden, problemen los je niet op door meer capaciteit toe te voegen. Doorlooptijden verkort je daar niet mee, integendeel. Negen vrouwen baren een baby ook niet in één maand.
Het is natuurlijk erg gevaarlijk om te generaliseren, maar soms is dat nodig om dingen duidelijk te maken. Bovenstaande situatieschetsen zijn gebaseerd op onze meerjarige ervaring met klanten in diverse landen. Veelal komen we vergelijkbare situaties tegen.
Samen bereik je meer
De vraag is nu natuurlijk bestaat er een medicijn tegen deze kwaal? Ja, dat medicijn bestaat en is vaak te simpel voor woorden. Menig organisatie heeft alleen blijkbaar een buitenstaander nodig om de zere plek aan te wijzen. In de meeste gevallen staan business en it gewoonweg al te lang tegenover elkaar.
Op zich vinden we dit waarschijnlijk allemaal vreemd, want we zouden toch allemaal dezelfde bedrijfsdoelstellingen na moeten streven. De praktijk is weerbarstiger. Om zeer uiteenlopende redenen heeft iedere afdeling inmiddels zo zijn eigen doelstellingen en die liggen lang niet volledig in lijn met die van de algehele organisatie.
Toon interesse
Persoonlijk vind ik dat it hierin een eerste stap moet zetten. Door interesse te tonen voor de businesszijde kan een dialoog ontstaan. Welgemeende interesse leidt tot een ongekende uitwisseling van informatie. It zal dan ontdekken dat de klant niet nodig had waar hij om vroeg. Hij kwam met een vermeende oplossing voor zijn probleem, maar in veel gevallen blijkt dat het echte probleem eigenlijk anders is, maar dat het niet gelukt was om dit te verwoorden.
Weten klanten eigenlijk wel wat ze echt willen, danwel nodig hebben? Vaak onvoldoende. En eigenlijk moeten ze dat ook niet proberen te verwoorden. Ze moeten gewoon, in relatief eenvoudige functionele beschrijvingen, uitleggen welk probleem ze ervaren of welke kans ze zien. Als it zich inleeft in deze situatie, kunnen zij met hun kennis van bestaande systemen en (nieuwe) technische mogelijkheden echt wel bedenken hoe het te realiseren.
Gezond verstand
Heb je hier Scrum of andere Agile methoden en tools voor nodig? Nee, niet per se. Dit is gewoon een kwestie van je gezonde verstand gebruiken en met elkaar een goede dialoog voeren. Dat zijn technieken die we met elkaar al vele eeuwen toepassen. Natuurlijk kunnen bepaalde best practices wel ondersteunen, maar dan wel op voorwaarde dat zowel business als it eraan meedoen.
Een it-afdeling die zegt conform Scrum te werken, maar geen product owner heeft, is in mijn ogen nog steeds niet echt goed Agile bezig. Dan is Scrum maximaal een excuus en is het tijd om gewoon te doen en een goed gesprek met elkaar te hebben.
Succes!
Hmm… doet me sterk denken aan ‘programming-motherfucker dot com’
Na waterval, volgde agile en nu zijn we dus alweer in de “gezond verstand” fase gekomen ? Het Business-ICT gap te lijf gaan met ‘gewoon doen en een goed gesprek met elkaar te hebben’.
Zelf ben ik meer voor de meewaai methode. De techniek komt voort uit best practice en bestaat uit geinteresseerd blijven knikken en niet vergeten je factuur te schrijven aan het eind van de maand. Doe er je voordeel mee.
@Tom: Ik begrijp waarom je dat denkt en op zich kan ik me daar redelijk goed in vinden. Ook zij zijn tegen allerlei nieuwe methodes die uiteindelijk niet echt veel veranderen. Maar ik ben het niet met hen eens dat het alleen maar om programmeren draait. Zonder overleg kom je volgens mij niet ver met alleen maar programmeren.
@Felix: We zijn het blijkbaar niet geheel eens en daar kan ik me prima in vinden, agree to disagree. Gezond verstand zou gedurende de implementatie van waterval en agile ook de boventoon hebben moeten voeren. Het is dus wat mij betreft geen nieuwe fase. Het probleem is dat dergelijke methodes zonder voldoende (gezond) verstand van zaken worden geïmplementeerd. Ik heb helaas vele consultants meegemaakt die de door jou beschreven factuurschrijfmethode hanteerden, erg teleurstellend.