Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

BI en Agile, een droomhuwelijk?

 

Computable Expert

ing. Tanja Ubert RI
Hogeschooldocent BI Design en Methoden, Hogeschool Rotterdam. Expert van Computable voor het topic Business Analytics.

De afgelopen tijd heb ik me verdiept in Agile-methoden en -technieken. Natuurlijk heb ik wel in wat projecten gewerkt waar Scrum werd gebruikt, maar waar ging het nu echt over. Gewapend met de Agile and Iterative Development: A Manager’s Guide van Craig Larman begonnen met het onderzoeken van de basis van Agile. Dan kom je natuurlijk bij de bron: Het Agile Manifesto.

De grote vraag die ik mezelf stelde: bi en Agile, is dit een droomhuwelijk? Agile is voor snelle ontwikkelingen en opleveren wat de klant nodig heeft. BI wil ook snel opleveren en opleveren wat voor de klant nodig is. Maar ja, datakwaliteit, tracebility, past dat allemaal wel?

Dus na het lezen van het boek van Larman meer research op basis van de de tips in het boek. Ook nog het BI Symposium bezocht, waar Agile centraal stond en de Agile en BI Conferentie van BI-Podium. Ik ben dus zeker geen expert op Agile gebied, maar er vallen mij wel een aantal zaken op.

Kijkend naar de principes van Agile uit het manifesto (Personen en interacties boven processen en tools; Werkende software boven uitgebreide documentatie; Samenwerking met de klant boven onderhandeling over het contract; Omgaan met verandering boven het volgen van een plan) lijkt het een ideale combinatie. Want iedereen die in bi werkt weet dat de vragen van de afnemers van onze producten bijna sneller wijzigen dan wij ze kunnen bedenken.

Valkuilen

Kijkend naar de principes van Agile is daar al de eerste valkuil. Dat wij van bi bedenken wat onze afnemers willen, is eigenlijk tegen de Agile-principes. We moeten het samen bedenken, niet vooraf door de technici en dan hopen dat het klopt. 

Een andere valkuil is de fabel dat het ineens allemaal sneller en beter gaat. Waar elke Agil-deskundige het over eens is, is dat de organisatie en de klant er klaar voor moeten zijn. Wat is dat dan, dat klaar zijn? 
Een aantal zaken voeren de boventoon, hier een kleine greep: De klant moet beslissen wat de prioriteit is voor de business, in samenwerking met het team (vaak Scrum-team). Dit impliceert veel meer dan er staat. Dit betekent dat de klant geïnteresseerd moet zijn in de uitkomst van het traject. Tijdens het hele project. Dat hij of zij hier tijd, mensen en middelen voor wil vrij maken, een visie heeft waar hij of zij heen wil. Vanuit de deskundigen moet er een multidisciplinair-team klaar zijn om met een klant samen te werken (echt te luisteren, genoeg kennis van de business om alles te begrijpen) met een werkomgeving die snelle ontwikkeling, verandering en deployment toestaat en faciliteert. Dus geen lange procedures naar productie, voldoende ruimte op de servers et cetera. 

Agile-methodes werken alleen als feed back tijdens de ontwikkeling verkregen wordt en meteen evaluatie en vasthouden van de leermomenten na de ontwikkelingsperiode (sprint) plaats vindt.

Andere uitdagingen die zo even in mij opkomen: Werkende software boven uitgebreide documentatie werkt misschien in een project, maar veel diensten in bedrijven vragen voor het onderhoud toch weer uitgebreide documentatie. Hoe borg je de kwaliteit van deze documentatie? Zijn er andere manieren? Misschien eerst maar eens met elkaar bepalen wat genoeg documentatie’ is? 

Ook de samenwerking met de klant boven onderhandeling over het contract … wow, best wel een statement. Jarenlang heb ik als consultant geleerd om pas te beginnen met een klus als het contract rond was, omdat het risico dat de klant niet betaald te groot is …

En dan het project voor de financiële afdeling, waar je gewoon van het plan afwijkt om om te gaan met de verandering. Dan kloppen de begrotingen dus ook niet meer, hoeveel tijd ga je besteden aan het aanpassen hiervan? En moet je dan weer door de beslissingsmolen van een bedrijf voordat je verder mag? Of is het project daarom achteraf niet volgens begroting en dus mislukt? (Hoewel er nu wel software staat die doet wat de bedoeling is?).

En dan natuurlijk de it-deskundige. Samenwerken met de klant, dus als de klant zegt dat het zo goed genoeg is, dan het ook zo doen. Ik kan me zo voorstellen, dat je als it-deskundige die al jaren verteld aan de klant wat goed voor hem of haar is, dat dit nogal een aardverschuiving is. Natuurlijk ga je nu niet stoppen met nadenken, maar je moet je klant echt goed vertellen waarom dingen nodig zijn, zodat hij of zij de beslissing kan nemen. Dus bi'er, leg maar even uit wat datakwaliteit is en waarom het echt moet … in mensentaal, niet in vaktermen.

