Bert Overbeek is trainer, coach en interim manager, maar tegenwoordig kan je ook zeggen: organisatiedokter en -innovator. Opgeleid door NS en Schouten en Nelissen, besloot Jongebazen-oprichter Bert Overbeek na 25 jaar loondienst om voor zichzelf te gaan werken. Hij wilde zijn klanten meer op maat bedienen, de basis van zijn werk verdiepen en de kwaliteit van zijn werk vergroten en had het gevoel dat hij daarvoor onafhankelijk moest kunnen opereren. Hij is er gelukkig van geworden. (Website met filmpje: www.pitchersupport.jimdo.com)
Prof. dr. Mastenbroek van Managementsite ‘ontdekte’ dat Overbeek meer kon dan bedrijven helpen met verbeteringen van resultaat en sfeer. Hij vroeg de schrijvende organisatieontwikkelaar of hij een weblog voor jonge managers wilde bijhouden, als partnerlink van het grote ManagementSite. Dat was tien jaar geleden. Sindsdien schreef Overbeek bijna 1500 artikelen en zes boeken. Ze werden uitgegeven door Haystack en door Futuro Uitgevers. Twee boeken werden bestsellers en eindigden in de top 10 (‘Het Flitsbrein’ en ‘Mannen en/of vrouwen’).
Overbeek vindt kosteloze kennisdeling en informatie-uitwisseling zo belangrijk, dat hij hier op jongebazen.nl nu 10 jaar de finesses van het managementvak deelt met vakbroeders en collega’s. Daarmee liep hij voor op de moderne social media trends waarin het ‘geven’ van gratis informatie een marketing tool is geworden.
Meer dan 100 000 mensen bezoeken Jongebazen per jaar. En het heeft hem veel respect opgeleverd in managementland. Alles wat te maken heeft met het verbeteren van organisaties, teams en mensen boeit hem. 21 jaar ervaring en intensieve studies helpen hem daarbij. Zijn humor leidt er toe dat mensen hem graag inhuren als spreker en inspirator, en zijn veelzijdigheid heeft hem het compliment van een topvrouw opgeleverd, dat hij altijd een eigen gezichtspunt kiest en je daardoor aan het denken zet.
Organisaties weten de weg naar hem te vinden. Hij zei daarover in een interview: ‘Het is niet altijd makkelijk om mijn werk te combineren met jongebazen, omdat je op zo’n blog wel eens inzichten los wilt maken die strijdig zijn met wat gangbaar is in mijn vak. Wat zegt hij daar nu weer?, denken opdrachtgevers dan. Maar ik kan ze gerust stellen. In mijn werk kan ik me goed op een opdracht richten.’
Bert twittert op Goeroetweets, een titel die is afgeleid van zijn boek ‘Goeroegetwitter’. Het woord ‘goeroe’ is duidelijk met een knipoog. Want hij is wars van goeroeneigingen, en prefereert laagdrempeligheid. Jongebazen heeft een eigen groep op Linkedin.
Correspondentie met Bert Overbeek via pitcher.support@hetnet.nl Zijn website is www.pitchersupport.jimdo.com
Veel interessanter is dat blijkbaar velen van ons geneigd zijn deze open deur te vermijden, ontkennen of zelfs te bestrijden? Enkel omdat er ook zovelen een goede boterham aan verdienen? Of omdat ze de eigen claims oprecht onvoorwaardelijk geloven? Of is het onze behoefte aan zekerheid en risicomijding? Of juist van onze angst iets te missen, dat we ons met liefde laten overtuigen dat deze rimpelcrème echt helpt.
En hoe verhoudt dit zich tot bijvoorbeeld het placebo als ook het Hawnthorne effect? En daar is wel degelijk, heel degelijk onderzoek naar gedaan. De absurd dure pil (consultancy firma) stiekem gevuld met niet werkzame middelen (agile werken, etc.) die door een kundig arts (adviseur) worden voorgeschreven werkt in veel gevallen beter dan het werkelijke medicijn. Wat dat werkelijke medicijn (agile of aromatherapie) dan ook is?
Dat geeft de paradoxale situatie dat alle huidige succesformules, weliswaar niet met zekerheid kunnen claimen werkzaam te zijn, maar het placebo effect toch werkelijk een tastbaar effect geeft? Of zijn al die adviezen en formules wel degelijk werkzaam, is het echter enkel nog niet voldoende degelijk onderzocht en definitief bewezen?
Maar stel dat jij, en op den duur iedereen, het middel hebt dat gegarandeerd tot succes leidt. Het concept succes zou alle betekenis verliezen, aangezien iedereen en dus niemand succesvol zou zijn.
En nog erger, stel je voor dat je bij voorbaat al weet dat je succesvol bent, je de toekomst zogezegd al weet en tot verleden hebt gemaakt. Hoe lang zou het duren voordat je, uit intense verveling, gaat hopen dat er eens iets niet slaagt?
En laat het nu de wetenschap zijn die uit ervaring kan zeggen dat juist de vergissingen, de verkeerde methoden, de ongelukjes en gefaalde praktijkexperimenten vaak het grootste succes en de meest revolutionaire ontdekkingen in zich verborgen dragen. Of daar in ieder geval een cruciale rol in hebben.
Mijn waardering voor je kritische blik op bewegingen in management- en organisatieland. Je eerdere kritiek op de Net Promotor Score vond ik persoonlijk heel waardevol. In dit artikel zitten echter een paar lacunes.
Omdat ik ook graag vanuit de empirie en met bewijsvoering werk, en het filmpje over agile van Scrum Company (waar ik werk) deel is van jouw stuk, doe ik graag een aantal correcties en aanvullingen.
Het is van belang om in het debat over agile, de scherpte te behouden. En wel op de volgende punten:
- Je claimt dat je in agile geen grote doelen ver weg stelt. Wat is daarvoor je bron? Je maakt geen uitgebreide plannen, maar grote doelen voor je project of organisatie(onderdelen) kun je zeker wel hebben wanneer je agile werkt. In Scrum en in modellen als SAFe kun je je grote doelen volop kwijt. En kun je er dus ook op evalueren.
- Je baseert het gebrek aan bewijs voor de winst die agile werken oplevert, op het gebrek aan validiteit van een specifiek rapport. Opvallend is dat beide wetenschappelijke kritieken op dat rapport die je aanhaalt gedateerd zijn (1 gaat over het eerste Standish rapport van 1994 (!), de volgende kritiek is uit 2008 en gaat ook terug tot 1994: tijden dat agile beperkt werd toegepast, daarnaast wordt nergens in de kritieken agile of Scrum genoemd.). Waaruit leid je, zonder verder onderzoek, af dat het Standish rapport van 2015 niet valide is? Het kan niet de quote zijn van Johnson die je aanhaalt, ook die komt uit 2008.
- Gelukkig vinden er meer onderzoeken plaats naar agile werken. Bijvoorbeeld Serrador & Pinto (2015): "Does Agile work? — A quantitative analysis of agile project success." Met als een van de conclusies: "There is a positive relationship between agile use and reported project success." Hier terug te vinden: http://www.sciencedirect.com/science/article/pii/S0263786315000071. Er zijn ook vele kwalitatieve analyses, surveys en scripties online te vinden, geen noodzaak om te cherrypicken. Op verzoek kan ik je een set toesturen.
Laten we dus van agile werken geen stroman maken, die we op basis van aannames over de werkwijze, en de validiteit van een specifiek onderzoek, neerzettten als 'religie'. Dat doet geen recht aan de vele, vele teams die met agile aantoonbaar succesvol zijn.
Groet!
Beste Rik, dank ook voor je comment. Baseer je je op onderzoek, of is dit jouw ervaring? Beiden zijn uiteraard prima, maar het lijkt me altijd netjes te weten wat de bron is van een uitspraak.
tof, dank voor je reactie! Wat betreft het doelen stellen, baseer ik mij op dat filmpje. Daar zegt de voice-over dat er een flexibele strategie is en 'ze maken geen uitgebreide plannen, maar gaan ontdekken wat het beste product kan worden’. Daaruit leid ik af dat Anna's team geen doelen stelt zoals: 'We gaan binnen een tijdbestek van een jaar 150.000 koekjes verkopen en daarbij 5.000 euro winst maken'. Excuses als die aanname niet klopt, en leg me gerust uit hoe ik het dan wel zou moeten interpreteren.
De onderzoeksmethode is, bij mijn weten, nog altijd niet te achterhalen bij Standish. Het klopt dat de onderzoeken die ik gebruik al wat ouder zijn, maar ook de nieuwe versies zijn niet toegankelijk. Heb jij wel hun methodiek weten te achterhalen? Waaruit zouden we mogen afleiden dat de Standish Group hun leven heeft verbeterd? Bij mij zou dat zo zijn als ze openheid van zaken geven.
Dan het onderzoek van Serrador en Pinto. Dat ken ik. Ook hier geldt: lees even goed de gebruikte methodologie. Dit 'onderzoek' is helaas niet meer dan een flinke enquete onder managers.
Er is in dat onderzoek aan managers gevraagd naar resultaten van twee soorten projecten: eentje die succesvol is verlopen en eentje die minder succesvol is verlopen. Over deze twee projecten hebben de onderzoekers dan allerlei vervolgvragen gesteld.
Mijn bezwaren, de meesten ervan erkennen de onderzoekers zelf ook ruiterlijk, tegen deze onderzoeksopzet:
1. Respondenten kiezen zelf twee projecten uit. We weten dus niet welke projecten er niet zijn uitgekozen. De data uit deze projecten hebben de onderzoekers niet kunnen meenemen. Dat geeft een enorme selectie-bias: We lopen groot risico dat we te maken hebben met projecten die bijvoorbeeld toevallig helemaal geweldig of helemaal dramatisch zijn verlopen. Of dat mensen projecten selecteren die hen zelf, om wat voor redenen ook, goed uitkomen.
2. De selectie van respondenten is volstrekt willekeurig. Ze zijn geworven via een LinkedIn-pagina. We weten maar heel weinig over ze, en al helemaal niet over de mensen die niet hebben gereageerd. Aangezien is gewerkt met een oproep via Linkedin, bestaat de kans dat er vooral veel mensen reageren die Agile bij voorbaat geweldig vinden en dus ook een project uitkiezen dat agile is. De kans bestaat dat mensen die niet agile werken (of er zelfs nog nooit van hebben gehoord) en ontzettend succesvol zijn, niet in gelijk mate bij dit onderzoek zijn betrokken. Dat maakt het vergelijk bij voorbaat oneerlijk.
3. De onderzoekers gebruiken een hele grove definitie van Agile werken. Ze doen dat enerzijds door respondenten zelf te laten aangeven hoe agile het project was, en anderzijds door te kijken naar het aantal uren dat in een bepaalde fase is gebruikt. Dat staat m.i. nogal ver af van een eenduidige definitie van agile werken, waarbij de onderzoekers objectief vaststellen of er daadwerkelijk agile is gewerkt.
4. De onderzoekers zijn - overigens heel begrijpelijk - niet in staat de antwoorden van de respondenten te checken. We moeten afgaan op wat ze zelf zeggen. Projectmanagers kunnen er baat bij hebben de agile-projecten in een mooi daglicht te stellen: hun organisaties hebben ongetwijfeld veel geld gespendeerd aan allerlei agile-tools en willen graag zien dat dat geld de investering waard is geweest.
5. De onderzoekers plaatsen zelf ook vraagtekens bij de generaliseerbaarheid van hun resultaten.
Dit onderzoek is uiteraard een enorm verschil met het Standish-report dat ik in mijn artikel bespreek. De onderzoekers zijn open over hun methodiek, en geven zelf ook de zwakheden aan. Dat is uiteraard geweldig nieuws. Toch zou de conclusie naar aanleiding van dit onderzoek volgens mij moeten zijn: 'We weten nu dat als je aan projectmanagers die je werft via LinkedIn vraagt of ze vinden dat Agile werken meer succes geeft, het antwoord ja is'.
De claim die ik in mijn column onderzoek luidt: geeft Agile werken meer succes dan traditioneel projectmanagement? Als je die claim wilt onderzoeken, zul je volgens mij moeten werken met projecten die op alle vlakken (mensen, omstandigheden, budget, etc) gelijk zijn, behalve agile als methode. Met een controlegroep. Dan kun je een eerlijke vergelijking maken en harde conclusies trekken. Dat lijkt mij uiterst moeizaam om uit te voeren. Ik begrijp dat er dan wetenschappers zijn die zeggen: 'beter een enquete dan het antwoord dat we het niet weten'. Dat mag uiteraard, maar hopelijk mag ik die conclusies dan wel in twijfel trekken en stellen dat op basis van de huidige stand van wetenschap, we het antwoord op de vraag of agile meer succes geeft, niet weten.
Uiteraard ben ik erg benieuwd naar je set met onderzoeken, maar hoop wel dat je hierbij dan voor de lezers van Managementsite vermeld wat de gebruikte onderzoeksmethode is.
Wat mij betreft blijft de conclusie dus dat het helemaal geen punt is als je 'fan' wilt zijn van agile werken, maar de stelling dat er bewijs is voor het succes van agile werken, is wat mij betreft erg voorbarig en doet ook geen recht aan de vele, vele teams die met traditioneel projectmanagement aantoonbaar succesvol zijn.
Fijne dag!
Maar iets meer naar details kijkende, ben ik een groot tegenstander van het Agile dat momenteel wordt gepromoot door de IT-sector. Een grote reden is dat tijd en geld worden gefixeerd. Dat duidt op de Tayloriaanse denkwijze waar slechts op tijd en geld wordt gestuurd en waar alle andere variabelen zoals kwaliteit van veel minder belang zijn (zie: http://www.viergever.info/home-nl/blog/2016/april/waarom-falen-zoveel-projecten/). Dat wordt mij ook met regelmaat bevestigd door personen die aan de gebruikerskant zitten. Hun beleving van Agile door de IT-sector komt er meestal op neer dat er veel sneller en meer frequent wordt geleverd maar dat het veel langer duurt voor er eindelijk iets bruikbaars wordt geleverd. De Tayloriaanse denkwijze heeft als kenmerk dat flexibiliteit tot een minimum wordt beperkt. Het zogenaamde Agile is hierop gebaseerd en is dus verre van agile. Het is een “quick and dirty” aanpak.
Een ander vaak voorkomend probleem van de Agile aanpak is het gebrek aan integrale visie. Tijdens verhoren van de commissie Elias werd gesuggereerd dat de overheid geen grote projecten meer moest aanpakken maar slechts kleine overzichtelijke projecten moest uitvoeren. Dat klinkt logisch maar er is een grote tegenwerping. Wat is het meest gevaarlijke niet-nucleaire wapen waarover de VS beschikt? De clusterbom bestaat uit vele kleine bommen die los van elkaar zeer grote en langdurige schade aanrichten. Zo is het ook met vele kleine projecten zonder samenhang, zoals waarop met de Agile voor de hand ligt. Een echte projectaanpak met samenhang is daarom te prefereren.
Zelf zie ik het meeste in de basis van de PRINCE2 aanpak maar dan wel de echte aanpak voordat de IT-sector er een farce van maakte. Het grote verschil tussen deze aanpak en verreweg de meeste manieren om naar projecten te kijken, is dat PRINCE2 zich richt op de effecten die het resultaat moeten zijn van projecten terwijl andere aanpakken, inclusief Agile en SCRUM, alleen naar oplevering kijken. Dit laatste heeft als risico: Operatie succesvol, patiënt overleden. Kijk dus naar de lange termijn (Business Case) en reken daar op af; niet op de korte termijn oplevering van het project. Maar dat betekent wel dat een project niet langer door een (interne) leverancier maar door de klant gestuurd moet worden (dit is het gedeelte van PRINCE2 dat de IT-sector het liefst wegmoffelt want niet in hun belang). Maar goed opdrachtgeverschap blijkt nog altijd een enorm probleem en dat wordt door de Agile denkwijze helaas een nog groter probleem.
Als we niet incrementeel willen veranderen, maar een systeem structureel willen veranderen, dan hebben we andere benaderingen nodig. We weten immers dat het anders moet, maar niet of nog niet hoe. Dan werkt het maakbaarheidsidee van traditioneel verandermanagement niet. Dan is doen en meten en opvolgen veel meer eenzelfde act en een continue gebeuren. Er zit dus iets fundamenteels onvoorspelbaar in dergelijke transities.
By the way, traditioneel veranderbeheerd en projectmanagement kent dit ook wel. Denk bv. aan change requests of vragen die rijzen maar niet voorzien zijn in het plan. Uiteindelijk sturen dergelijke vragen het project in andere richtingen, soms zelfs zodanig dat op het einde van de rit er iets anders uit de bus is gekomen.
Maar ja, hoe verkoop je een dienst/product als je niet (wetenschappelijk) hard kan maken dat het effect heeft, of liever, hard kan maken dat het een beter effect heeft dan een concurrerend product of dienst? Dan roep je de hulp van marketeers in! Die hebben daarvoor bijzonder creatieve oplossingen, denk aan de 'wetenschappelijke claims' in de reclamewereld.
We weten dat het veel gebakken lucht is, maar mensen hebben een oerdrift die deze rationele kennis overstijgt: reductie van onzekerheid (overlevingsdrang). We willen graag een 'garantie' dat iets positief werkt. En we willen houvast (een methodiek) om ons handelen structuur te geven en daarmee 'fouten' en onzekerheden vermijden.
Het ontstaan van steeds weer nieuwe methodieken (vaak met een hoog 'oude wijn' gehalte) is dan een logische consequentie. Al sinds er ICT bestaat (ter illustratie), wordt er geklaagd over 'falende projecten'. Dus als er dan een nieuwe werkwijze wordt geboden, die claimt dat het 'vanaf nu' beter gaat, dan is de overstap snel gemaakt. Een oneindig proces, juist omdat het decor van ICT projecten meestal een uitermate complexe werkelijkheid is. Die kun je enigszins beheersen door de processen van A naar B te stroomlijnen (met een methodiek). Uiteindelijk hangt het succes van de methodieken af van de mensen(!) die ze gebruiken. Een positieve 'just do it' houding van alle stakeholders kan niet vervangen worden door welke methodiek dan ook. Het begint altijd met het verandervermogen en de veranderbereidheid, een PM-methodiek kan binnen die context het leven veraangenamen.
Kortom: luister vooral ook naar je onderbuikgevoel en vertrouw op je gezonde verstand. En toets geregeld of alle neuzen nog dezelfde kant uit staan. Teambuilding heet dat. Wetenschappelijk wel goed onderzocht en bewezen effectief!
Ook echte aanpakken voor projectmanagement praten over plannen, herplannen en omgaan met grotere onzekerheden. Kijk bijvoorbeeld hier eens naar (engelstalig): http://www.viergever.info/home-en/whitepapers/2015/december/prince2-waterfall/
Mis, zoals wel vaker, onderbouwing van de bredere implicaties van je uitspraak.
Jammer ook dat je niet op zoek bent gegaan naar degelijker onderzoek dat de claim kracht bijzet of juist ontkracht. Anderzijds, heb ik je wel vaker zien schrijven dat je ander onderzoek gezocht maar niet gevonden hebt, maar daar geen reproduceerbaar verslag van zien doen.
Click-bait.
Wel effectief. Ik tuinde er ook in. :)
In vind het een vreemde vraag…. Naar mijn mening is succes nooit afhankelijk van een gekozen methode, model of (organisatie)structuur, maar van de mensen die het laten werken.
Je kunt inderdaad geen objectief vergelijkbare projectsituaties creëren waarin alles (mensen, omstandigheden, budget, etc.) hetzelfde is, behalve de gekozen methode. Maar dat moet je ook niet willen. Juist de omstandigheden en de mensen zijn belangrijke bepalende factoren bij het maken van de keuze voor een methode. Afhankelijk van de omstandigheden kan op een bepaald moment de ene keuze namelijk wel logischer zijn dan de andere.
De onvoorspelbaarheid van deze tijd en behoefte aan feedback van klanten of andere belangrijke betrokkenen zijn twee van de redenen waarom vandaag de dag vaak gekozen wordt voor Agile.
Dat kan heel valide zijn, maar kies niet voor Agile, omdat iedereen het doet.
Houd anderzijds ook niet vast aan traditionele methoden, omdat je het altijd al zo gedaan hebt.
Beoordeel de situatie, neem alle relevante factoren mee in de afweging en maak dan een keuze voor de best passende methode. Sluit op voorhand niet uit dat je voor verschillende projecten, andere keuzes maakt.
Als je de beschikking hebt over hele goede traditionele projectmanagers, en ontwikkelaars die nog niet rijp zijn om zelforganiserende teams te vormen, maar liever traditioneel aangestuurd worden, zou ik niet zomaar overgaan naar Agile.
Niet elke goede projectmanager is namelijk ook een goede Scrum Master of Product Owner. Al wordt hier in de praktijk, bij het verdelen van de rollen, nog steeds soms vanuit gegaan.
Laatst hoorde ik van een hele afdeling HR consultants die allemaal de opleiding Scrum Master met goed gevolg hadden afgerond. Daar verbaas ik me echt over. Ik acht de kans heel klein dat het allemaal goede Scrum Masters worden of zijn. Een rol moet passen bij je talenten. Voor een Scrum Master moet er iets van een dienend leider in ‘je genen’ zitten. En de kans dat dat voor allemaal geldt, lijkt mij heel klein. Dat betekent dat deze mensen het risico lopen ‘op kracht’ deze rol te gaan vervullen. Terwijl we met talentmanagement juist proberen medewerkers ‘in hun kracht’ te krijgen.
Dus als je kiest voor Agile werken, doe het dan niet, omdat je verwacht dat het je zomaar meer succes oplevert. Het vraagt om slimme, onderbouwde keuzes en een gedegen, zorgvuldige voorbereiding, zeker voor en met de medewerkers die het moeten gaan doen.
Ik werd een keer gewezen op een quote, die wordt toegeschreven aan Deepak Chopra:
“If you focus on success, you’ll have stress. But if you pursue excellence, success will be guaranteed.”
Mijn associatie in dit verband: Ongeacht de keuze die je maakt, neem de consequenties en streef ernaar het heel goed te doen. Zorg dat alle betrokkenen voorbereid zijn op een manier die past bij de gemaakte keuze, dat er reële verwachtingen zijn, dat er helder gecommuniceerd wordt met alle betrokkenen en dat je de ontwikkelteams slim hebt samengesteld. Dat wil zeggen: passend voor het doel, passend bij de gekozen methode, gebaseerd op talent, gericht op optimale samenwerking.
En vergeet vooral niet dat Succes = Kwaliteit x Acceptatie. Geen wetenschappelijke formule, maar vanuit het perspectief van een ‘klant’ zeker waar. En die acceptatie of waardering voor de gerealiseerde oplossing is niet gegarandeerd door de keuze voor een bepaalde (projectmanagement)methode.
Agile werken heeft zich allang bewezen, maar dan specifiek in de digitale hoek. Het filmpje waar je aan refereert geeft inderdaad het verkeerde voorbeeld of mist de nodige toelichting.
Het is echter niet zo dat je niet aan grote doelen werkt, dat doe je wel degelijk. De weg er naartoe is alleen niet vast uitgestippeld, die knip je op in allerlei testprojecten om zo snel mogelijk uit te vinden wat werkt en vooral ook wat niet werkt. Je test je product of methode en haalt zo snel mogelijk feedback vanuit de markt.
In het voorbeeld van het überhippe koekje zou je kunnen zeggen dat Anna iedere ochtend een serie koekjes bakt met een recept dat is aangepast op de klantenfeedback van de dag ervoor. Iedere ochtend gaan ze met de verse koekjes naar een winkelcentrum om de mensen te laten proeven. Ze noteren de feedback en gebruiken die om iedere middag om in de middag het recept aan te passen. Anna gaat hiermee door totdat 95% van de willekeurige proevers het koekje geweldig vindt.
Met het beste recept gaat ze nog naar 5 andere winkelcentra om de testresultaten te valideren. Wanneer dit ook aan de doelstelling (KPI's) voldoet besluit ze het koekje op de markt te brengen in 1 stad. Daar doet ze een product introductie met veel marketing kracht. Als het daar aanslaat kan ze besluiten om er vol voor te gaan, want vanwege de krachtige en opvallende product lancering heeft ze ook nog wat media aandacht gekregen en kan ze het direct de claim geven van "populairste koekje van Lutjebroek". Hierdoor is er al vraag voordat ze er vol voor gaat.
Als je achter de schermen bij Unilever zou kijken denk ik dat dit een werkwijze is waar ze niet aan kunnen tippen. Misschien moet je een nagaan wat het hun qua tijd en geld kost om een nieuw koekje op de markt te brengen. Ontwikkelproces van maanden, dan nog de verpakking, de distributie regelen, schapruimte reserveren bij Appie, enz. En dan natuurlijk een miljoen op TV besteden om enige aandacht te krijgen. Natuurlijk zetten ze ook de promotie in de supermarkten in, adverteren in de allerhande en damesbladen en een paar ton voor een online display campagne.
En dan blijkt het toch niet lekker aan te slaan want de testgroepen hadden toch net de verkeerde demografie...
Uiteraard kan dit ook een schot in de roos zijn en verovert Unilever daardoor ineens 40% van de überhippe koekjes markt. Echter is dit een veel grotere gok omdat er veel meer middelen voor worden ingezet dan Anna doet in het begin.
Agile is een methode waarmee je juist hele grote doelen kan realiseren met weinig initiële investering. Anna kan natuurlijk niet de route volgen die Unilever wel kan. Met haar kleine startkapitaal is het haar gelukt om het populairste koekje van Lutjebroek te lanceren. Omdat die specifieke KPI (Kritische Prestatie Indicator) is behaald komt nu de investeerder over de brug die kan helpen om een landelijke introductie te doen.
En ja, omdat deze methode voor vele internet start-ups heeft gewerkt die nu miljarden waard zijn, kijkt nu ook de rest van de markt naar deze methode want het blijkt toch echt te werken. Agile is echt geen mythe. Het werkt, alleen zegt de methode natuurlijk niet of het idee / product altijd slaagt. Agile zorgt er juist voor dat je snel realiseert dat je op het verkeerde spoor zit, of het juiste.
Bij Agile stel je je doelen steeds bij op basis van de feedback na iedere sprint. Hierdoor is het eindresultaat meestal iets anders dan bij de traditionele aanpak. Dit geeft de indruk dat Agile "soft" is. Eigenlijk heeft Agile iets weg van "snelle natuurlijke selectie" en "survival of the fittest".
Het (software)eindproduct bij de traditionele aanpak moet, nadat het door de user acceptance test is gekomen en opgeleverd is, vaak nog maandenlang daarna aangepast worden juist omdat het precies volgens het requirements document is ontwikkeld, maar daardoor zelden werkelijk aansluit bij de behoeften van de gebruikers en omdat de behoeften door de tijd heen vaak zijn voortgeschreden. Soms zie je bij de traditionele werkwijze ongunstige beslissingen, die tijdens een Agile sprint al vroeg naar voren zouden zijn gekomen en zo vermeden. Omdat het hele kaartenhuis in maanden tijd is opgebouwd rond die ongunstige beslissingen is aanpassing daarna bijna onmogelijk. Het resultaat is een project wat volgens de "meetlat" succesvol is, maar wat niet werkelijk aansluit bij de eindgebruikers.
En ja, natuurlijk kan een Agile team niet in isolatie werken en heb je het grotere integratiedoel nodig b.v. onder leiding van een Enterprise Architect. Deze manier van Agile ontwikkelen is mooi gedemonstreerd door Saab bij de ontwikkeling van hun Grippen gevechtsvliegtuig. Dit vliegtuig is (relatief) goedkoop en zelfs volgens Amerikaanse piloten, beter dan hun eigen Amerikaanse vliegtuigen.
In andere woorden het is bijna onmogelijk om de traditionele manier van werken te vergelijken met een Agile aanpak. Het neerzetten van een grote fabricagehal lijkt mij niet meteen een voorbeeld wat je met Agile aanpakt. Saab laat echter zien dat het ontwikkelen van een vliegtuig op basis van Agile prima gaat, zolang er goed op de integratie en samenwerking gelet wordt en er geen silo's ontstaan.
De Agile aanpak geeft vrijheid om in te spelen op het voortschrijdend inzicht en is daarmee minder voorspelbaar wat de uitkomst betreft. Ik vind het voorbeeld met de koekjes juist heel treffend. Bij de traditionele aanpak worden er marktstudies gedaan en grootse plannen gemaakt waarna er miljoenen in het project gedumpt worden. Bij een Agile aanpak begin je klein, test je de respons van de klanten en pas je de volgende stap in het project daarop aan. Het gevolg kan zijn dat je met Agile iets heel anders gaat produceren dan koekjes. Als je dat ziet als het falen van het koekjes project...
... Dan is een Agile aanpak inderdaad niet succesvol!