Posted on Leave a comment

7 Rules for the Ruler (not to be ruled)

Rule I: One rule to rule them all

“You shall not be subject to emotions”

Rule II:

“Expecting gratitude is not the attitude”

Rule III:

“When fought, you shall not fight (nor shall you weep; you shall smile)”

Rule IV:

“You shall concern but not be concerned about”

Rule V:

“You shall act beyond ethics or morality”

Rule VI:

“Your weakness shall be your strength”

Rule VII:

“Fairness was not part of your job expectations”

What can I say?
Oh, what to do?
Not to feel and who are you?
What shall we do if baby turns blue?
I see further to a day, to a day never to come.
With eyes in the back of my head I see all around me.
Posted on 2 Comments

Scrum (all sorts of people)

logo-myfragilityScrum is also in the minds of people. My mind is set on the ability of fragility. How about you?

Are you ‘management’? Then you should not only be willing to believe that a software project can truly deliver quality and business value. You should also do (a lot) more than just gather a group of programmers with a project manager on top during a (project’s) timebox.

Okay, so far for a view the community will quickly agree upon.

What is usually less focused on is the level of commitment of the actual team members. In my experience this may turn out to be at least as difficult to achieve. Because it takes the absolute will to self-organize, not wanting to depend on other people to take decisions for you (the essence of ScrumMaster facilitation versus Project Management’s execution of control), to outweigh every (technical) choice against the (business) value and functional profit, to discuss and communicate openly, etc.

Scrum is a simple way to outperform and excel but all parties should respect its essence, that I represent on my Scrum Diamond:scrum-diamond

think (talk) about it…

Posted on 1 Comment

Loving Facebook, Hating Facebook

facebook-logoPablo Zarate made a clear statement. Capo wrote about it. I’m getting bored with it. And here’s 25 reasons not to love it:

I don’t agree on every single reason, but certainly on a majority.

So let’s be trendy (for once) and:

  • Get rid of unused friends
  • Keep professional contacts at LinkedIn
  • Don’t accept silly requests or things getting thrown
  • Bluntly… defriend (I will start with people that don’t even respond to a personal e-card for their birthday. I just hate that!)

Okay, maybe my virtual network will look as friendless as my real life network :-(. But I will surely feel relieved and de-stressed :-).

Let’s use it pragmatically to keep informed of:

  • Real messages of real friends
  • Real friends’ birthdays
  • Events of bands/groups/subjects of interest
  • Worthwhile causes
Posted on Leave a comment

Gestapelde intenties (lees::boeken)

Eerder heb ik al eens bekend dat ik koop. En dat dit tot een weldadige overdaad aan boeken leidt. Maar sinds het schooljaar is losgebarsten, heeft er zich, bovenop deze chronische overgroei van blijvende aard, ook een meer accute opeenstapeling van leeswerk voorgedaan:

Een gedeeltelijke oorzaak is dat ik zelf nog zoveel wil uitspuien, waarbij: het hypothetische voornemen om voor den arbeid elke dag 1 deliverable te k*kken, uitwerking en beschrijving van mijn persoonlijke expertise in Scrum en andere schrijfsels -van eerder literaire aard-.

En dan ga ik het toch weer niet kunnen laten om op de boekenbeurs enkele werkjes aan te schaffen. Ik denk al jaren aan (het verzamelde) Het Beleg Van Laken van Walter Van den Broeck, ben erg geïnteresseerd in de nieuwe Grunberg (Mijn Oom), wil toch ook naar Dinsdagland met Dimitri Verhulst (remember godverdoms bericht), heb weet van Duivels van Dostojevski (alles van gelezen in mijn verre jeugd), in een sjieke uitgave van Athenaeum-Polak & Van Gennep (heb al verscheidene andere titels van de reeks).

En, awel, op de tijd dat ik dit bericht heb gemaakt, had ik ook weeral zòveel andere dingen kunnen doen.

Posted on 2 Comments

Kanban and Scrum (done or to be done?)

Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.

In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).

My.Fragility_logoMy Scrum Product ànd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).