Kortom: ik denk dat we bij bi en Agile nog veel moeten ontdekken, maar dat het in de basis prima bij elkaar past. Daarom hoop ik dat bedrijven het Agile-gedachtengoed niet alleen voor it-projecten gaat adopteren, maar dat het hele bedrijf mee gaat in deze stroming zodat er een echte fijne samenwerking komt van de business kant en de it-deskundigen. Samen voor een eindresultaat in plaats van ieder zijn of haar deelverantwoordelijkheid. Ik kijk er naar uit.

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

?


Lees meer over


 

Reacties

Leuk stuk wat lekker weg leest. Complimenten.

Scrum is best expliciet. Over zichzelf zegt het "lightweight", "simple to understand" but "extremely difficult to master". Herkenbaar dus.

Een aardig beschouwing zou ik zeggen. Ik kan me voorstellen dat er op het snijvlak BI en Agile wel raakvlakken te bedenken zijn. Ik hou me niet zo met BI bezig. Maar wanneer de koppeling hier gelegd word Agile en IT, dan vind ik het interessant worden.

Al gaan beginnen voor de contracten er liggen?
Ehmmmm, daar gaat mijn ondernemende geest even een nachtje over slapen als je het niet erg vind. Natuurlijk, je kunt wat momenten bedenken die louter tot gevolg hebben genoeg informatie voor handen te hebben wat de klant wil en verwacht en wat jij wil gaan leveren. Verder als dat? Ik denk het niet.

Agile-methodes werken alleen als feed back tijdens de ontwikkeling verkregen wordt en ......
Wilt u een reden waarom de IT processen op zijn gat gaan? Dan haalt u er hier eentje aan. Een wetmatigheid stelt namelijk dat als P groter wordt dan het ingezette proces, het proces onderuit zal gaan. P staat hier niet alleen voor probleem maar elke invloed die u kunt bedenken op dat proces.

Ik heb al vaker geroepen dat het precies daarom is dat Agile en IT niet zo lekker samen zullen gaan. Agile is Non lineair, IT lineair. Ik stel wederom hier belangenloos 'de Civile Matrix' ter beschikking.

IT Scalable, Predictable
Als er al een materie is die zo goed kan worden ingeschat, dan is dat IT. Je kunt voor de punten en comma al zaken invullen, bedenken, evalueren, voorbereiden, testen en je kan daar voor 85% alles al voorkoken.

Die overige 15%? Dat is pure uitvoering en monitoring, tenminste, als men het goed heeft ingeregeld. Scalability komt als u allerhande processen en projecten goed onderverdeeld in deelprojecten of deelprojecten.

Dan nog zijn al die delen onderworpen aan dezelfde wetmatigheden van IT als materie en behavior. Dus dat betekend..............?!? Precies. Dat betekend dat mensen die zich in de IT begeven, met IT bezig zijn, ermee werken, worden behept met één van de wetmatigheden van IT.

Lineair
Mensen die werken met IT, waar je mee omgaat word je door besmet, die worden in denken, doen en laten, steeds meer lineair. In gewone mensentaal, steeds incommunicatiever. T.a.v. de Non IT wereld dan wel te verstaan.

Hier zult u als consultant de stap moeten zetten naar de klant, de Non It klant, wat IT is, hoe het werkt en aan welke wetmatigheden die is onderworpen. En dan? Dan ga je allemaal blije gezichten zien want plots begrijpt Non IT hoe men zich met IT moet verhouden en kun je beginnen met bouwen.

Onderuit.....
In heel Agile kom ik niets lineairs tegen. In BI ook niet echt. Wilt u weten waarom het dan zo vaak fout blijkt te gaan? Dan heeft u hier het antwoord. Beweegt u zichzelf buiten de outlines van uw project of proces, dan kun je dat overal doen, maar niet in IT. Doe dit binnen IT processen of projecten, dan word P gewoon groter dan het proces. Dat betekend twee dingen.....

1. Meer kosten door vertraging
2. Meer kosten door onwetendheid

En was IT nou net niet het vehicle dat u wil gebruiken om kosten te besparen? Ik wijs agile niet af, maal ook agile zal zich namelijk moeten conformeren aan de wetmatigheden van IT. Die zijn namelijk vanaf het eerste moment tot nu toe, as we speak, onveranderd. Welk 'foefje' men ergens voor heeft bedacht. Doe het nou eens niet in IT.



De meeste BI-software is ontwikkeld om door IT-personeel omgevormd te worden in eindgebruikersoplossingen.
Every Angle software is een Business Analytics oplossing voor gebruik door business users. Het ontwerp is uitgegaan van de aanname dat gebruikers niet vooraf kunnen specificeren maar dat hun informatie- behoefte door hen zelf snel en flexibel moet kunnen worden ingevuld.
Dat is ''agility''.
Kom maar eens een kijkje nemen (www.everyangle.com)

