In mijn werk als management coach en adviseur op het gebied van agile werkwijzen kom ik bij vele bedrijven en IT afdelingen. Door mijn uitgebreide ervaring bij grootschalige implementaties van agile werkwijzen zie ik een interessant patroon in het behalen van het daadwerkelijke rendement.
Soorten bedrijven waar ik deze ervaring uit haal zijn:
- Uitgeverijen
- Telecommunicatie bedrijven
- Overheidsinstellingen
- Banken
- Verzekeraars
- Technische productleveranciers
Gouden bergen
Vaak worden gouden bergen beloofd in termen van rendement van agile werkwijzen. Betere kwaliteit, snellere 'time-to-market', minder kosten. Het rendement is echter afhankelijk van een aantal aandachtsgebieden en de mate waarin binnen die aandachtsgebieden invulling wordt gegeven aan het agile gedachtegoed:
- Cultuur
- Architectuur
- Structuur
- Veranderbereidheid
- Kwaliteit van implementatie
- Leiderschap
In deze serie van 5 blogs ga ik met name in op de ontwikkelingsfasen waarmee het aandachtsgebied (organisatie)structuur zich aan kan passen aan een agile werkwijze, en de voor- en nadelen die dat met zich meebrengt. Deze ontwikkelingsfasen zijn:
- Iteratief werken binnen projecten in de matrix
- Virtuele product teams over functie afdelingen heen
- Fysieke product teams, al dan niet virtueel aangevuld met operations
- DevOps binnen IT
- Bedrijfsbrede product of domein teams
Scrum aanpak tot op heden vaak geïnitieerd vanuit de IT
Agile gaat niet meer weg. Met de exponentieel snel veranderende economie wordt de vraag naar een snellere 'time-to-market' steeds groter. De traditionele ontwikkelmethodieken voorzien niet in een adequate anticipatie op deze snelle ontwikkelingen.
Ik zie dat in de afgelopen jaren vele Agile / Scrum initiatieven 'bottom-up', dan wel 'top-down' zijn gestart in de IT-afdeling om uiteenlopende redenen. Of een team stelde het zelf voor, of management bepaalde het omdat ze bijvoorbeeld een target hadden gekregen om kosten te besparen.
De matrix organisaties domineren in IT land. IT organisaties zijn vaak functioneel opgedeeld, en we zien vaak dat Development en Operations afdelingen zijn gescheiden, en aan elkaar gespiegeld.
Ontwikkelingsfase 1: iteratief werken binnen projecten in de matrix
Projecten binnen Development afdelingen worden telkens opnieuw bemenst vanuit de diverse afdelingen. Hierdoor wordt Scrum in het begin ook het meest toegepast in een project georiënteerde setting.
Dit kan al voordeel brengen, maar niet het voordeel dat men zich vaak zou wensen. Bij Agile / Scrum hebben we het over Product Owners en een Product Backlog. Dit zijn Business Product georiënteerde assets die vragen om een Business Product georiënteerde IT-organisatie (aangenomen dat de klantorganisatie al redelijk Business Product georiënteerd is). Als dat het geval is, of als men daaraan werkt, zie je het rendement van een agile werkwijze gelijk stijgen. Daar komt nog bij dat een agile werkwijze op gespannen voet staat met de vaste scope die in projectplannen vaak met bloed ondertekend wordt afgesproken.
Voor en nadelen
Voordelen
- Iteratief en risico gedreven werken levert voordeel in kosten en doorlooptijd, (zij het beperkt)
- Werken met een backlog met requirements geeft betere acceptatiegraad
- Vroegtijdig en frequent testen en demonstreren brengt betere kwaliteit software en draagt ook bij aan lagere kosten, kortere doorlooptijd, en hogere acceptatiegraad (alternatief: hogere klanttevredenheid)
- Transparantie door werken met een Product Owner als vertegenwoordiger van de business en een product Backlog als discussiestuk over scoping van projecten levert tevens betere acceptatiegraad
Nadelen
- Management heeft neiging agile als de zoveelste ontwikkelmethodiek te zien, terwijl het verder strekt dan dat
- Vaak werkt een team aan meerdere projecten tegelijk, heeft daardoor minder focus en veel verlies aan (omschakel)tijd
- Werken met vaste scope en klassiek governance model geeft spanning en druist in tegen agile principes als werken met transparante onzekerheid in plaats van schijnzekerheid, vaste doorlooptijd, vaste kosten en variabele scope
- Wisselende bemensing van teams verhindert teams om domeinkennis op te bouwen
- Wisselende bemensing van teams verhindert teams om met domeinkennis een referentiekader op te bouwen waardoor zij voorspelbaar kunnen worden in termen van velocity (productiviteit uitgedrukt in story points per sprint / product release)
- Klassieke manier van plannen en begroten wordt gehandhaafd en kost veel overhead die gereduceerd zou kunnen worden als een team op een agile manier voorspelbaar kan zijn
- Aandacht van klantvertegenwoordigers moet vaak naar meerdere projecten tegelijk
- Gebrek aan voorspelbaarheid en productiviteitsverbetering door drie voorgaande punten nopen management vaak tot afblazen van een agile initiatief ("zie je wel, dit werkt ook niet!")
Uitleg over oorzaken waardoor agile teams in zo een eerste fase niet voorspelbaar worden en geen productiviteitsverbetering laten zien vind je in mijn videoblog over de voorspelbaarheid van Scrum teams.
Vele organisaties waar ik kom zitten in deze ontwikkelingsfase in hun agile maturity. Het kan een keuze zijn van management om niet verder te gaan dan fase 1 met hun agile ambitie. Zij dienen zich dan wel te realiseren dat het rendement slechts suboptimaal zal zijn, net zoals deze invulling van agile werken is.
Qua rendementspercentage indicatie krijgt deze ontwikkelingsfase een 10%.
In deel 2 van deze serie ga ik het hebben over ontwikkelingsfase 2: Het werken in virtuele product teams.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.