Daarom eens geluisterd naar Getting Things Done.. Fast, een audioprogramma waarin Allen het allemaal nog eens uitlegt. Na een half uurtje begon het te vervelen, want ik kende het toch allemaal al…: Collect, Process, Organize, Review, indelen in Projects, Next Actions benoemen etc.. Zoals dit plaatje:

Maar… toen begon ik eens op een rijtje te zetten wat ik allemaal nog wel en niet gebruik van GTD en welke andere oplossingen ik soms heb gevonden. Daarmee werd de exercitie steeds interessanter. Dus binnenkort mijn nieuwe post (in het Engels): My personal organizing system!

www.davidco.com

Tsja, wat moet je over de biografie van Steve Jobs zeggen. Seth Godin verwoordde wel mooi wat ik ervan overhield: “No one reports liking Steve Jobs very much, yet he was as embraced as any businessperson since Walt Disney. Because he cared. He cared deeply about what he was making and how it would be used. Of course, he didn’t just care in a general, amorphous, whiny way, he cared and then actually delivered.”

Die enorme passie die Jobs tentoonstelde, daar werd ik een paar keer stevig door geraakt in het boek. De “Think different”-campagne, het moment dat het ontwerp van de iPhone helemaal omgegooid werd omdat ze het toch niet goed genoeg vonden, de voorbereidingen voor productintroducties. Het is zulk onorthodox leiderschap, al helemaal voor een beursgenoteerde omgeving. Alleen de kwaliteit van het product doet er toe, los van financiële aspecten.. Ik kijk er naar uit om Inside Apple te gaan lezen, dat veel meer in gaat op de cultuur van het bedrijf..

http://www.amazon.com/Steve-Jobs-Walter-Isaacson/dp/1451648537

Het goede aan het iOverheid-rapport is dat de WRR een beschouwing over alle ICT-gerelateerde ontwikkelingen en projecten heen legt en daarmee op een iets abstracter niveau kijkt naar wat er eigenlijk gebeurt. Het volgende citaat is wat mij betreft de kern van het rapport:

“Wie verder kijkt dan de in het kader van de eOverheid ingevoerde applicaties en digitaliseringslagen ontwaart een kluwen aan informatiestromen die zich een weg banen binnen en tussen de verschillende overheden, in de relatie burger-overheid en daarbuiten. Informatie en hoe hierop te sturen vormt echter nauwelijks een expliciet benoemd speerpunt binnen het overheidsbeleid. Stapje voor stapje, besluit na besluit, vormt er zich in de dagelijkse praktijk een informatie-Overheid zonder dat hier een overkoepelende visie of besef op het niveau van de politieke aansturing aan ten grondslag ligt. De paradox van de iOverheid bestaat erin dat de overheid een iOverheid opbouwt waar ze zelf het bestaan niet van afweet.”

Wat ik wel sterk vindt is de indeling in stuwende (veiligheid, efficiency, effectiviteit), verankerende (privacy, keuzevrijheid) en procesmatige (transparantie, accountability) beginselen om keuzes voor informatisering mee af te wegen. Daarbij zie je dat investeringsbeslissingen en beleidsbeslissingen rondom ICT vaak genoemen worden vanuit de stuwende beginselen, waarbij de verankerende en procesmatige niet evenredig aan bod komen.

