- Gegevens
Als je ooit aan projectplanning hebt gedaan zou je kunnen weten dat Douglas Hofstadter, in zijn boek Gödel, Escher, Back, een belangrijke wetmatigheid heeft geformuleerd die De Wet van Hofstadter heet:
Alles duurt langer dan je denkt, zelfs als je rekening houdt met de Wet van Hofstadter
In de praktijk is deze recursieve wet heel lastig te gebruiken. Ik gebruik meestal een niet-recursieve variant, die ook rekening houdt met de planning van een project:
Een zorgvuldig gepland ontwikkelingsproject duurt π keer langer dan je denkt. Als je niet zorgvuldig plant, wordt dit π2
- Gegevens
Bij de RAMIRI-training (Realising and Managing International Research Infrastructure) die ik deze week in Triëst volgde, sprak één zin mij bijzonder aan. Deze was van Kimo Koski (CSC Finland) die opmerkte dat het moeite kost om een organisatie klantgericht te houden terwijl deze groeit.
Vanaf ongeveer 100 mensen kan een organisatie zichzelf volledig bezig houden zonder ooit een klant te bedienen.
Toen ik voor Bruker AXS werkte, zei onze verkoopdirecteur Paul Ulrich Pennartz soms iets verwants als hij in een cynische bui was:
Zonder die vervelende klanten zouden we ons eindelijk kunnen concentreren op ons werk.
Als je je ooit hebt afgevraagd waarom kleine bedrijven sneller reageren dan grote, dan denk ik dat deze twee mensen de oorzaak vrij goed samenvatten.
(noot: dit is de essentie van wat deze beiden gezegd hebben, dit waren niet hun letterlijke woorden)
- Gegevens
Als er meer dan één taak moet worden voltooid, is het altijd beter om de ene voor de andere te doen. Dat besprak ik eerder in de post Parallelle processen in een projectteam.
Een individuele klant met een nieuwe vraag zou kunnen denken dat het nog sneller gaat als je zijn project ertussen inpast. We moeten die klanten ervan bewust maken dat als we onderbrekingen van welke aard dan ook toestaan in een agile sprint, niets ooit zal worden afgemaakt. Wat kunnen we ze vertellen? Er zullen andere mensen zijn met nieuwe verzoeken terwijl we aan uw taak werken.... moeten we ook hun verzoeken honoreren om ons werk te onderbreken?
Ze moeten begrijpen: agile sprints worden niet onderbroken. Ze worden voltooid of geannuleerd.
Image from Flickr by brittgow
- Gegevens
In een organisatie met meer dan twee mensen is er hoogstwaarschijnlijk een hiërarchie. Sommige mensen managen anderen.
Aan de andere kant zijn projectleiders niet noodzakelijkerwijs managers van de leden van het projectteam. Projectleiders kunnen geen opdrachten geven om dingen voor elkaar te krijgen. In onze organisatie is het nog erger: projectteamleden zijn in dienst van verschillende universiteiten en ziekenhuizen en de projectleiders zitten in onze aparte groep. Opdrachten werken niet.
Een vraag die soms opkomt is: hoe kun je een project en zijn teamleden managen zonder opdrachten te geven? Soms komt dit in de vorm: voor jou gaat het veel makkelijker, jij bent de baas en kunt iedereen vertellen wat ze moeten doen; Ik heb niet zoveel macht over het projectteam. Mijn antwoord daarop is: hoe vaak zeg ik wat je moet doen? En als ik je niet opdraag wat te doen, hoe leiden we dan een samenhangende organisatie?
De clou is: vertel mensen niet wat ze moeten doen, maar overtuig ze. Bouw vertrouwen op (dit duurt even) en gebruik vervolgens uw expertise om de leden van het team te overtuigen zich aan te sluiten.
In grotere organisaties verstrekken managers niet zo vaak opdrachten. Vertrouwen (en expertise) zijn veel effectiever. En dit wordt hoger in de organisatie sterker, tot aan de CEO toe. Het grootste probleem met managementmacht is dat het minder gaat werken elke keer dat je het gebruikt. Vertrouwen groeit bij correct gebruik.
Manage niet door bevelen te geven. Gedraag je als de CEO van een groot bedrijf.
Luister voor meer inspiratie naar deze cast van Manager Tools.
[Afbeelding: opdrachten geven door lincolndisplayimages.com op flickr]
- Gegevens
Er zijn twee manieren van autonavigatie: non-agile en agile. Niet-agile navigatie is wanneer u een vel papier meeneemt met instructies zoals deze:
5 km rijden. Ga naar links. Bij het derde stoplicht rechts, dan voor het blauwe gebouw links. Stop wanneer u aankomt bij een tankstation.
Niet-agile navigatie werkt prima als er een pad naar de bestemming is dat bekend is en waar je geen fouten kunt maken. Als er iets verandert op het pad, als er wegwerkzaamheden zijn, als je een fout maakt op de route: dan is er geen tweede kans; het zal onmogelijk zijn om met de bestaande instructies de bestemming te bereiken. Bovendien: als er niemand in de buurt is die naar dezelfde bestemming is geweest (zelfs meerdere keren), is het onmogelijk om zo'n gedetailleerde beschrijving van de route te krijgen.
Agile navigatie maakt gebruik van verkeersborden. Om bij het San Francisco Museum of Modern Art te komen, volg je eerst de borden naar Californië, vervolgens naar San Francisco en daar aangekomen volg je de borden naar SFMOMA. Het enige dat je moet weten, is waar je heen gaat, en ongeveer waar dat is (recursief, als je wilt). Deze manier van navigeren is zeer robuust: ook als een straat eenrichtingsverkeer wordt, of als het blauwe gebouw wordt afgebroken, kun je nog steeds op je bestemming komen. Wat nog beter is, is dat als uw exacte doel onderweg verandert, je de plannen nog steeds kunt wijzigen. Op weg naar San Francisco kun je nog steeds besluiten dat je in plaats van het museum de Golden Gate wilt bezoeken.
Nu probeer ik je natuurlijk niet te leren hoe je in een auto moet navigeren. Ik wil dit gebruiken als metafoor voor de ontwikkeling van software.
Hoe is softwareontwikkeling zoals navigatie? Je weet normaal gesproken niet precies wat je moet ontwikkelen. En slechts zelden kun je precies de sporen van iemand anders volgen. Softwareontwikkeling is niet zoals het bekende pad dat geschikt is voor niet-agile navigatie.
Toch wordt er nog steeds veel software ontwikkeld met behulp van niet-agile methodes. Specificaties worden volledig vastgelegd voordat de ontwikkeling wordt gestart. De exacte stappen die nodig zijn, zijn in detail beschreven. Contracten worden getekend. En dan ontstaan er wegblokkades, en het project overschrijdt het budget en loopt achter op schema. En als het project opgeleverd is, is de klant niet blij met de functionaliteit omdat ofwel zijn ideeën veranderd zijn, ofwel hij zich niet nauwkeurig genoeg heeft kunnen uitdrukken in de specificaties.
Agile softwareontwikkeling heeft alle voordelen van agile navigatie. Je kunt naar onbekende plaatsen gaan. Je kunt onderweg zelfs de details van de plannen wijzigen. En het is zeer robuust tegen onverwachte wegblokkades. Het is duidelijk de juiste keuze.
Agile softwareontwikkeling is niet eenvoudig. Maar het is minder vatbaar voor totale mislukking dan de traditionele methode. Laten we leren navigeren op de verkeersborden!
- Gegevens
We hebben nogal wat geëxperimenteerd met verschillende manieren om onze groepsbijeenkomsten te houden. Bij de meeste van onze vergaderingen voegen sommige groepsleden zich bij ons vanaf andere locaties, en we willen dat de externe leden volwaardige deelnemers aan de vergadering zijn.
Een tijdje deelden we alleen het geluid met de deelnemers op afstand, via skype. Dat werkte redelijk goed, maar het bracht de moeilijkheid met zich mee dat de deelnemers op afstand niet hetzelfde scherm konden zien dat we op de muur in onze vergaderruimte projecteerden. Als we maar één externe deelnemer hadden, konden we een lo-fi-beeld verzenden via video-skype, maar dit was nauwelijks beter dan helemaal geen scherm.
We zijn toen verschillende software voor webvergaderingen gaan uitproberen: een gratis proefversie van gotomeeting en de gratis versie van dimdim (toen die nog beschikbaar was). Gotomeeting had het probleem dat het Windows, Mac en Linux niet in gelijke mate ondersteunt. Dimdim had betere ondersteuning voor verschillende besturingssystemen, maar had een veel slechtere geluidskwaliteit en de video was soms helemaal zwart of vertraagd met wel 10 seconden. Deze "officiële" oplossingen hebben voor ons dan ook niet geleid tot een betere communicatie.
Ons probleem was opgelost toen we ons realiseerden dat we skype voor audio konden gebruiken en allemaal hetzelfde scherm konden delen door VNC te gebruiken. We hebben een VNC-server met (alleen-lezen) java-client geïnstalleerd op een van onze linux-servers. Tijdens een meeting heeft de meeting facilitator de touwtjes in handen via een read-write VNC-sessie terwijl de andere deelnemers alleen maar toekijken. De audioverbinding gebeurt zoals voorheen via skype, waardoor audio van goede kwaliteit wordt geleverd via een speciale externe luidspreker/microfooncombinatie.
Hier werden we heel blij van, zonder maandelijkse abonnementskosten. Ik hoor graag over andere alternatieven.
Update: Esther van Enckevort legt in een posting op haar blog uit hoe je een VNC-server opzet zoals wij deden.
- Gegevens
Hoe belangrijk is het om prioriteiten te stellen?
Laten we aannemen dat we 4 ideale projecten A, B, C, D en een ideaal projectteam hebben. Elk van deze projecten neemt 3 maanden in beslag. Ze zijn allemaal even belangrijk. We werken er parallel aan. Wanneer zijn de projecten klaar? Project A is na 12 maanden klaar. Project B is na 12 maanden klaar. Project C is na 12 maanden klaar. Project D is na 12 maanden klaar.
Wat gebeurt er als we prioriteiten stellen en aan de projecten in alfabetische volgorde werken? Wanneer zijn de projecten nu klaar? Project A is na 3 maanden klaar. Project B is na 6 maanden klaar. Project C is na 9 maanden klaar. En project D is na 12 maanden klaar. Iedereen behalve de klant van project D wordt er beter van! Fantastisch, toch?
Helaas is dit niet de perceptie van de klanten. Elk van hen ziet een project van 3 maanden en wil het in 3 maanden af hebben. De klant in project D wil niet horen "we gaan over 9 maanden aan je project beginnen". Prioriteiten veranderen daarom maar al te vaak. Elke maand, tijdens een evaluatie van het projectteam, zul je gedwongen worden om nieuwe prioriteiten te stellen. Wat is het effect? Project A is na 9 maanden klaar. Project B is na 10 maanden gereed. Project C is na 11 maanden klaar. Project D zal na 12 maanden klaar zijn.
Wat een verspilling. Trap niet in deze val. Stel prioriteiten en blijf bij de keuze.
[Afbeelding: goldstardeputy]
- Gegevens
Een van de eerste fasen in de ontwikkeling van een nieuwe tool (software of hardware) is een functionele specificatie. De functionele specificatie rijpt in discussies tussen de ontwikkelaars (afdeling R&D) en de vertegenwoordigers van de klant (vaak de afdelingen marketing en verkoop).
Natuurlijk is een functionele specificatie handig: het is erg moeilijk om iets nieuws te ontwikkelen zonder een idee te hebben van hoe de nieuwe tool zal worden gebruikt en waarmee deze zal worden vergeleken. Het definiëren van een functionele specificatie kan echter ook te ver gaan. In sommige organisaties zijn de functionele specificaties tot in de kleinste details uitgewerkt. Aan het einde van een lange formele procedure wordt het bestekboek ondertekend als een contract tussen marketing en ontwikkeling. De ontwikkeling kan pas worden gestart als de lijst met handtekeningen compleet is en zal worden uitgevoerd in complete afzondering van de wereld van potentiële gebruikers. Waarom maken organisaties hun specificaties op deze manier? Het is vaak een poging om de verantwoordelijkheden van de afdelingen te scheiden, zodat als er iets niet lukt de juiste partij de schuld krijgt. Als het eindproduct niet voldoet aan de functionele specificaties, kan dit worden toegeschreven aan de ontwikkelaars. En als het product niet slaagt terwijl het wel aan alle functionele specificaties voldoet, wordt dat aan de marketing toegeschreven.
Ik heb een serieus probleem met deze benadering: hoe kan men er met behulp van deze procedure voor zorgen dat het product nuttig zal zijn? Na twee jaar zonder interactie kan ontwikkeling precies opleveren waar marketing om vroeg (alle deadlines halen en binnen budget), maar de markt is veranderd en heeft het ontworpen product niet meer nodig. Of de techniek is veranderd, en betere specificaties zouden binnen handbereik zijn geweest en worden aangeboden door de concurrentie. Of misschien heeft marketing echt een fout gemaakt en gevraagd om iets waar de wereld niet op zit te wachten. In deze gevallen kan de ontwikkelingsafdeling duidelijk niets worden verweten! Maar als je op deze manier een verouderd product ontwikkelt, waar blijft de organisatie als geheel dan? En als dit niet de beste oplossing is voor de organisatie als geheel, is het dan wel goed voor de ontwikkelafdeling? Ook al deed iedereen precies wat er van hem verwacht werd, toch kunnen er mensen ontslagen worden omdat ontwikkelingskosten niet terugverdiend kunnen worden.
De oplossing is, zoals zo vaak, om een middenweg te behouden. Met behulp van b.v. Met Agile- of LEAN-ontwikkelingsmethoden kunnen ontwikkelaars voortdurend in contact blijven met marketing. Iteratieve en modulaire ontwerpprocedures kunnen worden gebruikt om te controleren of de nieuwe tool doet wat hij moet doen, zonder te vertrouwen op het vermogen van mensen om specificaties vooraf in woorden te beschrijven. En omdat de communicatie met de markt niet verloren gaat tijdens het ontwikkelproces, heeft de tool een aanzienlijk grotere kans om daadwerkelijk bruikbaar te zijn op het moment van introductie.
Afbeelding (door QuiteLucid op Flickr): "een kameel is een racepaard ontworpen door een commissie".
- Gegevens
Stel je een mechanische werkplaats voor. Je komt met een probleem dat zij oplossen. Wat verwacht je? Je verwacht met hen samen te werken, grofweg in de volgende vijf stappen:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Ontwerp. Ze gaan een tekening maken
- Onderdelen. Zij (mogelijk meerdere mensen parallel) zullen het ontwerp gebruiken om onderdelen te selecteren en te vervaardigen
- Product. Ze zullen de stukken aan elkaar lassen tot het ding dat je nodig hebt
- Test. Je test het en het kan kleine aanpassingen vereisen
Stel je nu een softwareworkshop voor. Je komt met een probleem dat zij oplossen. Wat verwacht je?
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Product. Zij zullen de softwaretool maken
- Test. Je alfatest, ze repareren, je bètatest, ze repareren. Herhaal tot bevredigend
Hoe komt het dat deze lijst slechts drie in plaats van vijf stappen bevat? En waarom veroorzaakt de laatste stap altijd zoveel pijn? Zou dit verschil de oorzaak kunnen zijn waarom zoveel softwareproducten falen? Wat is het echte verschil tussen software- en hardwareontwikkeling?
In plaats van te proberen het softwareprobleem in één keer op te lossen, stelt u zich eerst een hardwarewerkplaats voor die als volgt werkt:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Product. Ze zullen materialen aan elkaar lassen tot een stuk gereedschap
- Test. Je test, zij repareren, je test opnieuw, zij repareren. Herhaal tot bevredigend
Hoe waarschijnlijk is het dat deze procedure sneller is dan de procedure in vijf stappen? Hoe duidelijk is het welke stukken aan elkaar moeten worden gelast? Kunnen hierdoor meerdere mensen samenwerken aan het product? En hoeveel werk is het testen voor jou? Hoeveel afval komt er vrij in het proces? Je zou dit soort beunhazerij niet accepteren! En mijn punt: je moet het ook niet accepteren van een softwarewerkplaats.
Een goede softwarewerkplaats zou dezelfde vijf stappen gebruiken als de goede mechanische werkplaats:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Ontwerp. Zij maken een (modulair) ontwerp
- Stukken. Zij (eventueel meerdere programmeurs parallel) zullen het ontwerp gebruiken om softwaremodules te bouwen en te selecteren
- Product. Zij zullen de modules gebruiken om de software te bouwen die je nodig hebt
- Test. Je test het en er zijn misschien kleine aanpassingen nodig
Investeren in een ontwerp zal resulteren in een oplossing die het gestelde probleem echt oplost en geen eindeloze iteraties vereist om het goed te krijgen. Het lijkt misschien een trage oplossing, maar dat is bedrog: je krijgt daadwerkelijk een resultaat dat je brengt waar je wilt zijn, ook als je in de toekomst nieuwe aanvullende wensen hebt.
(Ik wil graag een oud-collega bij Bruker AXS bedanken die me deze mooie vergelijking heeft gegeven. Ik weet dat hij anoniem wil blijven op het internet. Beeldcredits: Dystopos op Flickr)
- Gegevens
Na elke ingrijpende verandering in een organisatie is er behoefte aan een fase van rustige doordachte verbeteringen. Wonderen verwachten van enorme bedrijfsreorganisaties is een misvatting die leidt tot reorganisatie na reorganisatie, mogelijk resulterend in volledige vernietiging van de organisatie.
Heb je ooit een spelletje Pac-man gespeeld? Het is een eenvoudig spel waarbij je een kleine figuur bestuurt die stippen op het scherm eet, terwijl geesten je achtervolgen. De game is een uitstekende spiegel van het zakenleven in een veranderende omgeving:
- In Pac-man probeer je bij elke stap je gezondheid te verbeteren door een stip te eten en uit de buurt van de geesten te blijven.
- In het zakenleven brengt u kleine wijzigingen aan in uw producten en procedures om meer te verkopen en uw concurrenten uit de weg te blijven.
Er is nog een analogie:
- In Pac-man lopen dingen soms vast. Geesten komen van alle kanten dichterbij en er is geen ontkomen aan. Op zo'n moment kun je gebruik maken van de teleport: een paniektoets die je in een oogwenk naar een willekeurige plek in de scene brengt.
- In het zakenleven loopt het soms vast. Concurrenten komen dichterbij en het lijkt erop dat er geen uitweg meer is. Op zo'n moment roept de CEO (vaak snel zonder alle betrokkenen te raadplegen) om een ingrijpende reorganisatie.
In het bedrijfsleven is er een belangrijke les die we kunnen leren van de teleportfunctie in Pac-man: een teleport is verre van een gegarandeerde redding! Het kan je in een zeer gevaarlijke situatie brengen. Het doel van de teleport is niet een onmiddellijke verbetering van het verloop van het spel, het is om te ontsnappen aan een hopeloos vastgelopen situatie, aan een dreigende ramp. Direct na een teleportatie moet je handelen en stappen ondernemen om de controle terug te krijgen. Evenzo zal een ingrijpende reorganisatie in het bedrijfsleven zelden direct een betere situatie brengen. Een reorganisatie is bedoeld om de boel op te schudden en te ontsnappen uit een hopeloos vastgelopen situatie (vaak onzichtbaar voor veel van de medewerkers). Na de relatief gedachteloze sprong die snel moet worden uitgevoerd om een onmiddellijke game over te voorkomen, zal de organisatie een doordachte fase moeten ingaan waarin kleine verbeteringen worden aangebracht om de situatie te optimaliseren.
Als u zich realiseert dat een reorganisatie u niet onmiddellijk winst heeft opgeleverd, probeer dan af te zien van verdere reorganisaties. Zoek in plaats daarvan naar mogelijkheden voor kleine veranderingen en geef het wat tijd.