Inleiding
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 heb ik een patroon ontdekt waarmee de mate van rendement van die implementaties verklaard kan worden.
Soorten bedrijven waar ik deze ervaring uit haal zijn:
- Uitgeverijen
- Telco’s
- Overheidsinstellingen
- Bank instellingen
- Verzekeraars
- Technische product leveranciers
Vaak worden gouden bergen beloofd in termen van rendement van agile werkwijzen. Betere kwaliteit, snellere time to market, minder kosten. De mate van dit rendement is afhankelijk van de kwaliteit van de implementatie, en van de mate waarin de organisatie wil mee evolueren naar een gehele agile organisatie.
Het patroon met stappen dat ik bij organisaties observeer waar ik kom is als volgt, en het zegt iets over de mate van Agile maturity van die organisatie:
- Iteratief werken binnen projecten in de matrix
- Virtuele product teams over functie afdelingen heen
- Fysieke product teams, al dan niet virtueel aangevuld met Ops
- DevOps binnen IT
- Bedrijfsbrede product of domein teams
In een serie van 5 blogs zal ik de voor en nadelen van deze stappen toelichten.
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.
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.
IT meestal georganiseerd in een matrix projecten organisatie
Ik kom in Nederland het meeste de matrix georganiseerde IT afdelingen tegen. Organisaties zijn vaak functioneel opgedeeld, en we zien vaak dat Development en Operations afdelingen zijn gescheiden, en aan elkaar gespiegeld.
Stap 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 van stap 1:
Voordelen:
- Iteratief en risico gedreven werken levert voordeel in kosten en doorlooptijd, doch 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 minder kosten, doorlooptijd, en betere acceptatiegraad
- 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 ontwikkel methodiek te zien, terwijl het verder strekt dan dat
- Vaak werkt een team aan meerdere projecten tegelijk, daardoor slechte focus en veel verlies aan tijd
- Werken met vaste scope en klassiek governance model geeft spanning en druist in tegen agile principes
- Wisselende bemensing van teams verhinderd teams om domeinkennis op te bouwen
- Wisselende bemensing van teams verhinderd teams om met domeinkennis een referentie kader op te bouwen waardoor zij voorspelbaar kunnen worden in termen van velocity en story points per sprint / product release
- Klassieke manier van plannen en begroten wordt gehandhaafd, doch 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 productiviteits- verbetering door bullets 4, 5 en 6 nopen management vaak tot afblazen van een agile initiatief
Vele organisaties waar ik kom zitten in deze fase of stap in hun agile maturity. Het kan een keuze zijn van management om niet verder te gaan dan stap 1 met hun agile ambitie. Zij dienen zich dan wel te realiseren dat het rendement slechts sub optimaal zal zijn, net zoals deze invulling van agile werken is.
Qua rendements percentage krijgt deze stap een 10%.
In deel 2 van deze serie ga ik het hebben over stap 2: Het werken in virtuele product teams.
