Agile: voor onzekerheid
Een product ontwikkel je voor de opbrengsten ervan - meetbare al dan niet financiële opbrengsten. Afgezet tegen een kosten-kant.
Hoe los je de onzekerheden rondom het ontwikkelen van producten op?
Het antwoord is een no-brainer! er zijn vier perspecireven die agile werken de ultieme oplossing voor projecten maken.
- het business perspectief
- het project perspectief
- het team perspectief
- het klant perspectief
Agile is een no-brainer 1
Het business perspectief
Kort-cyclisch producten ontwikkelen: betere Real Options, betere Cashflow, hogere Net Present Value.
Het economsich argument voor agile werken is eenvoudig: meer Real Options, betere Cashflow, hogere Net Present Value.
Door kort-cyclisch te werken creeer je mogelijkheden tot versnellen of vertragen gedurende de ontwikkelingsperiode; kleine overzichtelijke investeringen in plaats van een grote lang vastzittende mega-injectie.
En de opbrengsten manifesteren zich eerder in de tijd! betere Cashflow, betere Net Present Value!
Agile is een no-brainer 2
Het project perspectief
Waterval-projecten met grote batches en lange wachttijden. Onzekerheden stapelen zich op , feedback loops zijn traag en wachttijden voor individuele modules GROOT.
Waterval-projecten werken in grote batches - alle requirements uitschrijven, alle ontwerpen maken, alles produceren en alles testen tegen die requirements.
Individuele functionele modules wachten - en wachten - en wachten......ontwerpbeslissingen worden heeeeeeeel laat getoetst en eventueel bijgesteld. Integratie is rampzalig.
Grote batches leiden tot lange wachttijden
En late feedback
Een individuele module. Toetsbaar in de praktijk tegen de Job to be Done.
Een goed project toets een enkel functioneel element (met daarin zijn onzekerheden) zo snel mogelijk tegen de Job to be Done.
Zodat foutieve keuzes zo snel mogelijk gestopt en succsvolle gokjes uitgebuit kunnen worden.
Zodat kenniswerker snel feedback krijjgen vanuit de werkelijkheid van eindklant-benefits.
Agile is een no-brainer 3
Het team-perspectief
De klassiek vraag: maakt 1 team een complete module (of product) of maken specialisten ieder achter elkaar en gescheiden delen van modules en producten?
Hoe meer onzekerheid en variantie er is in 'Expressed Expectations', het ontwerp en de bouw van oplossingen en de fluïditeit van de implementatie (versie-updates van werkende software versus het verplaatsen van een flatgebouw over 1 meter), hoe korter je de verschillende disciplines bij elkaar wilt hebben.
Je zoekt: 1 team van multi-functionele T-shaped specialisten, die elkaar kunnen opvangen.
De klassieke organisatie
Lokaal geoptimaliseerde machinebureaucratie
Lokale optimalisatie leidt tot systemische suboptimalisatie. Variantie in aanbod en proces leidt tot opslingerende wachttijden.
De klassiek Tayloristische machinebureacratie:
- verticale functiescheiding,
- taakoptimalisatie door experts,
- scheiding tussen management en uitvoering,
- financiele eilandjes,
- lokale optimalisatie.
- maximale standaardisatie
- minimale variantie
Want zo deden we het in 1900 bij de massafabrikage van zwarte T-Fords.
Batchgewijze productie met complete scheiding van functies
lokale optimalisatie vraagt om grote batches en bijna 100% bezetting. Hetgeen gegarandeerd tot maximale wachtttijden voor enkelvoudige items leidt - 1:100 ratio's zijn niet ongewoon.
Geoptimaliseerde gescheiden silo's leiden tot grote batches en over de schutting-werpen.
Onvermijdelijk, want de handjes moeten blijven bewegen en dat kan alleen met voldoende werkvoorraad. Ieder individueel implementeerbaar element van de oplossing voor de Job-to=be-Done verdwijnt in de batch en moet wachten op voorgangers en opvolgers in de batch. gevolg: extreme wachttijden, hoge herstelkosten bij verkeerde ontwerppaden, zeer trage feedback.
Multi-functionele teams leveren enkelvoudige toetsbare functionele modules
In kleine batches en korte tijdperiodes
Analysten, ontwerpers, bouwers, testers bij elkaar om enkelvoudige delen van de oplossing voor Jobs to be done Life af te leveren.
Agile is een no-brainer 4
Het klant perspectief
Klanten hebben een Job to be Done. Bouwers bouwen oplossingen voor die Jobs. (ontwerpers bedenken, testers testen ze enzovoorts).
De klant heeft geen belang bij wie wat precies doet bij het maken van de oplossing voo rde JObs. De klant wil de beste oplossing zo snel mogelijk. Ook als hij niet eens alle details van de Job to be Done al helder heeft...
Close the Gap!
Close the gap - de eigenaren van Job-to-be-Done, de bowers van de opposing, testers, ontwerpers.....verwijder de muren tussen hen!