@NumoQuest IT-ontwikkeling is inherent een niet lineair proces. Agile, Lean-IT (waaronder Scrum) zijn juist ontstaan vanwege die eigenschap of waarheid zoals u het noemt.
IT is ook niet puur bedoeld om kosten te automatiseren. Alleen kijken naar kostenbesparing resulteert in ICT-projecten waar alleen maar bestaande processen in electronische formulieren wordt gegoten, zonder ooit goed overleg met gebruikers of de 'business' te hebben.

Beste Gerbrand,

Are you really kidding me? Ik ken uw achtergrond niet maar laat ik u meteen les 1 geven in IT.

2 vragen die aan elke stap in IT ten grondslag liggen.....

1. Waarom automatiseer je?
2. Waarom zou je automatiseren?

Kunt u eenvoudig deze twee vragen niet beantwoorden, ga dan weg van IT. Blijf er vanaf. Blijf er uit de buurt. U heeft dan namelijk geen enkel idee van de materie IT, de wetmatigheden IT aan onderworpen is.

U gaat dan wel een dekentje 'Lean' of 'Agile' over IT leggen? Heading voor disaster. U kunt dat alleen doen als u 'aardige' kennis heeft van IT en de ketens van IT.

Lean
Lean is gestoeld op de merites en wetmatigheden van Kaizen. Kaizen is niet Amerikaans, maar Chinees van origine. Deze is door Toyoda geimplementeerd in zijn processen bij Toyota en more..... nog steeds in zwang aldaar en geadopteerd door anderen.

Ondergetekende heeft meer dan 35 jaar Iaido en Aikido achter de rug waarbij Kaizen (Lean) een basis is. Dat men van Lean een commercieel verhaaltje heeft gemaakt soit. Daar ga ik verder niet over oordelen.

