Transcript 54 42 - IT-Executive

Inhoudsopgave
❉
Thema: Agile development
In dit nummer van Tijdschrift IT Management (TITM) veel aandacht voor agilemanagement. Het fenomeen ‘agile’ is volledig verbonden met de digitale wereld, een tijd waarin het gebeurtenissengehalte groot is en veranderingen zich in hoog
tempo voltrekken. De traditionele manieren van organiseren en leidinggeven schieten daarbij tekort. Veel IT-organisaties
hebben zich bimodal ingericht in een traditionele transactiegerichte omgeving en een agile omgeving. Dat laatste vereist
andere managementskills.
14
8 faalfactoren van agile projecten
De beloften van agile development zijn groot, maar uit de verf komen
doen agile opgezette ontwikkeltrajecten lang niet altijd. Wat zijn de
grootste valkuilen die succes in de weg staan? ➼
16
Outputgestuurd werken haalt het hoogste rendement
uit agile softwareprojecten
De omslag van de watervalmethode naar een agile aanpak kan de
nodige huivering met zich meebrengen. Hoe zorg je ervoor dat je met een agiledevelopmentaanpak toch de vinger aan de pols houdt en de stip op de horizon
rond budget, kwaliteit en deadline niet uit het oog verliest? ➼
14
10
22
Distributed teams: zó boek je resultaat
Elke twee weken werkende software tegen lage kosten: de combinatie van agile development en gedistribueerde teams kan veel moois
opleveren. Tegelijkertijd lopen distributed teams in de dagelijkse praktijk tegen
tal van uitdagingen aan.
➼
10
Mario Kortman van Waternet over agile transformatie
Het Amsterdamse Waternet heeft in 2015 onder leiding van Programmamanager Digitalisering Mario Kortman een veranderprogramma
ingezet: van de traditionele ‘geharkte’, hiërarchische organisatie naar een agile
vorm. “De logheid van veel ondernemingen en instellingen ligt vaak niet aan de
mensen, maar aan de organisatievorm.”
➼
Inhoud
Thema: Agile development
8 faalfactoren van agile projecten
Outputgestuurd werken haalt het hoogste
rendement uit agile softwareprojecten
Distributed teams: zó boek je resultaat
4 T I J D S C H R I F T
I T
M A N A G E M E N T
Special: security
Internet of Things: geen toekomst, maar nu
34
Datakwaliteit: uitdaging voor IoT-pioniers
40
Mobile edge computing (MEC): doorbraak voor IoT? 42
14
16
22
Vak
De humanoïde robot
Blockchain: nog tal van uitdagingen
De zin en onzin van een logmanagementoplossing
54
68
76
Special: Internet of Things
Het speciale katern focust op het Internet of Things. Werden gegevens van het IoT
eerst vooral in de specifieke sectoren gebruikt, nu blijkt het verzamelen van meetdata in vrijwel elke branche voordeel op te kunnen leveren. De technologie is er
en leidt tot neutrale feedback, en met veel fantasie tot nieuwe businessmodellen en
producten. Wat zijn de trends?
34
Internet of Things: geen toekomst, maar nu
34
Bedrijven als Gartner, IDC en Cisco duikelen over elkaar met hun
voorspellingen over het aantal connected devices in 2020. Maar liefst 76
procent van de ondervraagden geven aan IoT nu al te onderzoeken. Zo’n 36 procent
daarvan is bezig met een proof of concept en bijna iedereen verwacht dat hun organisatie binnen de komende drie jaar met IoT aan de slag gaat. Maar wat gebeurt er
nu al met IoT en waar komt dat enthousiasme vandaan?
➼
40
Datakwaliteit: uitdaging voor IoT-pioniers
Nu steeds meer apparaten binnen het Internet of Things (IoT) met elkaar
in verbinding staan, groeit het belang van een goede datakwaliteit. Heldere designuitgangspunten en voortdurende, geautomatiseerde kalibratie kunnen
voorkomen dat apparaten niet meten wat ze zouden móéten meten. ➼
42
Mobile edge computing (MEC): doorbraak voor IoT?
Steeds meer bedrijven ontwikkelen producten en diensten die deel uitmaken van het Internet of Things en die gebruikmaken van clouddiensten. Daarmee groeit echter ook de druk op de onderliggende mobiele netwerken.
Een oplossing op basis van mobile edge computing (MEC) kan uitkomst bieden. ➼
42
54
De humanoïde robot
Een aantal nieuwe technologieën is samen te brengen onder de noemer ‘de nieuwe werkers’. Het gaat achtereenvolgens om humanoïde of
mensachtige robots, zelfrijdende auto’s en kunstmatige intelligentie. Dit artikel gaat
dieper in op de ontwikkelingen rond mensachtige robots.
➼
54
Cover
Mario Kortman van Waternet over agile transformatie 10
Column
Column Peter van Eijk
Aldus Peter Bakker
Verslag
21
33
Rondetafeldiscussie over mobiele veiligheid en privacy 48
Rubrieken
Redactioneel
Kort nieuws
Gadgets
Science Fiction
Research
Servicepagina
Partnerartikelen
7
8
53
67
73
78
26, 30, 38, 46, 51, 62, 74
N U M M E R
4
2 0 1 6
5
‘Op afstand
vergaderen
scheelt 6
retourtjes en 12
gevulde koeken
per maand.’
Op en neer reizen voor je werk is kostbaar.
Met de digitale werkomgeving van KPN
kun je altijd en overal samenwerken met je
collega’s en aan de slag gaan met spreadsheets,
presentaties of rapporten. Overal fysiek
aanwezig zijn is dus niet meer nodig.
En dat scheelt een hoop tijd.
Ook zakendoen met KPN? Kijk op kpn.com/ict
Voel je vrij. KPN.
van TITM
Het einde van de piramide
Symbolen van massieve onverzettelijkheid, dat zijn ze:
piramides. De immense soliditeit van de wereldwijd voorkomende bouwsels heeft ze de tand des tijds laten trotseren.
Ruim vierduizend jaar na hun constructie zijn ze nog net zo
intimiderend als toen. Een piramide dwingt wie aan de voet
staat op te kijken naar de top. Andersom geeft het degene die
erbovenop staat de mogelijkheid neer te kijken op de mensen
beneden. Dat is geen toevallige metafoor.
De piramide staat ook model voor de manier waarop de
Romeinen al tweeduizend jaar geleden hun legers organiseerden. Aan de voet het voetvolk, gebukt gaand onder het
gezag van de laag erboven, die op zijn beurt onderhevig was
aan de bevelen van de laag daar weer boven. En ten slotte de
eenzame macht van degene aan de top. De beeldspraak van
een ‘hogere functie’ en ‘top-down’ heeft zo vorm gekregen.
voordeel. Integendeel: er zijn juist flexibele, wendbare processen nodig, zonder de ballast van onnodige procedures,
verwurgende hiërarchieën en starre mensen. En organisatievormen waarbij de besluitvorming en verantwoordelijkheden daar zijn belegd waar ze horen: op de werkvloer. De
verticale manier van denken, zoals in piramide- en silomodellen, heeft plaatsgemaakt voor een horizontale visie
met ‘customer delight’ als primaire doelstelling. Moderne
digitale organisaties werken niet meer met langetermijnplanningen, maar denken in korte cycli en sturen bij waar
en wanneer dat nodig is. Niet alleen in de bejubelde agile
teams, maar juist óók in de boardroom. Wat voor nut heeft
immers een snel, wendbaar schip met een flexibele bemanning, als kapitein en stuurman nog plannen in hiëroglyfen
en denken in Romeinse hiërarchieën?
Het Romeinse militaire, hiërarchische model heeft de
westerse wereld twee millennia gediend – of heeft tweeduizend jaar de dienst uitgemaakt, het is maar hoe u het
bekijkt. De industriële revolutie heeft er dankbaar gebruik
van gemaakt – het is de bakermat van wat we ‘management’ zijn gaan noemen. De gemiddelde fabrieksarbeider
aan het eind van de negentiende eeuw kon immers niet lezen en schrijven. En had dus iemand nodig die dat wel kon
om hem leiding te geven. Dat principe heeft het eigenlijk
te lang uitgehouden en ‘leidinggeven’ (ongeacht aan wie)
is een professie op zichzelf geworden. Maar anno nu huurt
een bedrijf mensen in vanwege hun expertise en competenties. Dan heeft het weinig zin die te laten aansturen door
iemand die die capaciteiten niet heeft.
Veel organisaties zijn zichzelf op de nieuwe agile-leest aan het
schoeien. En het lukt steeds vaker de piramide af te breken en te
vervangen door agile teams. Is het daarvoor nodig dat de volledige board hevig verliefd is op agile? Moet al het zittende personeel worden vervangen door mensen van de generatie Einstein?
Mario Kortman van het Amsterdamse Waternet beantwoordt
in het coverinterview beide vragen met een hardgrondig ‘nee’.
“Het ligt niet aan de mensen, maar aan de organisatievorm”,
is zijn stelling die hij – en anderen – inmiddels overtuigend
bewezen heeft. Laat dat een stimulans zijn voor alle medewerkers van traditioneel georganiseerde bedrijven om zelf het heft
in handen te nemen en de piramides te slechten.
Het is haar massiviteit die de piramide uiteindelijk heeft
doen afbrokkelen en haar ondergang heeft ingeluid. Want
de fysieke en symbolische eigenschappen van de piramide
werken vandaag de dag averechts, contraproductief. In een
tijd waarin veranderingen zich voltrekken met megabits
per seconde is massieve onverzettelijkheid bepaald geen
❉
Arnoud van Gemeren ([email protected]),
hoofdredacteur Tijdschrift IT Management
N U M M E R
4
2 0 1 6
7
kort nieuws
Genomineerd voor de CIO of the Year
Award 2016 zijn: Michel van Hout
(Transavia), Ron van Kemenade (ING),
René van Sandijk (Vanderlande), Hendrik-Jan Smaal (Heijmans), Gerard Spans
(Arcadis), Teun van der Vorm (ANWB).
Cloudapplicaties schieten
tekort qua beveiliging en
compliance
CIO of the Year Award 2016:
"Genomineerden realiseerden doorbraak"
De nieuwe CIO of the Year krijgt dit
jaar een kaderdoorbrekend profiel. Dat
blijkt uit de shortlist van zes genomineerden voor de jaarlijkse award, die
op dinsdag 29 november door prins
Bernhard van Oranje wordt uitgereikt
tijdens CIODAY2016 in de Amsterdamse Beurs van Berlage.
De jury gaf voorafgaand aan het selectieproces aan op zoek te zijn naar een
technologieleider die in de afgelopen
achttien maanden een echte doorbraak
heeft gerealiseerd. “IT was altijd een
discipline van frameworks en modellen op allerhande niveaus”, aldus Rob
Beijleveld, CEO van ICT Media en
initiatiefnemer van de CIO of the Year
Award. “In de nieuwe wereld, die
gedomineerd wordt door businessgerichte technologie, zijn deze kaders niet
langer toereikend. We hebben daarom
gezocht naar CIO’s die zich niet langer
laten vangen in raamwerken uit het
verleden, maar letterlijk grensverleggend bezig zijn.”
Bedrijven gebruiken twintig keer
vaker applicaties in de cloud dan de
IT-afdeling denkt, vertrouwelijke informatie wordt ondanks richtlijnen op
brede schaal gedeeld en 98 procent van
de cloudapplicaties voldoet niet aan
de eisen van de GDPR. Hierop duidt
onderzoek door Blue Coat Systems, leverancier van beveiligingsoplossingen.
De onderzoekers maakten gebruik van
datawetenschap om ruim 15.000 zakelijke cloudapplicaties en 108 miljoen zakelijke documenten die daarin werden
opgeslagen of daarmee werden uitgewisseld, te analyseren. Ze definieerden
een op risico’s gebaseerd waarderingssysteem voor toekenning van een score
aan de geschiktheid van cloudapplicaties voor zakelijk gebruik. De onderzoekers onderzochten cloudapplicaties
op hun functionaliteit voor compliance,
databescherming en beveiliging.
Van de 15.000 geanalyseerde applicaties bleek 99 procent onvoldoende
mechanismen te hebben voor effectieve compliance, databescherming
en beveiliging. Opvallend is dat bijna
driekwart van de zakelijke applicaties
geen multifactor-authenticatie heeft.
Ruim 10 procent van alle cloudapplicaties is nog altijd kwetsbaar voor
een of meer belangrijke exploits, zoals
FREAK, Logjam, Heartbleed, Poodle
SSLv3, Poodle TLS en CRIME.
Ook blijft schaduwdata, oftewel
gegevens die werknemers onbeheerd
opslaan in en uitwisselen via de cloud,
een belangrijk bedrijfsrisico. Bijna
een kwart van deze schaduwdata
wordt op brede schaal gedeeld tussen
werknemers en externe partijen. Organisaties gebruiken gemiddeld meer
dan 800 cloudapplicaties binnen hun
bedrijfsbrede netwerk: twintig keer
zoveel als de IT-afdeling inschat.
Nederlandse datacenterkaart
gepubliceerd
De Dutch Datacenter Association (DDA)
heeft een digitale en dynamische datacenterkaart van Nederland gelanceerd.
Voor het eerst is op meerdere niveaus
inzichtelijk hoe de belangrijkste datacenters in Nederland geografisch ge-
In CIO Magazine
“CIO’s zijn zelf vaak de bottleneck bij het over de bühne brengen van dit soort bewegingen [innovatie van IT, red.]. Ze zijn te gehecht aan iets wat ze ooit zelf hebben neergezet en kunnen dat
moeilijk loslaten. Maar leveranciers hebben zich intussen sterk ontwikkeld en bieden iets waar
een interne IT-afdeling niet of nauwelijks tegenop kan.”
Gerard Spans, CIO van Arcadis, in CIO Magazine nr. 3/2016.
8 T I J D S C H R I F T
I T
M A N A G E M E N T
POWERED BY IT-EXECUTIVE.NL
spreid zijn én wat hun kwaliteiten zijn.
Op www.dutchdatacenters.nl/map.html
zijn alle locaties van de grote datacenters
aangesloten bij de DDA aangegeven; dit
is meer dan 90 procent van het topsegment. Deze datacenters onderscheiden
zich door hun kwaliteit en professionaliteit. Tegelijkertijd heeft de DDA een
handboek uitgebracht met detailinformatie over de aangesloten datacenters.
Via de kaart is alle relevante informatie over de aangesloten datacenters
zichtbaar. Stijn Grove, directeur van
de DDA: “Je zou zeggen dat er al genoeg lijsten en catalogi over datacenters zijn, maar die missen objectiviteit
en flexibiliteit. De informatie op de
map is zo samengesteld dat in één
oogopslag de basisgegevens van een
datacenter bekeken kunnen worden.
En wie meer gedetailleerde informatie
wil, kan het handboek raadplegen.”
De kaart zal voortdurend worden
bijgewerkt en in de loop van dit jaar
zullen aanvullende functionaliteiten
toegevoegd worden, aldus de DDA.
IT-professionals aan meer positieve
effecten te verwachten als de verhouding van mannen en vrouwen gelijker
wordt dan de huidige 90/10-verhouding in de IT-sector. Opvallend
is echter dat het hier om een grote
minderheid gaat: slechts 33 procent
denkt dat de sfeer op de werkvloer zal
verbeteren vanwege een ‘betere balans
tussen ratio en emotie’. Een deel van
de respondenten geeft aan over meer
‘Betere man-vrouwverhouding verhoogt kwaliteit in IT’
innovatievermogen te beschikken
als er meer vrouwen in teams zitten.
Slechts 13 procent verwacht echter dat
teams als geheel innovatiever worden
vanwege de verschillende invalshoeken van mannen en vrouwen.
De resultaten zijn dus op twee manieren uit te leggen, op een positieve en
een negatieve wijze: vrouwen doen
niet onder voor mannen en het maakt
niet zo heel veel uit hoe de verhoudingen liggen, maar de verwachting is
wel dat diversiteit bijdraagt aan het innovatieve vermogen, of: de IT-sector is
Vier op de tien Nederlandse IT’ers
verwachten een hogere kwaliteit van
dienstverlening als de man-vrouwverhouding op de werkvloer gelijker
wordt. Een ruime meerderheid verwacht echter geen noemenswaardige
veranderingen door verandering in de
verhouding tussen mannen en vrouwen op de werkvloer. Daarop duidt
onderzoek onder 1.000 IT’ers door
recruitmentbureau Computer Futures.
Naast hogere kwaliteit van werk geven
enigszins vrouwvijandig en de grote
meerderheid van mannen vindt vooral
dat zij in de meerderheid moet blijven.
Acceleratorprogramma voor
blockchaintoepassingen
gelanceerd
Technologieleverancier en adviseur
voor de financiële sector Synechron
lanceert een cloudgebaseerd acceleratorprogramma met zes blockchainapplicaties, waarmee financiële
dienstverleners ‘binnen enkele weken’
operationeel kunnen zijn. Klanten
kunnen gebruikmaken van de modulaire code en een sandboxomgeving
die ontwikkelingsduur, infrastructuur
en investeringen beperkt houden.
De blockchain-accelerators zijn op een
agile manier ontworpen en gebouwd
met blockchaintechnologieën zoals Ethereum, Hyperledger, Eris en
Ripple. Ze zijn volgens Synechron
compatibel met hedendaagse hybride
cloudomgevingen, waardoor banken
en verzekeraars kunnen experimenteren met blockchain zonder dat extra
investeringen nodig zijn en zij sneller
toepassingen kunnen lanceren.
Synechron ziet zes gebieden waar financiële dienstverleners blockchain kunnen
toepassen in hun bedrijfsvoering: global
payments, trade finance, smart margin
calls, insurance claims processing, KYC
(know your customer) en mortgage
financing & processing – met lagere
operationele kosten en een verbeterde
fraudebestrijding tot gevolg. De zes applicaties zijn dan ook precies voor deze
toepassingsgebieden ontwikkeld.
and
•v e
maand
maand
quote
nd
•va e
“Er zou niet zoiets moeten bestaan als IT-management. Waarom zou je ergens
in een hoekje van de organisatie besluiten nemen over zaken die aan alle processen raken? Waar vrijwel elke medewerker mee te maken krijgt? Op de keper
beschouwd is IT-management een curieuze ontwikkeling.”
Mario Kortman, Programmamanager Digitalisering bij Waternet, in het interview op p. 10 van dit nummer.
N U M M E R
4
2 0 1 6
9
thema agile development
10
T I J D S C H R I F T
I T
M A N A G E M E N T
VAN ONZE REDACTIE | FOTO’S: ROELOF POT
Mario Kortman, Waternet: “Het ligt niet aan de mensen maar aan de organisatievorm”
AGILE
OVERHEID
Het Amsterdamse Waternet is het eerste watercyclusbedrijf in Nederland. Sinds 2006 verenigt het
een afvalwaterbedrijf, een drinkwaterbedrijf en een bedrijf dat zich bezighoudt met hemelwater – inclusief de taken van het waterschap. En daarmee is het overheidsbedrijf uniek in Nederland. In 2015
is onder leiding van Programmamanager Digitalisering Mario Kortman een veranderprogramma ingezet: van de traditionele ‘geharkte’, hiërarchische organisatie naar een agile vorm. “De logheid van
veel ondernemingen en instellingen ligt vaak niet aan de mensen, maar aan de organisatievorm. Die
triggert namelijk onwenselijk gedrag, zoals hokjesdenken en een gebrek aan eigenaarschap. In onze
agile teams werken we wel tien keer zo effectief en efficiënt. Gewoon, met onze eigen mensen en met
veel plezier. En met spectaculaire resultaten.”
M
ario Kortman studeerde politieke
filosofie en politicologie in Leiden
en wordt in 2008 parttime projectleider bij het net twee jaar jonge Waternet, een uitvoeringsorganisatie van de
gemeente Amsterdam en het Waterschap
Amstel, Gooi en Vecht. Hij doet daar
vooral projecten die dicht tegen het politieke bestuur aan zitten en ontfermt zich
over vastgelopen of risicovolle projecten.
Hoewel daar niet zijn roots liggen, krijgt
Kortman vanaf dat moment dagelijks
met informatietechnologie te maken: er
zijn immers nauwelijks meer veranderingen denkbaar zónder IT-component.
Zijn filosofie: “Er zou niet zoiets moeten
bestaan als IT-management. Waarom zou
je ergens in een hoekje van de organisatie besluiten nemen over zaken die aan
alle processen raken? Waar vrijwel elke
medewerker mee te maken krijgt? Op de
keper beschouwd is IT-management een
curieuze ontwikkeling.”
Dogmatisch agile
Van de in totaal 2.200 medewerkers
waren in 2015 binnen Waternet zo’n 160
mensen in huis bezig met informatisering en automatisering – I&A. “Development vond zelden binnen het bedrijf
of binnen de business plaats en dan
noemden we het meestal databeheer of
procesautomatisering”, zegt hij. “Eigenlijk deden we zoveel mogelijk buiten de
deur. Ook in het nieuwe agile-domein
‘klantdigitalisering’ komt ongeveer een
derde van de 110 mensen uit de busi-
“Van de digitaliseringsdrang was niets terug
te vinden in de organisatiestructuur”
ness, een derde uit de eigen IT en een
derde van externe leveranciers. Maar
dan wel samen in agile teams. Fysiek.”
N U M M E R
4
➼
2 0 1 6
11
thema agile development
Kortman is begin 2015 heel dogmatisch
begonnen met het doorvoeren van de
agile-uitgangspunten. “Dogmatisch
heeft gauw een negatieve klank, maar
we leggen gewoon heel veel focus op
de agile-principes en dan vooral de verbinding met lean. We vormen daarom
alleen business-IT-teams die waarde
toevoegen voor de eindklant. Je zoekt
hier dan ook tevergeefs naar een team
dat ‘meer inzichten’ geeft, of iets anders
vaags. Elk team heeft heldere businessdoelen en bestaat uit alle mensen die
nodig zijn die te realiseren – of ze nu bij
ons op de payroll staan of niet”, aldus
Kortman. Anderhalf jaar geleden werd
in het kader van klantdigitalisering
voorzichtig begonnen met twee van dergelijke agile teams, in 2016 is dat uitgegroeid tot een cluster van acht en begin
2017 verwacht hij vijftien à twintig teams
aan het werk te hebben, gevormd door
negen tot twaalf mensen – waarmee dan
het grootste deel van de IT-organisatie
over agile teams uitgesmeerd zal zijn.
met eigen mensen, ook met medewerkers die gemiddeld al zo’n achttien
dienstjaren achter hun naam hadden
en van allerlei afdelingen afkomstig
waren. Mensen uit de oude cultuur dus.
“Die krijg je ook niet in een half jaar
om”, weet Kortman. “Maar er wordt
veel te gemakkelijk geroepen dat de zittende mensen het probleem vormen. Ik
bestrijd dat. Het is onze ervaring dat als
je een nieuw gevormd team écht ruimte
en verantwoordelijkheid geeft, de
kanteling naar de nieuwe agile cultuur
veel sneller komt dan verwacht. Zolang
mensen maar échte ruimte krijgen.”
Zo ontstond tussen directie en werkvloer
wat Kortman in termen van mandaat
een ‘bubbel’ noemt, een gebied met
minimale organisatiespelregels, behalve
die waar je absoluut niet omheen kunt.
In essentie is agile werken invoeren een
zoektocht naar verandering in gedrag,
naar meer samenwerken, meer focus op
het resultaat en voortdurend over ‘het
hekje’ kijken, zowel binnen als buiten het
Fundamenteel probleem
Het was zo rond 2014 inmiddels een
gegeven dat digitalisering van de
dienstverlening echt sneller moest. Ook
de rijksoverheid dringt daar landelijk op
aan. Toch hadden in 2014 twee projecten
die het selfserviceloket van Waternet
moesten verbeteren het moeilijk. Het bedrijf heeft 1,2 miljoen klanten, verstuurt
jaarlijks 3 miljoen rekeningen – en kreeg
in 2013 ongeveer 400.000 telefoontjes over
die facturen. “Het goedkoopste belletje
kost 5 euro, de duurste wel meer dan 100
euro. Dat daar verbetering te behalen
moest zijn, was duidelijk. Wat ging er
mis in die projecten?” Kortman beantwoordt die vraag zelf: “Omdat er van die
digitaliseringsdrang helemaal niets terug
te vinden was in de organisatiestructuur.
Online werd beheerd door anderhalve
man en een paardenkop, die een heel
kluitje externe partijen moesten aansturen. Als A iets belangrijk vond, dan
was B wel met iets anders bezig. En ga
zo maar door. De organisatievorm, dát
was het fundamentele probleem. Niet de
techniek, niet het leveren van diensten
en zeker niet de mensen. Maar wel de
manier waarop je samenwerkt.”
Waternet verliet de traditionele ‘geharkte’, hiërarchische organisatievorm
en formeerde begin 2015 de eerste
autonome agile teams. Samengesteld
12 T I J D S C H R I F T
I T
“Er worden geen wonderen verricht, het is
een doorsnee sociaal
gewenningsproces”
team. “Er zit daarom niet te veel variëteit
in het agile proces: de teams volgen hetzelfde ritme en leveren elke drie weken
op. Zo ontstaat er voorspelbaarheid en
gewenning in de hele organisatie.”
Stijgende klanttevredenheid
“Als reactie op deze aanpak krijg ik
voortdurend dezelfde opmerkingen”,
vertelt Kortman. “De eerste is: je hebt
zeker uitzonderlijk slimme mensen. De
tweede: je hebt een directie die verliefd
is geworden op agile. En de derde: je
beschikt over een onuitputtelijk budget.
De vraagstellers moet ik teleurstellen met
drie keer een ontkennend antwoord. Er
worden geen wonderen verricht, het is
een doorsnee sociaal gewenningsproces. Alleen met heel andere resultaten.
Volgens mij werden er in 2012 per jaar
ongeveer veertig interne projecten
gedaan met vijf projectleiders. Er was
een ‘versteend’ IT-projectportfolio met
M A N A G E M E N T
iets van 250 projecten, allemaal even belangrijk. Een team levert nu in zes weken
– twee sprints – al meer resultaat dan een
project in de oude situatie. Dat maakt een
team dus rond de tien keer zo effectief.
Die cijfers overtuigen iedereen.”
Als voorbeeld van een tastbaar resultaat noemt hij de sterke stijging van de
klanttevredenheid, die in anderhalf jaar
tijd van 6,2 naar 7,9 is gegaan. “In 2014
hadden we per maand 4.000 bezoekers
van onze selfservice ‘Mijn Waternet’ –
nu zijn dat er soms 15.000 per dag. Dat
verschil is zo fundamenteel, zo groot,
omdat je alles richt op maximaal effectief samenwerken en dan alleen maar
hoeft te focussen op: hoe draagt elk
ingezet uur bij aan het overkoepelende
doel ‘maak de klanten tevreden’?”
Overheid Nieuwe Stijl
Kortman zegt dat het belangrijk is als
een overheidsorganisatie kan laten zien
dat ze meer dingen doet dan diensten
leveren, beleidsdocumenten produceren en facturen sturen. “We kunnen de
samenleving een beetje prettiger maken.
Vergeet niet, een stad als Amsterdam
kan zonder het waterschap gewoon niet
bestaan. We mogen dat wat meer laten
blijken. Daarom ontwikkelen we nieuwe
vormen van dienstverlening. We leggen
bij digitale belastingaanslagen uit wat
er gebeurt van dat geld. Ook kijken we
hoe we onze bak data kunnen verbinden
aan problemen van onze klanten. Met
uitgekiende toepassing van technologie
en processen kunnen we daar slimme
verbindingen tussen leggen. Op basis
van een geraffineerd profiel kunnen we
bijvoorbeeld snel herkennen of iemand
een potentiële klant voor de schuldhulpverlening is. En nu al regelingen treffen,
zodat hij daar niet in terechtkomt. We
ontwikkelen een LoRa-sensornetwerk
om onze assets – dijken, rioleringen,
leidingen, gemalen en pompen – op een
heel doordachte manier te kunnen onderhouden. Op de 160 km aan Amsterdamse grachten varen 10.000 boten, die
door ons via de gratis app ‘Vaarwater’
inzicht hebben in eventuele filevorming
op het water. Vaarwater heeft alle grote
marketingprijzen gewonnen en inmiddels meer dan 80.000 gebruikers. En we
hebben alle vaar- en ligvergunningen
verstrekt in de vorm van RFID-chips.
Per jaar lichtten we voorheen een paar
honderd gezonken boten uit het water à
Mario Kortman,
Programmamanager Digitalisering bij Waternet:
“Er wordt veel te gemakkelijk
geroepen dat de zittende
mensen het probleem
vormen. Ik bestrijd dat.”
5.000 euro per operatie – die dan nog verhaald moeten worden op de eigenaren.
Nu we die van tevoren kunnen waarschuwen als geconstateerd wordt dat de
boot water maakt, is het aantal lichtingen
gedaald met enkele tientallen per jaar.
Dat scheelt én de booteigenaren én de
overheid dus geld. Het kernidee achter
al die zaken is: ga met een leeg vel papier
rond de tafel zitten en vraag je met elkaar
af hoe je een bepaald probleem kunt
oplossen. Met techniek en data.”
Tribe leads
De eerste twee agile teams, de best
functionerende van de acht, zullen
opnieuw ondergebracht worden in de
businesslijn. Kortman juicht dat toe:
“Die teams hebben mij niet meer nodig.
Mijn rol is in de loop van de tijd dus ook
veranderd. Ik ben vorig jaar begonnen
als programmamanager klantdigitalisering. Die rol wordt nu in de organisatie vast belegd bij een regisseur van
een waardedomein, vergelijkbaar met
een ‘tribe lead’. Er is al een domeinregisseur ‘digitalisering van de klant’
en er komen nog domeinregisseurs
‘digitalisering van de medewerker’ en
‘digitalisering van de assets’. Als er drie
tribe leads zijn, wordt mijn nieuwe rol
die van overkoepelend regisseur, die
bedrijfsbreed verantwoordelijk is voor
digitalisering. Dat is heel breed, van de
impact van kunstmatige intelligentie en
robotisering tot het agile-gedachtegoed
en innovatie in onze IT-voortbrenging.
Die soort van vierde tak stuur ik via
de drie tribe leads aan. Zo ontstaat een
soort matrixorganisatie van tribes en
functionele ketens over elkaar.”
Ontwrichting operationsmodel
“Als we een jaar geleden dit gesprek
gehad zouden hebben, zou ik echt
gedacht hebben dat kennisachterstanden, techniek, beschikbare middelen
en het gegeven dat we niet makkelijk
aan nieuwe mensen kunnen komen, de
voornaamste issues waren. In de fase
waarin ik nu zit begrijp ik dat veel terug
te voeren is op gedrag en conditionering”, zegt Kortman. “Een heel groot
deel van traag, inflexibel of weinig effectief opereren als organisatie of team valt
terug te voeren op de organisatievorm.
Die triggert vaak onwenselijk gedrag,
zoals bijvoorbeeld wederzijds wantrouwen tussen ‘planners’ en ‘uitvoerders’.
Digitalisering heeft wel een maar,
benadrukt hij: “Op den duur ontwrichten we ons eigen operatingmodel. Want
verregaande digitalisering kan banen
kosten bij groepen waarvoor je niet
gemakkelijk iets anders vindt. Je vormt
dan een bedreiging voor de manier
waarop je werkt die zo groot is, dat je er
eigenlijk helemaal niet zo gelukkig mee
zou kunnen zijn. Daar moet je als organisatie heel erg goed over nadenken. En
bedenken hoe je het dan wél gaat doen.
Dat je wel de digitale toekomst ingaat,
maar oog hebt voor de mensen die kunnen achterblijven”, aldus Kortman.
N U M M E R
4
❉
2 0 1 6
13
thema agile development
Veelgemaakte fouten bij agile softwareontwikkeling
14
T I J D S C H R I F T
I T
M A N A G E M E N T
VAN ONZE REDACTIE
De beloften van agile development zijn groot, maar uit de
verf komen doen agile opgezette
ontwikkeltrajecten lang niet
altijd. Wat zijn de grootste valkuilen die succes in de weg staan?
B
innen het manifest voor agile
development (zo’n vijftien jaar
geleden in het leven geroepen als
alternatief voor de traditionele ‘watervalmethode’ voor softwareontwikkeling) draait alles om twaalf principes.
De centrale uitgangspunten van agile
softwareontwikkeling: mensen en hun
onderlinge interactie (boven processen
en tools), werkende software (boven
allesomvattende documentatie), samenwerking met de klant (boven contractonderhandelingen) en het soepel
inspelen op verandering (boven het
strikt volgen van een plan). De beloften
van agile softwareontwikkeling zijn
groot: de aanpak leidt idealiter tot onder
meer overzichtelijke en beheersbare projecten, tot meer betrokkenheid van de
individuele teamleden en tot de snelle
oplevering van werkende producten.
Bezetting
Toch lukt het lang niet alle organisaties
om de agile-doelen te bereiken en de op
papier grote beloften waar te maken.
Hoe komt dat? Volgens senior engineeringmanager Bruce Epstein van de
Amerikaanse dienstverlener Novantas
zijn er grofweg acht redenen te noemen
waarom agile lang niet altijd goed van
de grond komt, zo schrijft hij in een blog
op LinkedIn. Een eerste reden voor (in
meer of mindere mate) mislukte agile
projecten is gelegen in een gebrekkige
personele bezetting. Alhoewel het voor
de hand ligt om iemand met agilekennis aan het hoofd van een team te
zetten, gaat het op dit punt opvallend
genoeg nog regelmatig mis. Agile
werken is niet iets dat je van de ene op
de andere dag doet; het heeft tijd nodig
voordat een team de agile-principes
volledig in de vingers heeft. Onontbeerlijk is daarbij een ‘scrummaster’ of
agile-coach met voldoende kennis van
productmanagement, ontwikkelingen
en ontwerp in het algemeen en agile in
het bijzonder. Alleen dan zal hij of zij in
staat zijn om tekortkomingen te signaleren en richting te geven aan het team.
Sprintplanning
Een andere veelgemaakte ‘fout’ is gelegen in de wijze van communiceren; te
vaak kiezen teams standaard voor dagelijkse ‘stand-upbijeenkomsten’ – óók
als er weinig te melden valt. Vaak is
een frequentie van maximaal twee bijeenkomsten per week effectiever, aangevuld met communicatie via e-mail,
instant messaging of (nog beter) een
agile-workflowtool, zoals Jira Agile.
Ook de zogenoemde ‘sprintplanningbijeenkomsten’ – waarbij alle uit te
voeren werkzaamheden gezamenlijk
worden gepland – schieten hun doel
regelmatig voorbij; te vaak verworden
ze tot ontwerpbijeenkomsten waarbij
de uitgangspunten van design worden
besproken. Idealiter blijft het aantal
sprintplanningsessies beperkt tot één
uur per twee weken aan ontwikkeltijd.
In zo’n sessie licht de producteigenaar
kort de prioriteiten voor de komende
sprint toe en wordt er een gezamenlijk
doel bepaald. Uiteraard is er zo nodig
ruimte voor kleine vragen, maar de
sprintplanningsessie is niet de juiste
plek voor het bespreken van specifieke
zaken als het ontwerp van een scherm
of de overkoepelende productvisie.
Verder is het goed te beseffen dat agile
geen wondermiddel is dat werkt tegen
een slechte ontwikkelaar, een ongefocuste producteigenaar of een niet goed
uitgebalanceerd team. Wél kan agile
helpen om teams productiever en met
meer focus te laten werken. Teamleden die niet voldoen? Train of vervang
ze of kijk of ze wellicht beter tot hun
recht komen in een andere rol.
QA
Quality assurance (QA) wil nog wel
eens een ondergeschoven kindje zijn
binnen agile-teams. Onterecht: juist
ontwikkelteams waarvan QA integraal deel uitmaakt, boeken de beste
resultaten. Als de QA-medewerker
niet aanwezig is tijdens stand-ups en
de sprintplanningsessies, leidt dat er
vaak toe dat de QA-cycle uit de pas
gaat lopen met de ontwikkelingssprint – met alle gevolgen van dien
voor de focus en het momentum van
het project. Is er geen geschikte QA’er
voorhanden? Overweeg dan om er een
in te huren of om de verantwoordelijkheid voor de kwaliteitscontrole bij een
of meerdere teamleden te beleggen.
Backlog
Verder staat of valt het succes van
agile met onderling vertrouwen en
communicatie in twee richtingen. Nu
wordt agile vaak gebruikt om developers ‘achter de vodden’ te zitten, terwijl idealiter alleen de ontwikkelaars
bepalen hoeveel items van de backlog
naar de huidige sprint verplaatst kunnen worden. Een andere veelgemaakte fout – zeker binnen teams die hun
eerste schreden op het agile-pad zetten – is het definiëren van te veel of
juist te weinig taken en user stories,
Agile: geen wondermiddel tegen slechte
ontwikkelaars
of het simpelweg slecht definiëren
hiervan. Van te weinig taken en user
stories is vooral sprake in projecten
die van meet af aan volgens de agilerichtlijnen worden opgezet. Aan de
producteigenaar de taak om heldere
aanwijzingen te formuleren voor
de huidige sprint en de twee à drie
sprints daarna, zodat ontwikkelaars
alleen aan de slag gaan met uitgewerkte ideeën. Tegelijkertijd hebben
projecten die hun oorsprong hebben
in de traditionele watervalmethode
en pas later in agile-vorm zijn gegoten, vaak te lijden onder een backlog
van honderden niet-gecategoriseerde
taken en bugs. Idealiter worden taken
opgehelderd en geprioriteerd, zodat
het team tijdens de eerste sprints
momentum kan opbouwen.
Geduld
Ten slotte gaan veel projecten ten
onder aan een gebrek aan geduld
en aan het niet goed omgaan met de
tijdsvereisten. Vaak kost het zo’n zes
sprints (oftewel zo’n 12 tot 24 weken)
om obstakels in de workflowsoftware
op te lossen, goede user stories te
schrijven en een juiste inschatting te
maken van de daarvoor benodigde
tijd, en om de juiste ontwikkelsnelheid te bepalen. Oftewel: agile takes a
day to learn and a lifetime to master.
N U M M E R
4
❉
2 0 1 6
15
thema agile development
Outputgestuurd werken haalt het hoogste rendement uit agile softwareprojecten
CONTROLE
OVER DE CHAOS
De omslag van de watervalmethode naar een agile
aanpak kan de nodige huivering met zich meebrengen.
Managers geven inhoudelijke
zeggenschap over soms grote
softwarerealisatieprojecten
immers uit handen aan de
werkvloer. Hoe zorg je ervoor
dat je met een agile-developmentaanpak toch de vinger
aan de pols houdt en de stip op
de horizon rond budget, kwaliteit en deadline niet uit het
oog verliest? En hoe manage je
een leverancier als een agile
aanpak het uitgangspunt is?
B
ij de traditionele watervalontwikkelmethode was de projectleider
gewend om een schatting op te
halen over het ontwerp-, programmeeren testwerk dat gedaan moest worden
en op basis daarvan een team aan het
werk te zetten en te houden. Bij een agile
aanpak is die verantwoordelijkheid veel
meer naar het team gedelegeerd. De
producteigenaar houdt wel een release-
16 T I J D S C H R I F T
I T
planning aan en bepaalt de scope en de
prioritering, maar het team beslist zelf
hoeveel werk zij uit een productbacklog
daadwerkelijk in een specifieke sprint
oppakken. Dat werkt beter dan met
druk van bovenaf als een geheel aan een
deadline van een half jaar of langer te
werken. Zo’n top-downbenadering gaat
vaak ten koste van de kwaliteit van het
product en de motivatie van het team.
Bij de agile aanpak geef je mensen zelf
de verantwoordelijkheid, waardoor zij
intrinsiek gemotiveerd zijn om een maximale inspanning te leveren. Bovendien is
softwarekwaliteit en afstemming op de
beoogde doelgroep voortdurend in beeld
omdat er na iedere sprint een werkbare
versie van de software opgeleverd moet
worden die ook wordt gedemonstreerd.
Hoe verfrissend die aanpak ook mag
zijn, het spanningsveld tussen de
kosten, de deadline, de kwaliteit en
de scope bestaat nog steeds in grotere
agile softwareprojecten, stelt Richard
Sweer,1 die als projectmanager betrokken is bij verschillende grootschalige
softwareprojecten. “Het agile werken
heeft zijn toegevoegde waarde omdat
het organisaties focus geeft om tijdens
M A N A G E M E N T
iedere sprint zoveel mogelijk waarde
voor de business te leveren”, aldus
Sweer. Een belangrijk voordeel van de
agile aanpak is dat de requirements
niet in beton gegoten zijn en dat er in
alle iteraties meer aandacht is voor
werkbare software. Voortdurend
wordt de vraag gesteld welke functionaliteit belangrijk is voor de eindgebruikers en welke businesswaarde de
organisatie wil realiseren.
Adequate inschatting
Om het budget en de planning van een
groot project adequaat in te schatten
werkt Sweer het liefst met een zo concreet mogelijke inschatting van de functionele omvang. “Zoals een tegelzetter
telt in vierkante meters, zo berekent een
automatiseerder de omvang van een softwareproject in functiepunten2”, vertelt
Sweer. “Deze methode is in de jaren zeventig en tachtig ontwikkeld, maar heeft
ook in de agile-wereld van scrumteams
en producteigenaren niets aan kracht
ingeboet, omdat je bij het juist toepassen
van functiepuntanalyse dicht bij de taal
van de gebruiker blijft.” Daarnaast is het
een bewezen en objectieve methode om
TEKST: HAROLD VAN HEERINGEN EN SYTSE VAN DER SCHAAF
de functionele omvang van transactieverwerkende informatiesystemen vast
te stellen. Met onderzoek is bewezen dat
de functionele omvang de belangrijkste
factor is die kosten en doorlooptijd van
softwareprojecten bepaalt. Wereldwijd
zijn er vijf ISO-normen beschikbaar. De
meestgebruikte internationale methoden
zijn die van de NESMA (ISO 24570) en
van de IFPUG (ISO 20926).
Functiepunten maken outputgestuurd
werken mogelijk. “In een groot langlopend softwareproject helpt deze aanpak
om de benodigde uren, kosten teamomvang en doorlooptijd te begroten. Hiernaast is het mogelijk om de voortgang
van het project te bewaken op basis van
geleverde output. Dit maakt het mogelijk de kwaliteit van software op peil te
houden”, vervolgt Sweer. “Als je het goed
aanpakt, dan zul je verbaasd staan wat je
te weten kunt komen over de productiviteit en de kwaliteit van de gemiddelde
agileteams. Vragen zoals: hoeveel fouten
per functiepunt worden door het team
gemaakt en wat is de productiviteit van
een specifiek team? De teams die bovengemiddeld presteren haal je er zo uit,
maar ook de teams die minder goed zijn
in hun werk. Op een groot project heeft
dit concrete zicht op de productiviteit en
kwaliteit absoluut toegevoegde waarde.”
correctieve maatregelen nodig zijn als
blijkt dat de minimaal gewenste functionaliteit nog niet op het gewenste
moment beschikbaar zal zijn.”
Achterhaald
In de agile-wereld, waarin alles draait
om ‘user stories’ en ‘agile delivery’,
bestaat de neiging om projectverantwoording en documentatie als
achterhaald en overbodig te bestempelen. “Het gevaar van agile werken
is dat mensen hierin doorschieten”,
stelt Sweer. “Kijk naar het verleden en
houd vooral vast aan goede dingen als
je nieuwe wegen inslaat. Van functiepunten wordt nogal eens gezegd dat
het vrij oud en niet tastbaar genoeg is
en dat het toekennen van story points
beter werkt. Binnen de context van het
specifieke project mogen story points
zeker hun waarde hebben, maar een
objectieve maatstaf is het niet. Het meten van de functionele omvang helpt
om grip te krijgen op de totale kosten
van het project. Het is belangrijk ook
om te begrijpen hoeveel en welke
functionaliteit op welk moment in de
toekomst afgerond is en of er wellicht
Managers geven
zeggenschap uit handen
aan de werkvloer
Om dezelfde reden houdt Sweer
ook vast aan bijvoorbeeld productbeschrijvingen volgens de Prince2methode die hij onderdeel maakt
van de ‘definition-of-done’ oftewel
de criteria waaraan na iedere sprint
voldaan moet zijn om de sprint als
afgerond te bestempelen. Hetzelfde
geldt voor documentatie rondom het
voortbrengingsproces of beheer van
de softwarecode. Als je documenteert
volgens de lean-principes dan draagt
ook dit element bij aan het ‘agile’
maken van een project. Story points
en functiepunten vullen elkaar heel
N U M M E R
4
➼
2 0 1 6
17
thema agile development
goed aan. Schatten is de taak van het
team. De backlog-items worden van
een aantal story points voorzien door
het team. Dit is alleen geen aspect van
de omvang, maar van de inspanning.
De inschattingen rond story points
zijn daarmee relatief. Metingen die
gebaseerd zijn op story points zijn om
die reden niet te gebruiken buiten het
betreffende team en dus ook niet om
te vergelijken of te benchmarken.
Functiepunten kunnen ook helpen bij
het opsporen van verbeterpunten. Omdat het een objectieve maatstaf is, valt
het ook in te zetten bij een terugblik op
het scrumproces om de punten eruit
te halen waar zaken te optimaliseren
zijn. En ook de toepassing van de agile
development in de eigen organisatie
kan tegen het licht gehouden worden.
Er zijn mensen die stellen dat agile
softwareprojecten door voortschrij-
HET NUT VAN METEN
Het meten van de functionele omvang
van de werkpakketten voor het bepalen
van de productiviteit en kwaliteit van
interne en externe ontwikkelteams vormt
een belangrijke factor in het besturen
en bijsturen van complexe softwareprojecten. Het is daarmee ongeacht de
methode en de leverancier een belangrijk
middel om het gewenste projectresultaat
te behalen en daarmee businesswaarde
te realiseren. Hoe het meten van functiepunten plaatsvindt, staat daar in principe
los van, maar automatisch meten zorgt in
ieder geval voor consistentie, herhaalbaarheid, objectiviteit en onafhankelijkheid van schaarse specialisten.
Het meten van de functionele omvang kan
onder andere onderstaande rollen vervullen.
Functiepuntanalyse kan worden
gebruikt om de functionele omvang
van een productbacklog te meten. Met
behulp van relevante historische data
en parametrische modellen kan een
software cost engineer vervolgens een
accurate begroting maken van het deel
van de backlog dat op een bepaald moment gereed is per teamomvang.
Een functiepuntanalyse helpt
om de aanpak en voortgang van
een agile softwareproject op de voet te
volgen. Het kan zicht geven op punten in
het complexe project waar extra maatregelen nodig zijn om de productiviteit op
peil te houden zodat het einddoel van het
project haalbaar blijft.
1.
2.
Functiepunten zijn objectief en
vergelijkbaar tussen projecten of ze
nu van tevoren gemeten zijn, tijdens
of na afloop van een project. Zet je
in eenzelfde project de kengetallen
van de story points naast die van de
functiepunten dan kun je de waarde
van de teaminschattingen vaststellen.
18 T I J D S C H R I F T
I T
3.
Een functiepuntanalyse is in te
zetten om grip te krijgen op de
impact van procesverbeteringen. Door de
functionele omvang te kwantificeren kun je
de effectiviteit van procesverbeteringen in
het softwarerealisatieproject doormeten.
Functiepuntanalyse is van nut bij
de contractering van een externe
leverancier. Een prijs per functiepunt is een
beter middel om een vinger te krijgen achter
de toegevoegde waarde van leveranciers
dan de gebruikelijke methode om een vast
uurtarief af te spreken. Het uurtarief is vaak
gerelateerd aan de interne kostenberekening van de leverancier en heeft geen enkele
relevantie voor de businesswaarde die deze
leverancier uiteindelijk gaat leveren aan zijn
klanten. De prijs per functiepunt in combinatie met afspraken over de kwaliteit van de
opgeleverde software zijn een zo concreet
mogelijke indicatie hoe goed een leverancier
in staat zal zijn om software op te leveren
met een maximale toegevoegde waarde.
Een functiepuntanalyse is te gebruiken om een baseline vast te stellen
voor supplier performance measurement:
de productiviteit, kosten, kwaliteit en timeto-market in een specifiek project. Op basis
van de baseline wordt het mogelijk realistische targets af te stemmen met betrekking
tot metrieken als productiviteit, kosten per
functiepunt en time-to-market en de trends
te volgen door de tijd. Omdat functiepuntanalyse een internationale ISO-standaard
is, wordt het mogelijk deze metrieken te
benchmarken met de markt.
4.
5.
dend inzicht meer aanpassingen nodig
hebben dan andere ontwikkelmethodes. Dit soort mythes zijn te ontrafelen
door het aantal functiepunten van de
nieuwe en verbeterde functionaliteit te
tellen en zo concreet zicht te krijgen op
de productiviteit van zowel de aanpassing als het hele ontwikkelproces.
M A N A G E M E N T
Maximale impact
Het is de kunst om het meten en documenteren van de software zo in te vullen dat het een minimale impact heeft
op het team, maar een maximale impact
heeft op de performance in een project.
“In de projecten waar ik bij betrokken
ben, werken we met een hulpmiddel als
Team Foundation Server van Microsoft”, vertelt Sweer. “De teamleden die
met zo’n hulpmiddel aan een project
werken, houden er bijvoorbeeld ook
hun uren in bij. Door met verschillende
urencodes per discipline te werken,
kun je automatisch de bijdragen aan
het project inventariseren. Door dit te
combineren met een functiepuntanalyse
wordt het mogelijk de productiviteit van
het totale team en de individuele leden
te analyseren. Zo krijg je zicht op het
aantal uren dat het realiseren van functiepunten kost en kun je voeling houden
met de kwaliteit door het aantal fouten
in de softwarecode te inventariseren.
Dat een functiepuntanalyse veel tijd
kost, is een veelgehoord misverstand.
“Het kost me vaak nog geen tien minuten om de opgeleverde functionaliteit
van een sprint in functiepunten uit te
drukken3”, stelt Sweer. “En het helpt
me enorm om grip te krijgen op de
voortgang en de status van het project.
Het opstellen van een goede fact-based
begroting en het constant bijsturen van
een project aan de hand van productiviteitscijfers maakt dat projecten een stuk
voorspelbaarder worden. Je kunt met
een gerust hart om vijf uur naar huis,
“Functiepuntanalyse
heeft zeker toegevoegde
waarde bij de contractering van een externe
leverancier”
want je weet dat het team op tijd de
juiste resultaten zal opleveren.”
De impact op het team en het proces kan ook in agile teams zonder
specifieke kennis van functiepunten
omlaag omdat er sinds kort een specificatie is die het mogelijk maakt om
functiepunten geautomatiseerd te tel-
➼
N U M M E R
4
2 0 1 6
19
thema agile development
len. “Een van de belangrijkste bezwaren tegen de inzet van functiepunten
is hiermee komen te vervallen”, stelt
André Nadorp,4 managing consultant
en director benchmarking bij METRI.
“Voorheen moesten functiepunten
door gecertificeerde specialisten
worden vastgesteld op basis van de
functionele documentatie. In agile
projecten is vaak een tendens zichtbaar dat het bijwerken van de documentatie een sluitpost op de sprintbegroting is. Het komt nogal eens voor
dat de documentatie niet volledig is
bijgewerkt. Een functiepunt-analist
zal dan het verkeerde aantal functiepunten meten, waardoor een aantal
prestatiecijfers niet meer klopt. Als
je functiepunten geautomatiseerd
meet na afloop van een sprint en deze
omvang verrijkt met data uit de urenregistratie, de defectadministratie en
andere relevante bronnen, dan houd
je continu grip op de productiviteit en
de voorspelbaarheid van het team.”
Functiepunten
zijn objectief en
vergelijkbaar tussen
projecten
Ook op dit punt is er sprake van standaardisatie. In 2015 is de ‘automated
function point’-specificatie vastgelegd
in een internationale standaard (CICQ/
OMG). Op dit moment is alleen de
Application Intelligent Platform tooling van CAST Software in staat om
geautomatiseerd te meten volgens de
AFP-standaard. Er zijn andere tools op
de markt die claimen geautomatiseerd
functiepunten te kunnen meten, maar
die werken vooral volgens de omstreden en alom niet accuraat beschouwde
backfiringmethode, een methode waar
zelfs de uitvinder Capers Jones tegenwoordig fel tegenstander van is. Bij deze
aanpak wordt het aantal functiepunten
gerelateerd aan het aantal regels softwarecode met grote nadelige gevolgen
voor de uitkomsten. “Het geautomatiseerd meten van de functionele omvang
en de structurele kwaliteit van de soft-
20 T I J D S C H R I F T
I T
ware heeft een minimale impact op de
projectorganisatie en het kan een grote
bijdrage leveren aan het succes van het
project”, benadrukt Nadorp.
Contractering
Functiepuntanalyse heeft ook zeker
toegevoegde waarde bij de contractering van een externe leverancier. “Net
als bij andere ontwikkelmethodes is
het bij een agile aanpak nog steeds
belangrijk om een zo concreet mogelijke indicatie te krijgen hoe groot een
project is en hoe goed een leverancier
in staat is om de software te realiseren binnen een bepaalde periode en
tegen een bepaald budget”, vervolgt
Nadorp. “Dit is een beter alternatief
dan uurtarieven met een leverancier
uit te onderhandelen”, aldus Sweer.
“Door vooraf niet alle functionaliteit helemaal uit te ontwerpen zoals
gebruikelijk bij een agile aanpak maar
juist just-in-time voordat het de sprint
in gaat, maakt functiepuntanalyse
juist een geschikt instrument om
de geleverde output te meten en te
bepalen in hoeverre het team marktconform presteert.”
Neem je dat niet mee in de onderhandelingen dan zul je nooit zeker weten
of je niet te veel betaalt of misschien
te weinig waar voor je geld krijgt. Om
vast te stellen of de geleverde kwaliteit
van de dienstverlener marktconform
is moet je aanbiedingen van verschillende leveranciers naast elkaar leggen
en uitvragen wat hun toezeggingen
zijn rond het aantal uren per functiepunt, kosten per functiepunt en het
aantal fouten dat in de opgeleverde
software mag zitten. Hierbij kun je
afspraken maken, ten aanzien van
de productiviteit, maar zeker ook
ten aanzien van de kwaliteit van de
software. “Het is bekend dat een prijs
van een functiepunt afhankelijk is
van verschillende factoren, maar dit
wil niet zeggen dat je geen vaste prijs
per functiepunt kunt afspreken met je
leverancier”, aldus Sweer.
Het wordt in de markt steeds gebruikelijker om een gedegen analyse
te maken van de performance van
een agile-ontwikkelteam door vijf of
zes geplande sprints nauwkeurig te
meten. Hierbij wordt de performance
van het team in termen van geld, tijd
M A N A G E M E N T
en kwaliteit gemeten en vergeleken
met de markt. Om dit (supplier) performance measurement zo optimaal
mogelijk uit te voeren is METRI een
partnership aangegaan met CAST
Software, zodat er geautomatiseerde
functiepuntberekeningen uit te voeren
zijn als onderdeel van een doorlopende supplier-performancemeasurementdienst. Hiernaast krijgt men een
gedetailleerd inzicht in de structurele
kwaliteit van de broncode die wordt
gerealiseerd. Dit alles in overzichtelijke en eenvoudig te interpreteren
managementdashboards, waarin de
status van de applicatie en de trends
in de prestatiecijfers in één oogopslag
duidelijk worden. “Supplier performance measurement maakt het
mogelijk om vast te stellen of de commerciële prijs van de gecontracteerde
leverancier en diens toezeggingen
in de praktijk gerealiseerd worden.
Budgethouders hebben daarnaast een
maat om de omvang van hun software
en de wijzigingen daaraan te kunnen
volgen”, besluit Nadorp.
Harold van Heeringen is senior consultant bij METRI Group en momenteel
Nesma-bestuurslid en president van de
International Software Benchmarking
Standards Group. Sytse van der Schaaf is
Research Consultant bij METRI Group.
NOTEN
1. R
ichard Sweer is een IPMA-B-gecertificeerde projectmanager met meer dan twintig jaar
ervaring als projectmanager, manager in een
demand-supplyorganisatie, kwaliteits- en
lijnmanager. Hij heeft uitgebreide kennis van
en ervaring in de realisatie en implementatie van complexe maatwerksoftware en
standaardpakketten voor middelgrote en
internationale ondernemingen. Hij werkt met
methodes en technieken die het applicatiebeheer en het implementeren van innovatieve technologieën gecontroleerd en zeer
betrouwbaar maken.
2. We spreken hier over een globale functiepuntanalyse conform de NESMA- of IFPUG-telrichtlijnen. Niet alle typen applicaties zijn geschikt voor het tellen van functiepunten zoals
compilers en embedded software. Functiepuntanalyse is met name geschikt voor
transactieverwerkende informatiesystemen
zoals hypotheeksystemen, ERP-systemen en
verzekeringssystemen.
3. A
ls een externe partij de functiepunten moet
meten, kost dit meer tijd.
4. A
ndré Nadorp is managing consultant en
director Benchmarking bij METRI. Hij is verantwoordelijk voor de uitvoering van IT-benchmarks op het gebied van applicaties en het
ontwikkelen van nieuwe producten en diensten
rond het reviewen van applicatieportfolio’s.
❉
column Peter van Eijk
AGILE DEVELOPMENT
VRAAGT OM MODERNE
DIGITALE INFRA
Agile development is helemaal de mode tegenwoordig. Waarom is dat
en wat voor digitale infrastructuren heb je daarvoor nodig?
Vroeger werd businesssoftware vooral geschreven om bestaande bedrijfsprocessen te
automatiseren. Die werden middels software weliswaar wel wat veranderd, maar in de
kern waren de processen niet anders. We denken daarbij dan aan boekhoudsystemen,
roosterplanning, ‘customer relationship management’, enzovoort. Tegenwoordig zien we
dat software niet alleen de bedrijfsprocessen automatiseert, maar deel gaat uitmaken van
het product of zelfs het product is. En die software is dan bovendien ook nog vaak een
online dienst. Denk aan de slimme kamerthermostaat. Ook in financiële dienstverlening is
software meer en meer het hoofdonderdeel van het product: denk aan online bankieren. En
bij sociale media van Facebook tot Relatieplanet is software de dienst.
Peter van Eijk geeft zijn
kijk op nieuwe digitale
infrastructuren en helpt
bedrijven en individuen
hun weg daarin te vinden.
Elk product verandert de wereld die het gebruikt, dat geldt ook voor software. Maar een
veranderende wereld verandert ook de producten die we kunnen of willen gebruiken. Er
ontstaat een soort dans tussen vraag en aanbod. Gaan we vaker buiten de deur ontbijten
omdat er meer mogelijkheden voor zijn, of ontstaan er meer ontbijttentjes omdat we vaker
buiten de deur gaan eten? Net als in een dans is het niet altijd eenvoudig te zeggen wie
door wie geleid wordt. Nu software het product is, gaat het ook meedoen aan die dans, en
dan wordt het belangrijk om sneller aan te passen aan de danspartner. Hoe sneller, hoe
beter. Dat verklaart de noodzaak voor agile development. Tussen wens en realisatie moet
geen twee jaar staan, maar twee weken en liefst nog minder.
Wat voor digitale infrastructuren zijn daarvoor nodig?
Het belangrijkste doel van digitale infrastructuren is het beschikbaar maken van applicatiefunctionaliteit. De kwaliteit daarvan wordt bijvoorbeeld uitgedrukt in het aantal
ondersteunde gebruikers. Bijvoorbeeld: 10.000 gelijktijdige gebruikers op tien locaties met
een responstijd van minder dan vier seconden. Maar met agile development komt daar
een nieuw doel bij: ‘feature velocity’. Dat is de snelheid waarmee nieuwe features kunnen
worden uitgerold. De tijd tussen het bedenken van een feature en het testen van de zinvolheid bij echte gebruikers moet korter zijn dan de tijd waarin de omgeving verandert. In een
dans wil je anticiperen op je partner, niet op diens tenen staan. De digitale infrastructuur
moet daarin geen flessenhals zijn. Dat vraagt een aantal dingen van die digitale infrastructuur zoals automatisch testen, snel op- en afschalen van capaciteit en zo weinig mogelijk
handmatig ingrijpen. Alleen zo kan de doorlooptijd van een wijziging worden verkort.
Kortom: agile development vraagt om cloud computing. Immers: essentiële karakteristieken
van cloud computing zijn onder meer snelle, elastische en zelfbedieningsuitrol van middelen.
Dat is wat nodig is voor agile development. En dan gaat de dans door. Want als dat mogelijk
is zijn er weer nieuwe dingen mogelijk. Betere security bijvoorbeeld. Als je sneller kunt reageren op functionele vragen, kun je ook sneller reageren op securityproblemen.
❉
N U M M E R
4
2 0 1 6
21
CIO Day
CIO of the Year
Award
CIO Dinershow
Join
the
club
CIO
Community
CIO Roundtable
Sessions
NEEM NU EEN ABONNEMENT OP
CIO Online
CIO MAGAZINE
CIO Magazine, hét blad over IT in de boardoom, verschijnt 6 keer per jaar. Een abonnement
kost 175 euro per jaar excl. BTW en loopt automatisch door tenzij 30 dagen voor de vervaldatum schriftelijk wordt opgezegd. Abonnees ontvangen 300 euro korting op de CIO Day.
Ga voor meer informatie en inschrijven naar www.it-executive.nl/abonneer-op-een-magazine
ICT Media BV
ALaan van Voorburg 1, 5261 LS Vught
T073 614 00 70
[email protected]
Wwwww.cioday.nl
Wwww.it-executive.nl
28+29
NOV
2016
KIJK OP WWW.CIODAY.NL/AWARD
service
colofon
TIJDSCHRIFT IT MANAGEMENT
Hoofdredactie
Arnoud van Gemeren
([email protected])
Website
www.it-executive.nl
Eindredacteur
Edith Kroon, [Red.] voor tekst en taal
Fotografie
Mark van der Brink, Erik Fecken, Roelof Pot, Clemens Rikken,
Marcel Willems, Marcel van Hoorn
Manager Vormgeving
Mathieu Westerveld
Vormgeving
Aschwin de Hoog
Contentproductie voor marktpartijen
Contact Media (www.contactmedia.nl)
Drukker
Damen Drukker, Werkendam
Vaste medewerkers
Peter Bakker, Freek Blankena, Chantal Burink, Peter van Eijk,
Hans Lamboo, Paul van der Linden, Joost Peters, Henny van
der Pluijm
Adviesraad
Nard van Breemen (Bird & Bird), Frank Heijtlager (MCXess),
Sander Hoogendoorn, Rudolf Liefers (Liefers Consultancy),
Paul van der Linden (Accenture), Arthur Roumimper (Landal
GreenParks), Bart Stofberg (Quint Wellington Redwood),
Rens van der Vorst (Fontys University).
Uitgever
Rob Beijleveld
([email protected]) Tel. 06-51531551
ICT Media BV
Laan van Voorburg 1
5261 LS Vught
Tel. 073-6140070 Fax. 073-6129997
Publiceren
TITM is er voor leidinggevenden in de ict. In TITM vindt u prikkelende columns, no-nonsense vakinformatie en boeiende interviews met opinion leaders of collega’s bij andere organisaties. Zelf een bijdrage leveren of geïnterviewd worden over een project of een aanbesteding? Met name IT-managers
aan de afnemerszijde van de markt worden van harte uitgenodigd contact
met de redactie op te nemen. Stuur een mail met een beknopt voorstel naar:
[email protected]. De redactie neemt dan snel contact met u op!
TITM in 2016
TITM verschijnt tweemaandelijks.
Sales Manager ICT Media
Bart de Vaan
([email protected]) Tel. 073-6140070
Manager Media ICT Media
Jeffrey Ploeg
([email protected]) Tel. 073-6140070
Traffic advertenties
Jeffrey Ploeg
([email protected]) Tel. 073-6140070
Abonnementen
Een abonnement in Nederland kost 75 euro per jaar exclusief
btw. Prijswijzigingen voorbehouden.
Zie: www.it-executive.nl/abonneer-op-een-magazine
Nicole Scheepers
([email protected]) Tel. 073-6140070
Opgave en vragen over abonnementen:
ICT Media BV
Laan van Voorburg 1
5261 LS Vught
Tel. 073-6140070 Fax. 073-6129997
Site: www.it-executive.nl/abonneer-op-een-magazine
voor abonneren of [email protected] voor adreswijzigingen en opzeggingen.
Nr. 5/6
Thema: DevOps
Special: Trends
Deadline: 14 november
Verschijnt: december
Beëindigen abonnement
TITM is een vakblad. Daarom hanteren wij de opzegregels uit het
verbintenissenrecht. Wij gaan ervan uit dat het blad ontvangen
wordt uit hoofde van beroep. Hierdoor wordt een abonnement
steeds stilzwijgend met een jaar verlengd. Opzegging (uitsluitend
schriftelijk of via [email protected]) dient 30 dagen
voor afloop van de abonnementsperiode in ons bezit te zijn.
Aanlevering van artikelen
Inzending van een artikel naar de redactie ter publicatie houdt
in dat de auteur akkoord gaat met de volgende voorwaarden:
- de auteur heeft het volledige auteursrecht op het werk;
- het artikel is niet eerder, in welke taal dan ook, gepubliceerd;
- met publicatie wordt geen geheimhoudingsplicht geschonden;
- de auteur zal het artikel niet zonder schriftelijke toestemming
van de uitgever elders publiceren.
Artikelen herpubliceren?
Zonder schriftelijke toestemming van de uitgever is het niet
toegestaan om artikelen uit dit blad geheel of gedeeltelijk over
te nemen in eigen of andere media (zoals tijdschriften, websites
en intranet). Geen toestemming is nodig om van een artikel
de titel en inleiding over te nemen (circa 50 woorden) onder
de voorwaarde dat er een goed zichtbare en werkende link of
verwijzing naar de website van dit blad wordt geplaatst.
© ICT Media BV, Vught 2016
Zonder voorafgaande toestemming van ICT Media BV is het
niet toegestaan om door ICT Media BV gepubliceerde artikelen,
onderzoeken of gedeelten daarvan over te nemen, te (doen) publiceren of anderszins openbaar te maken of te verveelvoudigen.
78 T I J D S C H R I F T
I T
M A N A G E M E N T