Development

Software-ontwikkeling

Veel teams werken op de handrem

9 januari 2015

De 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 beleggen bij multidisciplinaire teams, zie je dat de traditionele werkwijzen verantwoordelijkheden vangen in processen, hiërarchieën en 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 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 agile leverancier 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 agilemethoden 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 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.

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 aanpasbaar 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? Alle drie? 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?

Parallelle ontwikkelingen

Voorbeelden van ontwikkelingen die sterke parallellen vertonen met agile software development, zijn:

  • 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 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 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.

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.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!