Velocity is a way to optimize the inventory and the continuity of work. Traditionally ‘velocity’ equals the #Story Points (gummy bears) that can be finished in one iteration (a Sprint). However, I apply an overall Velocity as a multiplicator on Story Points (ideal time) to result in #planning days. The size of the inventory (in #Story Points) for a Sprint is determined by dividing the available #planning days of a team (minus 2 slack days) by expected Velocity (Yesterday’s weather). Note: continuity is also assured by the presence of the Product Owner. He/she makes sure that no functional issue remains unsolved, on the spot!

Posted on Leave a comment

Scrum and the Cooperative Game

In many (IT) partnerships and implementations people seem to prefer to strangle each other rather than assure mutual benefits.

I’m applying Scrum (over 4 years already), in my projects and in my management. It continuously helps me to cross fences; between suppliers and customers, business and IT, analysts and developers, x-layer developers and y-layer developers, etc.

In my Scrum-based development process I use Pre-Game Staging to name the barely enough preparative phase for 1 stage of software development. The “Games” metaphor was described by Alistair Cockburn in his biblical work Agile Software Development. I strongly agree with him that software development should be a Cooperative Game.

  • Cooperative: a team of people works together towards a common goal, not to fight each other.
  • Non-zero sum: the players are not opposed and do not try to win by getting the other at zero. There are multiple winners.
  • Finite and goal-seeking: the game ends when the goal is achieved. The game is not meant for just staying in existence.

You will find this as well in the integrated prerequisite for supplier-customer relationships (possibly multi-tier), from Toyota’s Lean Production to Poppendieck’s Lean Software Development. It offers far more certainties than our commonly applied bidding processes. Think (read) about it!

Posted on 1 Comment

Iedereen Manager! (bekentenis #1)

Zoals Van Rossum ooit de verkiezingsbelofte “Iedereen een Ferrari” lanceerde, vind ik (pas op, hier komt de slogan):

Iedereen MANAGER!

Omdat iedereen toch denkt dat hij (ook: zij) het beter weet, het beter kan, beter steken kan (dood), steeds hoger (de ‘Peter’ in elk van ons -die van het principle- tartend). Meer geld, meer titel, meer auto, meer macht, meer meester, minder anderen, meer meer MEER… ALLES!!!

…behalve ik.

Omdat ik gedij, vegeteer, prospeer in de schaduw; ver weg van de lijkengeur en gewette messen. Zonder strategie, een vroeggestorven diplomaat, verdwaalde huurdoder, tekstloze scherpschutter.

Omdat ik… dichter ben, niet meer ben dan begaan met woorden, steeds dichter bij woorden ben, dan een manager bij mensen.

Omdat ik, zelfs als projectmanager, kunstenaar ben. Op zoek naar de autonomie van mijn werk, steeds afhankelijk van een mecenas, dus voortdurend balancerend tussen werk, medemens en … manager.

Posted on 2 Comments

De kost van een plekje om te werken

Een berekening die niet zo vaak gemaakt wordt, alhoewel een studie hierover toch een verrassend hoog cijfer oplevert: een werkplek kost 12.000€ per jaar in België (onlangs gelezen in De Morgen).

Dus… je hebt hier als werkgever best wel een zware kost. En daar wil je besparen als het even kan. Dat doe je ondermeer door mensen structureel thuis te laten werken. Hey, bevestig je gelijk ook even je modern imago. Heb je ook nog het voordeel dat je aantrekkelijk blijft voor de talenten van vandaag, die als het even kan ook liefst nog besparen op filetijd. Overal winst. Maar je mensen hebben op afstand niet alleen hun documenten en andere informatiebronnen nog nodig, ze willen die ook actief kunnen delen en er zelfs over kunnen communiceren.

Pffft. Gaat het je een beetje duizelen? Niet nodig, want de visie en de technologie om dit te verwezenlijken bestaat en is bewezen. En geheel toevallig hoort het niet alleen tot mijn fascinaties, maar ook tot mijn professionele werkzaamheden. Dus als je vragen, opmerkingen en zo meer hebt over dingen als de ‘High-Performance Workplace‘ (HpW), Sharepoint/MOSS, Live Communicator, OCS laat je maar een berichtje achter.

De firma dankt u ;-)