Veel TeAms werken Op DE HAnDrEm

ITExpert
Agile werken is populair: het levert snel resultaten op. In het bijzonder bij softwareontwikkeling. Toch werken agile-teams vaak ‘op de handrem’ omdat hun waarden en hun manier
van werken conflicteren met die van andere delen van de organisatie. Maar, betogen Daan
Kalmeijer, Anko Tijman en Olaf Agterbosch: agile software development is geen geïsoleerde
ontwikkeling waar de rest van de organisatie niets mee te maken heeft.
door: Daan Kalmeijer, Anko Tijman & Olaf Agterbosch beeld: ANPFoto
Agile-teams opereren in een omgeving
die inherent anders denkt en werkt
Veel teams werken
op de handrem
D
e afgelopen veertig jaar heeft het
vakgebied IT zich ontwikkeld van
een ‘begin maar gewoon met
programmeren’-aanpak naar een
volwassener structuur. We hebben
voor elk aspect van de IT een werkwijze, een
discipline, een methode. We hebben projectmanagement geregeld, programmamanagement, functioneel beheer, technisch beheer,
architectuur, kwaliteitsmanagement. We
blijven die aanpakken natuurlijk continu
verbeteren. Meestal gaat het om verbeteringen
van een aanpak die we al kenden. Soms gaat
het om een aanpak die wezenlijk anders is dan
al de voorgaande. Dit is het geval bij agile
software development. Waar agile wordt
ontwikkeld, zijn de resultaten snel zichtbaar:
de producten hebben een hogere kwaliteit en
sluiten beter aan bij de wensen van de
gebruiker. Maar er ontstaan ook conflicten.
Conflicten tussen de ontwikkelteams en de
omliggende activiteiten en disciplines.
Conflicten
Scrum is een werkwijze die gericht is op een
enkel ontwikkelteam. Zij beschrijft alleen het
werk van de mensen in dat team. Die ‘bescheidenheid’ is karakteristiek voor agile werken.
Men zoekt het in simpele oplossingen en stelt
beperkte doelen, men richt zich op één
probleemgebied: softwareontwikkeling.
Ondanks die bescheidenheid (of misschien wel
juist daardoor) blijken agile-methoden in de
praktijk niet goed samen te gaan met veel
andere processen en werkwijzen in organisaties. Dit komt doordat agile-waarden conflicteren met de waarden van werkwijzen voor die
andere disciplines. Waar agile-methoden de
verantwoordelijkheden zo veel mogelijk
20
Masterclass agile management
Anko Tijman, Olaf Agterbosch en Daan Kalmeijer verzorgen samen met Rini
van Solingen, Roger Wouterse en Hennie Huijgens de Masterclass Agile Management. Deze masterclass – die 26 januari 2015 begint – wordt georganiseerd in een
samenwerkingsverband tussen AutomatiseringGids en de Nyenrode Business
Universiteit.
In zes bijeenkomsten presenteren zij een heldere update over het managen van
agile in een organisatie. Zij zullen vragen beantwoorden als: Wat betekent op een
agile manier werken voor een organisatie of voor een manager? Hoe kunnen meerdere agile-teams met elkaar samenwerken?
Voor meer informatie, ga naar: executiveeducation.nl/agile.
beleggen bij multidisciplinaire teams, zie je dat
de traditionele werkwijzen verantwoordelijkheden vangen in processen, hiërarchieën en
Er ontstaat meer afstand
tussen mensen die moeten
samenwerken
controlemechanismen. Er ontstaat op die
manier alleen maar meer afstand tussen
mensen die zouden moeten samenwerken.
Waar agile ervan uitgaat dat er fouten worden
gemaakt en dat die fouten zo snel mogelijk
gedetecteerd en verholpen moeten worden,
daar proberen traditionele methoden de
processen zodanig in te richten dat er in
theorie geen fouten kunnen plaatsvinden.
Dergelijke verschillen maken dat agile-teams
‘op de handrem’ hun werk moeten doen. Zij
Drie lagen
Wanneer mensen spreken over ‘agile’, dan hebben zij het niet altijd over hetzelfde. In grote lijnen
kennen we drie lagen, drie varianten van agile.
• Eerste laag: agile als kwaliteit
De term agile is niet met één enkel Nederlands begrip te vertalen. ‘Agile zijn’ betekent dat een
persoon of organisatie wendbaar, flexibel of aan-pasbaar is. Welke organisatie wil er nu niet
wendbaar zijn?
• Tweede laag: agile als instrument, als werkwijze
De meest gebruikte agile-methode is Scrum. Scrum is een lichtgewicht proces dat met zo min
mogelijk ceremonie, rollen en artefacten werkende software oplevert.
• Derde laag: agile als verzameling waarden
Een van de eerste uitingen van agile is het Agile manifesto. Dit beschrijft wat er belangrijk zou
moeten zijn in het vakgebied IT (en dat we in de
praktijk helaas vooral tegengestelde ontwikkelingen zien).
Als iemand roept ‘Wij moeten meer agile worden!’, dan is het belangrijk om na te gaan over
welke betekenis van agile hij het heeft. Moeten we wendbaarder worden? Moeten we (meer)
Scrum gaan doen? Moeten we meer in de geest van agile-waarden gaan opereren? Alledrie?
Is Scrum als methode mager en lichtgewicht? Wat betekent dat voor de wijze van samenwerken
met leveranciers. Gaan we voor uitkomstgerichte of gedragsgerichte overeenkomsten? En wie
bepaalt dat allemaal?
opereren in een omgeving die inherent anders
denkt en anders werkt. Dit begint al vóór de
eerste stappen van het project: de inkoop. Wie
op zoek gaat naar een leverancier en de hoop
heeft om samen met die leverancier een
agile-ontwikkeltraject te beginnen, die vangt
meestal bot bij de eigen inkooporganisatie.
Traditionele inkoopprocessen kunnen helemaal
niet overweg met agile-partijen. Die inkoopprocessen verwachten dat leveranciers zich
committeren aan zaken die voor een agileleverancier als pervers gelden. In tegenstelling
tot de traditionele inkoopprocessen passen bij
onzekerheid over de uitkomst van een
ontwikkeltraject gedragsgerichte contracten.
Uitkomstgerichte contracten passen vooral
bij duidelijk gedefinieerde resultaten.
Dan zijn er de budgetrondes. Naarmate het
spannender wordt in een organisatie moeten
we steeds vroeger en met steeds meer detail
aangeven wat er voor het aangevraagde budget
opgeleverd gaat worden. Agile-projecten
zouden het liefst iets opvoeren als ‘wij gaan
datgene doen wat voor de gebruiker op dat
moment de meeste waarde oplevert’, maar
daar zijn de mensen van de budgetronde
meestal niet tevreden mee. Waar bij traditionele methoden opdrachtgevers vaak lastig te
bewegen zijn mee te denken over de eisen en
wensen van de op te leveren oplossing, wordt
agile werken vaak als vrijbrief gebruikt om
daar helemaal niets van te vinden: agile
werken wringt met andere werkwijzen.
Zelfs in zo’n conflicterende context blijken
agile-teams productiever te zijn dan traditioneel georganiseerde teams. Die successen
leiden ertoe dat steeds meer organisaties op
zoek gaan naar manieren om het conflict
tussen agile-methoden en omliggende
methoden (voor productontwikkeling,
projectmanagement, inkoop, budgettering,
kwaliteitsmanagement) met elkaar in
overeenstemming te brengen. In veel gevallen
doet men dat door typische agile-practices op
te schalen en van toepassing te verklaren op
processen buiten de softwareontwikkeling.
Die andere processen worden ‘verscrumd’.
SAFe is hier het meest populaire voorbeeld
van. Zij is een compleet nieuwe methode die
hiervoor is ingericht. De toepassing van
dergelijke methodes is zeer ingrijpend. Allerlei
functionarissen moeten zich volgens SAFe een
werkwijze aanmeten die meestal tegenstrijdig
is met hun ‘oude’ werkwijze.
Onontkoombaar
Bij het introduceren van agile-werkwijzen
vergeet men vaak dat softwareontwikkeling
niet de enige discipline is waar een omwenteling van traditioneel werken naar nieuwe
oplossingen speelt. De verstarring en
bureaucratisering die agile software development probeert tegen te gaan, komt ook voor
bij veel andere disciplines. In vrijwel alle
disciplines wordt allang nagedacht over
manieren van werken die meer flexibiliteit
Parallelle ontwikkelingen
Voorbeelden van ontwikkelingen die sterke parallellen vertonen met agile software development, zijn:
• Lean
Lean is bedoeld om productieprocessen te optimaliseren, om alles wat geen waarde toevoegt aan
het eindproduct (waste) te minimaliseren. Hoewel de ontwikkeling van software niet helemaal te
vergelijken is met een productieproces, zijn de waarden achter Lean vergelijkbaar met die van agile,
zoals het volledig doorlopen van het proces in korte tijd, empowerment van medewerkers en het
continu verbeteren. Het is dan ook voor de hand liggend dat er een aangepaste variant van Lean is
ontwikkeld die specifiek voor softwareontwikkeling is bedoeld: Lean software development.
• Sociotechniek
Sociotechniek bestaat al vele decennia. Het is een bedrijfskundige aanpak die in veel opzichten
haaks staat op de traditionele, analytische, tayloriaanse aanpak. Ook voor sociotechniek geldt dat de
achterliggende waarden zeer vergelijkbaar zijn met die van agile.
• Beyond budgeting
Beyond budgeting bezit waarden die sterk overeenkomen met agile-waarden. Zo zijn budgetten niet
meer gefixeerd en in handen van bestuurders, maar zijn de teams eigenaar. En controle vindt plaats
door aan elkaar verantwoording af te leggen. Ook de traditionele jaarcyclus bestaat niet meer in Beyond budgeting. Beyond budgeting gaat bureaucratisering en verstarring tegen, zoals agile-methoden
onnodige bureaucratie, controlemechanismen en verstarring in softwareontwikkeling willen tegengaan.
‘Inkoop’ kan
helemaal niet
overweg met
agile-partijen
bieden, die medewerkers meer betrokken
krijgen bij het werk, die meer gericht zijn op
vakmanschap en kwaliteit. Wanneer dergelijke methoden (zie kader) naast agile-methoden worden gelegd, dan is te zien dat men
vergelijkbare kwaliteiten beoogt, dat men
ongeveer dezelfde waarden aanhangt, maar
dat de uiteindelijke methodes verschillen.
Dat is ook te verwachten – het gaat over
andere vakken, andere disciplines. Je zou
echter kunnen stellen dat er een ‘pact’ van
ontwikkelingen is die dezelfde waarden
kennen, dezelfde richting opgaan, dezelfde
toekomst voor ogen hebben.
Agile software development is geen ‘feestje
van de programmeurs’, geen geïsoleerde
ontwikkeling waar de rest van de organisatie
zich niet mee hoeft te bemoeien. Wie de
waarde van het agile-gedachtegoed wil
oogsten, zal wezenlijke aanpassingen moeten
doorvoeren in de processen rondom softwareontwikkeling. Die aanpassingen passen echter
in ontwikkelingen die toch al spelen in die
disciplines. Het loont de moeite om de
mogelijkheden van die ontwikkelingen voor
de eigen organisatie te onderzoeken. Op die
manier kan de inrichting van een agile(ontwikkel)-organisatie passen binnen een
groter kader en kunnen conflicterende
werkwijzen worden vermeden. Agile moet
gezien worden als een onderdeel van
een veel grotere beweging en die
beweging is onontkoombaar.
Voor reacties
en nieuwe
bijdragen van
IT-experts:
Henk Ester,
070 3046812
h.ester@
automatiseringgids.nl
»
Anko Tijman
([email protected])
is Agile & DevOps-coach
bij Ordina.
Olaf Agterbosch
([email protected])
is managing consultant,
product- en fieldmanager
bij ViQiT.
Daan Kalmeijer
(daan.kalmeijer@
inspearit.com) is expert
consultant en docent bij
inspearit.
21

Download Report