Paradigmaverschuivingen bij Scaling Agile
We horen allemaal al te weten dat het toepassen van Agile principes en Scrum als empirisch framework voor IT-trajecten of -projecten al diverse paradigmaverschuivingen met zich meebrengt. Toch valt het me altijd weer tegen wat daar in de praktijk van terecht komt. Het blijven denken in de bestaande werkwijzen en manier van besturen blijft een hardnekkig iets.Nu is het bedrijfsbreed opschalen van agile werken een (voor mij blijvende) trend. Maar het aantal paradigmaverschuivingen dat hierbij komt kijken is nog eens vele malen groter.
In deze blog geef ik een (niet uitputtend) overzicht van paradigmaverschuivingen die een organisatie door moet bij het opschalen van agile werken. Ik geef er geen uitleg bij, maar de bedoeling is om medewerkers en management van organisaties te triggeren die bezig zijn met (of willen beginnen met) het opschalen van agile werken. En hen bewust te maken van de uitdagingen waar zij voor staan.
Klassiek besturingsparadigma
Voor het toepassen van Scrum in tijdelijke projectteams in een projectenmatrix-organisatie.
Van | Naar |
Vaste scope | Vaste kosten en vaste doorlooptijden (Vergt tolerantie in scope en MOSCOW) |
Denken in oplossingen | Denken in eisen |
'Big Design Upfront' (BDUF) | 'Just in time design' |
Creëren van 'dode' papieren werkvoorraad | 'Just in time' detailleren van eisen en produceren werkende software |
Push planning | Pull van eisen van backlog |
Inhoudelijke en procesaansturing door Project Manager | Inhoudelijke aansturing door Product Owner Procesaansturing door Scrum Master |
Agile besturingsparadigma
Voor het verlaten van een projectenmatrix-organisatie.
Van | Naar |
Tijdelijke project teams | Vaste product teams |
Gebrek aan eigenaarschap van producten | 'Shared code ownership' door vaste teams |
Gescheiden innovatie en applicatie onderhoud voor de boekhouders (Capex vs Opex) | Innovatie en applicatie onderhoud door 1 vast team voor domeinkennis, kwaliteit en voorspelbaarheid |
(Tijdelijke) teams naar het werk brengen | Het werk naar (vaste) teams brengen |
Starten en stoppen van projecten | Continue flow van eisen gerealiseerd in releases |
'Exception Reports' bij uitloop project | Bewuste keuzen business door prioriteren eisen voor beschikbare vaste capaciteit |
Creëren van technische schuld | Iteratief terugdringen technische schuld |
Schijnzekerheid over planning | Transparante onzekerheid over planning |
Absolute inspannende begroting vooraf | Relatieve eenvoudige begroting vooraf |
Volledig uitnutten van team capaciteit voor realisatie scope | Structureel bieden van ruimte aan teams voor continue procesverbetering, innovatie en terugdringen technische schuld |
Stilstand (40 jaar oude werkwijze handhaven) is achteruitgang (Lagere productiviteit op lange termijn) | Veranderen (zie alle paradigma verschuivingen) is vooruitgang (hogere productiviteit op lange termijn) |
Denken in specialisten met slechts 1 expertise | Denken in specialisten met een IT-profiel |
Gebrek aan autonomie in tijdelijke teams | Opbouw van autonomie in zelf organiserende vaste teams met shared code ownership |
Tijdelijke Stuurgroepen | Vast Product Management met mandaat voor prioriteren flow van eisen |
Ongestructureerde Ad Hoc overlegvormen | Gestructureerde ritmische werkvormen |
Waardestromen
Voor het opschalen en structureren naar waardestromen
Van | Naar |
'Component' teams | 'Feature' teams |
Functionele organisatiestructuren | Organisatiestructuren analoog aan waardestromen |
'Up to date' houden vakkennis binnen je afdeling | 'Up to date' houden domeinkennis binnen je afdeling |
'Up to date' houden van vakkennis binnen je afdeling | 'Up to date' houden vakkennis binnen communities (vakgroepen) |
Denken in individuen (1 discipline tegelijk) die werk verrichten | Denken in multidisciplinaire teams die werk verrichten |
Gecentraliseerde IT-resources | Gedecentraliseerde IT-resources |
Portfolio
Voor het corporate portfolio
Van | Naar |
Gecentraliseerde controle | Gedecentraliseerde besluitvorming |
Gedetailleerde projectplannen | Lichtgewicht Business Cases per Epic |
Gecentraliseerde jaarlijkse planning | Gedecentraliseerde 'rolling wave' planning |
'Work breakdown structure' | Agile begroten en plannen |
'Project Cost accounting' (Dubbele projecten boekhouding) | 'Lean budgetting' van domeinen met release treinen (Enkelvoudige boekhouding gebaseerd op salariskosten en kostenplaatsen) |
Plannen op basis van begrootte mandagen (schijnzekerheid) | Voorspelling op basis van een nieuwe voorspelbaarheid met velocity en 'roadmapping' |
Watervalmijlpalen | Continue levering van werkende producten |
Financiële KPI's die niets zeggen over geleverde business waarde | KPI's die daadwerkelijke sturing op de IT én Product life cycle bieden in categorieën business waarde, klanttevredenheid, kwaliteit, productiviteit, kwantiteit, medewerker tevredenheid en agile volwassenheid. |
Sturen op afronding en decharge van projecten | Sturen op geleverde Business waarde en productiviteit (en bovenstaande KPI's) |
Onsamenhangend projecten portfolio | Heldere structuur in business domeinen met release treinen |
Leveranciers
Voor het werken met leveranciers
Van | Naar |
'Fixed price' opdrachten | Inhuur op 'Time and material' |
Elimineren financieel risico door management bij gebrek aan kennis (IT) productie proces | Bewustwording en kennisname van eigen (IT) productieproces (Gemba walk) door management, en sturen op dit productieproces |
Contracten met afspraken over scope | 'Agile contracting' met afspraken over samenwerking, partnering, kort cyclisch leveren van businesswaarde, continue procesverbetering, productiviteitsverbetering, kwaliteitsverbetering, innovatie en terugdringen technische schuld. |
Inkoop op basis van functiepunten | Inkoop van vakkennis |
'Out of Pocket' kosten toegewezen aan een project | 'Out of Pocket' kosten toegewezen aan een afdeling, kostenplaats |
Nogmaals, de lijst is niet uitputtend, en de 'shifts' staan binnen een categorie ook in willekeurige volgorde. Ik ben iemand die graag zaken scherp formuleert, en chargeert. Dit omdat ik in de praktijk merk dat vele genoemde noodzakelijke veranderingen gewoon niet worden erkend, gezien, doorgevoerd, of zelfs hardnekkig worden tegengehouden, door een decennialang inslijten en opstapelen van gewoontes en denkwijzen. In deze context verwijs ik graag naar een filmpje van oud-collega Daan Kalmeijer:
Ik hoop dat de lijst stof tot discussie geeft, en als er vragen zijn dan ben ik vanzelfsprekend te bereiken.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile of lees hier meer Agile gerelateerde blogs.