Kaizen
Kaizen is het wederkerige menselijke principe dat mensen leren bij herhaling. Mensen zijn niet volkomen dus hun processen en actie ook niet. Dat is een gewone mondial wetmatigheid. Mensen leren door herhaling en het principe van Kaizen is de gedachte dat wanneer een mens een fout maakt, dit de mens niet mag worden aangerekend. Die fout is een positieve onvolkomenheid. De mens heeft iets ontdekt wat kan worden 'Verbeterd'. (Kaizen is namelijk 'Beter Maken', Perfectioneren' zo u wil.)

Kaizen in het westen
Dacht u werkelijk dat de volle potentie van Kaizen voet aan de grond zou krijgen in Nederland? Om het even beperkt te houden? In een zakelijk klimaat van afrekenen en afserveren? You must be kidding me. Dus word lean en agile een commercieel verhaal, dat het wellicht prettig zal doen in een dynamische of verzuilde organisatie.

Lean/Agile en IT
Wanneer u Lean of Agile wil toepassen in organisaties waar IT processen een noodzakelijke strategie is, dan dient u kennis te hebben van die IT processen en hun 'behaviour'. Als u stelt dat niet nodig te hebben omdat Lean/Agile dit dekken, dan loopt u vanzelf tegen de wetmatigheden van IT aan.

Niet iets wat mij dan verder uit maakt. In courses en seminars stel ik continue hetzelfde...... I don't care! In het begin. Neem het aan, neem het niet aan. Prima. Ik hoef namelijk de rekeningen van de F#ck #ps niet te betalen. Maar als het je iets waard is, neem kennis van de werking van IT als materie, hun processen en wetmatigheden, en je gaat IT gebruiken en inzetten waar het voor is bedoeld.

Doe het niet, en de organisatie zal het meer kosten dan men oogde te besparen. en laat IT nou net een materie zijn die je moet helpen te besparen. Daar heb je vervolgens een Lean of Agile niet voor nodig. Hoogstens een vertaalslag.

@TanjaUbert Wat een leuk en herkenbaar artikel. Ook ik vraag me al een tijd af wat de agile filosofie is en ik kwam ook uit bij de bron: het agile manifesto. Het riep bij mij vragen op die jij ook stelt. Daar schept het manifesto geen duidelijkheid in, in mijn ogen is het manifesto een vaag en slecht verhaal met een paar statements waar je alle kanten mee op kan. Op zijn best denk ik, er zit iets in maar dan moet je er naar zoeken.

Zo worstel ik ook met het statement over werkende software boven documentatie. Ik ben van mening, geen werkende software zonder documentatie. Net als de software behoort documentatie tot de deliverables van een ontwikkel project en is het je referentiepunt. Ben het met je eens dat het een uitdaging is om te bepalen welke documentatie nodig is en voldoet. Als het gaat om veel documenten en letters produceren, ja dan ik kan ik iets begrijpen van dit agile gebod. Maar of het zo bedoeld is?

Je schrijf ook over samenwerking met de klant boven contractonderhandelingen in combinatie met het omgaan met veranderingen. En dat je gewend bent als consultant eerst te onderhandelen over een contract en dan pas te beginnen. Dit punt van het manifesto daar kan ik me iets meer bij voorstellen, als het contact tussen klant en uitvoerder formeel is dan loop je de kwade kans dat over iedere wijziging gesteggeld moet worden en opnieuw onderhandeld. Dat lijkt me inderdaad niet agile (..) en niet productief.

Individuen boven processen is de statement waar ik het minst mee kan, zeker als je kijkt naar de agile methoden die gangbaar zijn (scrum, lean etc). Die methoden lijken me nu een voorbeeld van processen belangrijker dan mensen, het proces als middel om IT projecten te sturen, controleren en monitoren. Ik denk niet dat in een Japanse autofabriek het individu boven het proces gaat.

Tegenwoordig heb ik agile ook wel omschreven zien worden als wendbaar, flexibel en snel. Je kan er alle kanten mee op met dat agile en in verkeerde handen ontstaan er hele vreemde ideeen over software ontwikkeling. Je schrijft dat je geen agile expert ben maar ik vraag me af of die bestaat, die expert. Daarvoor is het te vaag om te beginnen met het welhaast religieuze dictaat van het manifesto.

@Gerbrand Ben ook van mening dat het ontwikkelen van software (of ieder ander it project) geen lineair proces is en meer weg heeft van een Echternachse processie. Dat is ook waar ik aan denk bij het woord agile, ruimte voor voortschrijdend inzicht bij het ontwikkelen van software. @Numoquest Dat ICT lineaire materie is ontgaat me en kan me er weinig bij voorstellen.

@TanjaUbert ik ben het met je eens dat Agile en BI wat voor elkaar kunnen betekenen, maar het grootste dilemma wat ik in de praktijk tegenkom is dat de aanlooptijd van BI-trajecten vaak erg lang is. Met name het verzamelen van de data, het opschonen en beschikbaar stellen ervan is een DWH is een traject wat zomaar enkele maanden kan duren. Dan kun je wel lekker willen Scrummen en maandelijks willen opleveren, maar zonder fatsoenlijke data lukt dat simpelweg niet.
Pas als er de technische randvoorwaarden er zijn om nette rapportages te genereren, kun je in interactie met gebruikers uitstekend gaan itereren. En als het deploymentstuk ook goed is geregeld (en er dus probleemloos rapportages op P kunnen worden gezet), dan kan dat vaak sneller dan maandelijks.

Voor wat betreft de waarden van het Manifesto: er staat daar NIET dat contracten niet belangrijk zijn, maar dat men heeft gemerkt dat software projecten succesvoller zijn als de focus meer op de software komt te liggen dan op de fulfillment van de contractuele verplichtingen. Als zodanig is het Manifest een tegenbeweging tegen het gedachtegoed uit de jaren '90 waarin contracten, processen en planningen centraal stonden in de projectuitvoering, in plaats van het realiseren van waarde.
Contracten heb je nodig, en processen en planningen ook. Maar ze zijn altijd een middel, en geen doel. Dat is wat het Agile Manifesto (mij) zegt.

@NumoQuest: je weet vast wat faalfactor #1 in (IT-)projecten is. Inderdaad: communicatie. En is je onderbouwing geef je exact aan waarom lineair niet werkt: mensen in een lineair proces creeeren hun eigen hokjes en waarheden en worden steeds minder communicatief naar elkaar toe, en al helemaal niet naar de non-IT.
Als Agile voor mij (!) 1 ding doet, dan is het wel het faciliteren van communicatie. Een multidisciplinair team in 1 ruimte zetten, met een duidelijk doel voor ogen en de middelen om dat te realiseren waarin ze eendimensionaal worden aangestuurd door een gemandateerde. Dat werkt!

IT blijft binnen een Agile team lineair: er zal eerst een behoefte moeten zijn, waarover wat zinnigs geroepen moet worden over hoe dat er uit kan zijn, vervolgens ontwikkel je wat en ga je dat beoordelen. Dat is nu eenmaal een wetmatigheid, want je kunt niet beoordelen voordat je een idee hebt wat je wil. Maar daaromheen zit een schil van interactie, communicatie en continu leren van water nu daadwerkelijk nodig is. Dat is geen onvermogen, maar erkenning van het feit dat exact weten wat je wil onmogelijk is in een complexe adaptieve wereld om ons heen en in ons die continu verandert.

Dank allemaal voor het leuke en inhoudelijke commentaar. Goed om te zien dat er nog veel collega's zijn met een gedegen kijk op de zaak.

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

×
×