We horen allemaal al te weten dat het toepassen van Agile principes en Scrum als empirisch framework voor IT trajecten of projecten al diverse paradigma verschuivingen 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 paradigma verschuivingen dat hierbij komt kijken is nog eens vele malen groter.
In deze blog geef ik een (niet uitputtend) overzicht van paradigma verschuivingen die een organisatie doormoet bij het opschalen van agile werken. Ik geef er geen uitleg bij, maar de bedoeling is om medewerkers en management van organisaties die bezig zijn met, of willen beginnen met, het opschalen van agile werken, te triggeren, en bewust te maken van de uitdagingen waar zij voor staan.
| Voor toepassen Scrum in tijdelijke project teams in een projecten matrix organisatie (Klassiek besturingsparadigma) | |
| 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 |
| Voor verlaten van projecten matrix organisatie (Agile besturingsparadigma) | |
| 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 T 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 |
| Voor het opschalen en structureren naar waardestromen | |
| Van | Naar |
| ‘Component’ teams | ‘Feature’ teams |
| Functionele organisatie structuren | Organisatiestructuren analoog waardestromen |
| ‘Up to date’ houden vakkennis binnen je afdeling | ‘Up to date’ houden domein kennis 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 multi disciplinaire teams die werk verrichten |
| Gecentraliseerde IT resources | Gedecentraliseerde IT resources |
| Voor 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’ |
| Waterval mijlpalen | 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 |
| 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 ex collega Daan Kalmeijer: https://www.youtube.com/watch?v=TJAugy1Tbeo .
Ik hoop dat de lijst stof tot discussie geeft, en als er vragen zijn dan ben ik vanzelfsprekend te bereiken.