In het algemeen overleg over ICT-onderwerpen in de Tweede Kamer op 1 maart werd het iOverheid rapport mondjesmaat behandeld (https://zoek.officielebekendmakingen.nl/dossier/26643/kst-26643-229?resultIndex=0&sorttype=1&sortorder=4). Men slaat eigenlijk alleen aan op de meest concrete aanbeveling in het rapport: het opzetten van een iAutoriteit.

En daar heb je het precies te pakken. Mensen zijn op zoek naar concrete dingen. Vergelijk de discussie over “mobiliteitsconcepten”. Allerlei goeroe’s houden zich al jaren bezig met het mobiliteitsconcept, waarin er allerlei manieren zijn om van a naar b te komen, inclusief het besef dat je eigenlijk helemaal niet van a naar b hoeft, want in het kader van Het Nieuwe Werken lekker thuis kan blijven. Maar uiteindelijk denken de meeste van ons nog steeds in termen van auto’s, fietsen en treinen en kunnen we eigenlijk de keuzevrijheid die je krijgt bij “mobiliteitsconcepten” helemaal niet aan. En zo denkt de overheid (en de Tweede Kamer) in termen van systemen en koppelingen in plaats van aan informatiestromen en verankerende beginselen.

De aanbeveling om een bewuste afweging tussen stuwende, verankerende en procesmatige beginselen is dus een fantastisch idee, maar ik zie het nog niet in een willekeurig beleidsrapport terugkomen. Ook wordt gesuggereerd om “grenzen aan de groei te stellen”… maar hoe dan? als de iOverheid stapje voor stapje, besluit voor besluit ontstaat, hoe stel je dan grenzen?

Als oplossing daarvoor wordt in instituten gedacht als een “permanente commissie voor de iOverheid”, een “iPlatform” en een “iAutoriteit”. Aan de hand van de kamerbehandeling heb ik niet de indruk dat die er gaan komen, dus verwordt het iOverheid rapport tot een intellectuele discussie over beginselen. Maar… ik moet toegeven: iedereen heeft het tegenwoordig over de iOverheid in plaats van de e-overheid! Lekker concreet.

http://www.ioverheid.nu/

P.S.: mijn complimenten voor de enorme hoeveelheid verzameld materiaal in het kader van het rapport.

Alhoewel “What to expect when you’re expecting”, geleend van Nina, ook niet te versmaden babyliteratuur is, leverde “De taal van huilen” dusdanige aha-erlebnissen en eye-openers op (pardon voor het jargon), dat ik daar toch iets over moet schrijven.

“Waarom huilen babies?”, een vraag die menig jonge of oudere (wanhopige) ouder zich vast talloze malen heeft gesteld. Honger, pijn, krampjes, verveling, manipulatie, vermoeidheid of misschien wel allemaal tegelijk. En dus wiegen we, geven we spenen, troosten we, geven we nog eens “de borst” of “het flesje” of stellen we beloningen voor niet meer huilen in het vooruitzicht. En in de wat vijandiger richtingen van het spectrum negeren we, straffen we, schudden we zelfs door elkaar. En dat allemaal vanuit het idee “huilen is niet goed”. En in die aanname brengt dit boek nou net verandering..

“De taal van huilen” zegt dat babies en kinderen altijd huilen om een reden, hoe onbegrijpelijk of irritant dat ook voor ons kan zijn. En als die reden niet direct aanwijsbaar is, in de vorm van honger of pijn, moeten we dat huilen ook gewoon laten gebeuren. Kinderen hebben het nodig om te kunnen huilen om te verwerken wat ze hebben meegemaakt. Ouders moeten daarop reageren door het kind vast te houden en aandacht te geven. Als je dat goed doet, dan kan het kind snel zijn spanning ontladen en nare ervaringen verwerken, waardoor het ontspannen en vrolijk opgroeit.

In zo’n 160 pagina’s wordt natuurlijk meer toegelicht, ook over het tekeer gaan en de driftbuien van kinderen, maar de boodschap is telkens hetzelfde: ook het tekeer gaan heeft een reden en is niet per sé met straffen of negeren op te lossen. Kenmerkend is het “gebroken koekjes syndroom” waarbij kinderen volledig overstuur zijn “omdat hun koekje is gebroken”. Kinderen zoeken echter vaak een aanleiding om te gaan huilen of boos te worden, zodat ze hun spanning kwijt kunnen. Misschien is er eerder op de dag wel iets ergs gebeurd en zit het kind daar nog mee.

Ik kon hem één op één doorvertalen naar gedrag van volwassenen. Een partner die boos of verdrietig wordt om iets wat op het eerste gezicht totaal niet belangrijk is, anyone?

http://www.bol.com/nl/p/nederlandse-boeken/taal-van-huilen/666839329/index.html

http://nl.wikipedia.org/wiki/Aletha_Solter

Enter Carryology, a blog I’ve been following for a while now and whose contributors are close to gurus in the art of carry, writing about anything from wallets to bags to the best buckles. I decided to jump on their train and ride along.

So… here’s my first post for Carryology: Eight versatile office bags!

Hier komen er een paar:

- “de zomer”: een periode van welhaast mythische omvang waarin absoluut niets gebeurt, die zich, afhankelijk van degene die het woord gebruikt, uitstrekt tussen enkele dagen in juli en augustus tot de volledige periode tussen mei en oktober. Dingen moeten “absoluut vòòr de zomer” of kunnen wachten tot “na de zomer”.

In het bedrijfsleven is de zomer een wat onhandige periode, waar veel mensen even weg zijn, maar daar houdt het wel ongeveer mee op. Interessante waarneming: voor ambtenaren bestaat “de zomer” niet in het bedrijfsleven, want daar werkt iedereen immers altijd. Sterker: in de overheid is het ideaal om zo halverwege juni een offerte voor een enorm traject uit te zetten in de markt, eind juni de gunning te doen, zelf weg te gaan en dan “na de zomer” van de resultaten te genieten. Vanuit mijn oude werkgever hebben we wel eens vruchteloze pogingen gedaan om opdrachtgevers te overtuigen dat we voor ons onderzoeks-/adviestraject toch ook echt met de opdrachtgever bij moesten praten, mensen moesten interviewen en workshops moesten houden..

- “de kerst”: vergelijk “de zomer”, alleen hier gaat het om, afhankelijk van de belanghebbende, de week tussen kerst en oud en nieuw tot en met héél december en januari. Voor het bedrijfsleven telt “de kerst” overigens niet, die moeten gewoon doorwerken en deadlines kunnen op geen enkele wijze worden beïnvloed door “de kerst”. In mindere mate ook: “de krokus” en in bepaalde delen van het land: “de carnaval”.

- “de woensdag” en “de vrijdag”: dagen waarop vrijwel niemand werkt of bereikbaar is. Alle overheidscongressen vinden ongeveer plaats op “de donderdag”, want dan heeft heel ambtenarenland, zo lijkt het, niets te doen. Op “de maandag” wordt er vergaderd, op “de dinsdag” is iedereen aanwezig op kantoor, op “de woensdag” is iedereen vrij, “de donderdag” is er voor congressen en bijzondere vergaderingen en “de vrijdag” is er voor ofwel zeer exotische vergaderingen met een select gezelschap ofwel over lege gangen wandelen en bijpraten met de collega’s die er per ongeluk wel zijn omdat ze op “de woensdag” afwezig zijn.

- Het ministerie zegt dat “…..”: om onze woorden kracht bij te zetten verwijzen we regelmatig naar grote organisaties (of rapporten) met veel autoriteit. “De VNG zegt dat …..”, “De gemeente Amsterdam zegt dat ….”, “Het ministerie van Binnenlandse Zaken zegt dat ….”. Alsof de hele VNG, de hele gemeente Amsterdam en het hele ministerie zich hebben gebogen over het specifieke vraagstuk. Toegegeven, als het in een duidelijk beleidsstuk of uitspraak van de minister terug komt, dan mag je voor het ministerie spreken (al zijn er dan ook nog genoeg uitzonderingen). Maar meestal gaat het om één persoon die in een onbewaakt moment een uitspraak heeft gedaan, wat wordt vertaald naar “de gemeente” of “het ministerie”.

Ook: “Het rapport i-Overheid zegt dat”, “De commissie Jorritsma heeft gezegd dat ….”

En: “De manifestgroep zegt dat”, “De gemeenten zeggen dat” of “Europa zegt dat” om nog maar grotere eenheden te benoemen.

Gek genoeg komt het veel minder voor dat er aan andere aspecten autoriteit wordt ontleend:
- in onze planning gaan we uit van (is er geen planning? is ie niet belangrijk?)
- we hebben als stuurgroep besloten dat (worden er geen besluiten genomen? worden ze niet opgevolgd?)

De oplossing om deze barrières te slechten is eigenlijk altijd dezelfde: doorvragen.
“De VNG zegt dat”: Wie binnen de VNG zegt dat dan? Wat heeft ze precies gezegd? Waar kan ik dat terugvinden? En denkt ze er, anderhalf jaar later, nog steeds zo over?
“Dat kan pas na de zomer”: Wie zijn hier bij betrokken en wanneer zijn zij afwezig?
“Het rapport xxx zegt dat”: Over welke situaties zegt dat rapport iets en geldt dat hier ook?

Of “Mijn baas/onze interne organisatie zegt dat”; mijn reactie: “Oooh dan bel ik hem wel even om dat na te vragen!” Af en toe krijg je dan een heeeeeeeele zenuwachtige reactie

Martin was me voor met een recensie van dit geweldige boek. Cialdini’s “Influence” is een klassieker als je iets wilt begrijpen van het, soms toch best vreemde, gedrag van mensen.

Cialdini weet heel pakkend op te schrijven wat de 6 “weapons of mass influence” zijn, mechanismen waarop we min of meer automatisch reageren, maar die je wel degelijk bewust in gang kan zetten. Maar naast de vlotte schrijfstijl, is het ook zeer goed (wetenschappelijk) onderbouwd en toegelicht met smakelijke voorbeelden.

http://en.wikipedia.org/wiki/Influence:_Science_and_Practice

http://www.amazon.com/Influence-Psychology-Persuasion-Business-Essentials/dp/006124189X

http://www.influenceatwork.com/

Software moet zo vaak mogelijk gereleased worden, waarbij bij voorkeur bijna alle stappen van builds, testen en deployment automatisch gaan.

Als het geautomatiseerd wordt is het controleerbaar, herhaalbaar, sneller, niet gevoelig voor menselijke fouten. Dat is wat Humble en Farley toelichten in hun bijbel voor het moderne softwareontwikkelingsproces: Continuous Delivery. Vervolgens lichten ze in zo’n 450 pagina’s toe hoe dat in zijn werk gaat. Ondanks de taaie stof en soms technische insteek een pageturner..

Het boek start heel sterk met “antipatterns”; een beschrijving van patronen waaraan je kunt herkennen dat het niet goed gaat met het ontwikkelproces en de deployment van je software. Pijnlijk herkenbaar in sommige gevallen: na maanden van ontwikkeling wordt iets voor het eerst in een “productie-achtige” omgeving gezet, waar totaal verschillende versies van operating systems, databases, patch levels en dergelijke worden gebruikt, waarna je een hysterische uitwisseling krijgt tussen ontwikkel en beheerteams, want “morgen moet het live”. Iedere keer weer heb je slapeloze nachten bij een nieuwe release, en als er een fout ontdekt wordt in je software kost het dagen voor je ontdekt hebt waar het zit. Dat kan ook anders..

Wat als je bijna iedere functionaliteit die je bouwt meteen afrondt en in productie kan nemen? Dat je zelfs meerdere malen per dag een deployment kan doen in enkele seconden of minuten, dat je vrijwel zeker bent dat het goed gaat en als er toch iets mis is, dat je dat ook in enkele seconden of minuten weer terug kan draaien? Dan heb je je continuous delivery op orde..

Principes van software delivery
- create a repeatable, reliable process for releasing software: zorg dat je je hele proces van ontwikkelomgeving, testomgeving, regressie-omgeving, integratie-omgeving, performancetestomgeving, securitytestomgeving, gebruikerstestomgeving, acceptatie-omgeving, productie-omgeving en wat je nog meer nodig hebt uitgewerkt hebt en op dezelfde manier behandeld
- automate almost everything: zorg dat je zoveel mogelijk automatiseert: van je unittesten, interfacetesten, je builds, je deployment, alles; er is bijna geen reden meer te verzinnen om iets niet te automatiseren.
- keep everything in version control: zorg dat je alles zodanig in versiecontrole hebt, dat je moeiteloos een complete build kan reproduceren of terug kan gaan naar een probleemloze situatie als er iets mis is.
- if it hurts, do it more frequently, and bring the pain forward: de dingen die pijn doen in een ontwikkelproces: een build maken, deployment near andere omgevingen, integratietesten, most je zo vaak mogelijk doen en zo vroeg mogelijk in het proces, zodat het herhaalbaar, controleerbaar en uiteindelijk pijnloos wordt.
- build quality in: meet vanaf het begin voortdurend je kwaliteit en geef kwaliteitsproblemen absolute voorrang in je proces
- done means released: jets is pas af als het in een productie-omgeving staat. Maak je user stories zo klein mogelijk en maak ze meteen helemaal af, zodat ze zo snel mogelijk voor de gebruiker iets opleveren.
- everybody is responsible for the delivery process: iedereen is verantwoordelijk voor het proces om iets in productie te krijgen, dus niet alleen je beheerteam, niet alleen je testers, maar iedereen; best opgelost door multidisciplinaire teams in te richten
- continuous improvement: verbeter continu je proces.

Veel zaken in het boek worden voor mij iets te specialistisch: versie controle, branching en meeging, maar in grote lijnen is het goed te volgen en sluiten alle details aan bij de filosofie van de auteurs. En die filosofie is echt om te smullen, niet alleen voor de techneuten maar ook voor iedereen die geïnteresseerd is in de kracht van teamwerk en de mechanismen die daarin voorkomen.

Een absolute must als je iets met software ontwikkeling of beheer doet. Bij het Landelijk Register Kinderopvang passen we deze werkwijze bijna in zijn geheel toe; dus kom gerust eens langs als je het in de praktijk wil zien!

Jez Humble’s blog over Continuous Delivery: http://continuousdelivery.com/
David Farley’s blog: http://www.davefarley.net/
Boek op Amazon: http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

Check out more pics on Flickr!