Category Archives: Books

Book review: Commitment, novel about managing project risk by Maassen, Matts & Geary.

Posted on by

Cool, a graphic novel, brilliant idea to share ideas about the subject. The drawings are very nice. Refreshing to see the main character is a woman, who is supported by her younger sister.

The main idea of the book is about Real Options. Three things you need to know about real options;
1. They have value,
2. They expire,
3. Never commit early unless you know why.

In the story, Rose Randall is appointed project manager to a project in trouble. With the help of a kanban visualisation board she gets control of the state of project. Tasks can have only 3 statuses: ..not started….work in progress…and done. Percentages are nonsense (thank you authors).

New for me was the concept of staff liquidity. This is the time it takes for a team to respond, the time to redeploy people. Based on this concept and the real options model you allocate the most experienced people last (!) to tasks. Experienced people have to most options. This point reminds me about the super programmer you don’t want in your project and the lessons from Peter Drucker (The Effective Executive) about key man dependencies in projects. Really cool stuff.

It’s a great book, which makes you think. I enjoyed reading and thinking about it. Truly recommend it to (project) managers.

P.S;
Once a while I hear someone mentioning the phrase “failure is not an option”…hmm…after reading this book I hope is an option…..I sure don’t want people commit to failure. 🙂

My view on the concept of Leadership

Posted on by

Recently I overheard a discussion about the concept of leadership within my company. The word makes me smile since a couple of years. There are many ideas and definitions about this word.

After attending the Problem Solving Leadership Workshop (2011) & the Change Artistry Workshop (2013), my view about leadership is summarized in a poem and a statement;

If you are a good leader,
Who talks little,
They will say,
When your work is done,
And your aim fulfilled,
“We did it ourselves.”
— Lao Tse —

 “Leadership is the process of creating an environment in which people become empowered.”
— Jerry Weinberg —

This environment must contain three ingredients:

  • Motivation–the trophies or trouble, the push or pull that moves the people involved
  • Organization–the existing structure that enables the ideas to be worked through into practice
  • Ideas or innovation–the seeds, the image of what will become

Note: creating the environment is hard work, destroying it is easily done.

It is time to re-read “Becoming a Technical Leader an organic problem-solving approach” again.

Boek review: Big Data geschreven door Tom Breur

Posted on by

Big Data. Er lijkt geen ontkomen meer aan te zijn, iedereen praat en schrijft over deze nieuwste hype. Het is eigenlijk een hype waarvan ik zelf dacht dat ik me daar niet zo druk om hoefde te maken. In de regel volg ik het principe dat als de leveranciers heel hard brullen ik rustig aan de zijlijn blijf staan tot het echt duidelijk wordt of het wat is. Ik laat me in ieder geval niet door leveranciers overtuigen dat ik een early adopter moet worden. Het kost namelijk vaak simpelweg teveel geld en tijd om vroeg in te stappen. Daarnaast heb ik ook ooit eens een overtuigend verhaal gelezen over een IBM principe: always be second.

Het boek. Heel fijn, voor de niet Big Data expert, is dat helder uiteen gezet wordt in begrijpelijk Nederlands wat het verschil is tussen SQL en NoSQL en de impact ervan op Big Data dit inclusief de positionering van Hadoop. Dat scheelt weer een heleboel uitzoek werk. Aan de hand van praktijk voorbeelden wordt duidelijk gemaakt dat Big Data alleen maar waardevol is in de context van “small data” uit je datawarehouse.

Je heb ook een bijzonder type medewerker nodig die aan de slag gaat met Big Data, namelijk de data scientist. Ik had die term al vaker gelezen, maar het is me nu duidelijk geworden dat je een dergelijk persoon nodig heb. In de huidige jonge levensfase van Big Data zal het nog niet eenvoudig zijn om daar goede mensen voor te vinden.

Onderwerpen als sentimentanalyse, long tail marketing, micro targeting komen ruimschoots aanbod en worden verduidelijkt met leuke herkenbare voorbeelden. De voorbeelden komen uit verschillende werelden; van McDonalds, Twitter, Rijkswaterstaat, Politie, naar Call centers.

Er wordt veel verteld over de business case rondom Big Data. Dit is een boeiend hoofdstuk om te lezen. Met name als er verbanden gelegd worden met de theorie van Michel Porter en Treacy & Wiersema. Mocht je weinig tijd hebben om te lezen, pak dan dit hoofdstuk!

Het hoofdstuk over privacy heeft me aan het denken gezet. Er liggen een aantal gevaren op de loer. Enerzijds de veranderende wetgeving (inclusief de verschillen tussen Amerika en Europa) wat neerkomt op een waarschuwing voor de consument en anderzijds hoe denk je als bedrijf straks te dealen tussen privacy en Big Data? Dat zal geen eenvoudige opgave worden.

Het oordeel. Het boek is heerlijk leesbaar geschreven, met sprekende praktijkvoorbeelden. Hierdoor maakt de auteur het thema Big Data concreet en levendig. Het is geen halleluja verhaal over hoe geweldig Big Data wel niet is, en dat is prettig. Leveranciers zijn daar veel beter in om dat te vertellen. De belangrijkste thema’s komen allemaal aanbod, waaronder de thema’s privacy en de business case.

Dat Big Data niet zomaar iets is wat je er even bij gaat doen is wel duidelijk geworden. Dat wist ik eigenlijk al maar fijn dat het weer bevestigd wordt. Laat Big Data a.u.b. geen IT-feestje worden.

Eigenlijk ben ik heel benieuwd naar een opvolger van dit boek over een paar jaar. Hierin kan dan een reflectie gegeven worden op de huidige hoofdstukken. Is Big Data over 5 jaar “mainstream” geworden of doen alleen hele rijke en/of slimme bedrijven nog aan Big Data?

Dus het eindoordeel? Dit bepaal ik op mijn standaard manier: Weet de auteur na het lezen van het boek mijn interesse voor het onderwerp te vergroten? Het antwoord hierop is volmondig ja. Big Data is zeker een trend om goed in de gaten te houden.

The misunderstanding of Dr. Royce

Posted on by

It’s the year 1970. Dr. Winston W. Royce, director at Lockheed Software Technology Centre decides to write a paper. The paper, Managing the development of large software systems, will become famous. This paper is the origin, the source, the root, of the waterfall model, although he never used the term. Someone in the American Department of Defence reads the paper, and voila a new standard is born; the DoD STD 2167. Adoption in the development world can be compared with a snow avalanche.

Back to the paper. Have you ever read it, or (even) want to read it? Chances are it’s a boring endless explanation of the greatness of the waterfall. WRONG!

It’s a very readable 11 pages thin paper with 10 figures. Royce starts with the basic blocks of the model; analysis followed by coding. Then he mentions;

“A more grandiose approach to software development is illustrated in figure 2. The analysis and coding steps are still in the picture, but are preceded by two levels of requirements analysis, are separated by a program design step, and are followed by a testing step.”

So far so good, this is the waterfall method. But then surprise, the first sentence of page 2 (!), we read;

“I believe in this concept, but the implementation described above is risky and invites failure.” Backed up with arguments, he continues with;

“In effect the development process has returned to the origin and one can expect up to 100-percent overrun in schedule and/or cost.”

What? Pardon? He’s not promoting the waterfall? …….Total silence…….please, open the hyperlink, read his paper.

The right to believe

Posted on by

The Ethics of Belief by William K. Clifford. A story from 1877.

A shipowner was about to send to sea an emigrant-ship. He knew that she was old, and not overwell built at the first; that she had seen many seas and climes, and often had needed repairs. Doubts had been suggested to him that possibly she was not seaworthy. These doubts preyed upon his mind, and made him unhappy; he thought that perhaps he ought to have her thoroughly overhauled and refitted, even though this should put him to great expense. Before the ship sailed, however, he succeeded in overcoming these melancholy reflections. He said to himself that she had gone safely through so many voyages and weathered so many storms that it was idle to suppose she would not come safely home from this trip also.

He would put his trust in Providence, which could hardly fail to protect all these unhappy families that were leaving their fatherland to seek for better times elsewhere. He would dismiss from his mind all ungenerous suspicions about the honesty of builders and contractors. In such ways he acquired a sincere and comfortable conviction that his vessel was thoroughly safe and seaworthy; he watched her departure with a light heart, and benevolent wishes for the success of the exiles in their strange new home that was to be; and he got his insurance-money when she went down in mid-ocean and told no tales. What shall we say of him? Surely this, that he was verily guilty of the death of those men. It is admitted that he did sincerely believe in the soundness of his ship; but the sincerity of his conviction can in no wise help him, because he had no right to believe on such evidence as was before him. He had acquired his belief not by honestly earning it in patient investigation, but by stifling his doubts. And although in the end he may have felt so sure about it that he could not think otherwise, yet inasmuch as he had knowingly and willingly worked himself into that frame of mind, he must be held responsible for it.

Let us alter the case a little, and suppose that the ship was not unsound after all; that she made her voyage safely, and many others after it. Will that diminish the guilt of her owner? Not one jot. When an action is once done, it is right or wrong for ever; no accidental failure of its good or evil fruits can possibly alter that. The man would not have been innocent, he would only have been not found out. The question of right or wrong has to do with the origin of his belief, not the matter of it; not what it was, but how he got it; not whether it turned out to be true or false, but whether he had a right to believe on such evidence as was before him.

Pretty good story!

Let’s fast forward the ethics of belief to your current IT project. Just imagine you are the Shipowner. Your role can be project manager, tester, programmer, or an analist. What evidence supports your project to make a safe voyage?

Simple as ABC……

Posted on by

I like well designed workshops. They give me positive energy. The most interesting part for me is where stakeholders discuss which features are included (and some thereby excluded) in next release. Sometimes you ‘just’ have to (gently) push them to make the prioritization. Easy, done it before.

Easy, that little word got me thinking. Thesaurus of easy; piece of cake, effortless, no problem, no sweat, simple as ABC, straightforward…hmmmmm……

I decided to put myself to the test, a.k.a ‘eat my own dog food‘. I love amazon.co.uk, and I guess the feeling is mutual. Over the years many books filled my bookcase. The test: I have to choose 3 of my precious books.

The long list;

My first reaction? No, these are ALL good books, all of them are such a good reads, I care about these books. Let’s just change the 3 into a 5, no that would be self-deception. It’s not necessary to lie to myself.

Whatever happens, Becoming a Technical Leader will make the top 3. I love that book, and it’s a signed copy. It must make the top 3. The Mythical Man Month. Does it needs an explanation? It’s Fred Brooks, is it the best software book ever written? Brooks makes it to the top 3. D-E-F-I-N-I-T-E-L-Y.

Lets pick the last book. We have……..Weinberg (2x), DeMarco & Lister (2x), Senge and Humphrey. Simple as ABC, no sweat??? Okay I can survive without Perfect Software, if I must, that book has helped me very well over the last few years. Waltzing with bears, such a great read from DeMarco & Lister (aren’t they all?). So many aha-moments in that little book on risk management. Quality Software Management (QMS) and the Fifth Discipline do cover the same subject (Systems thinking). Senge covers more theory, but QMS is applied to the software business. Both very well written. I choose QMS. Learned a lot from Humprey, it’s a classic. I’m going to regret it leaving these books behind.

What’s left? QMS and Peopleware. Two totally different subjects are covered in those books. That’s why I bought them! O no, my stomach doesn’t feel good, can’t believe it. I have to choose between QMS or Peopleware. Think! 4 hours later on this sunny afternoon.

I choose …..I choose………did I just bite one of my nails off?……… I choose……………..Peopleware. Argh….I left QMS behind, that hurts, feels like I have to make an apologise to Jerry. Let’s roundup.

The short list

  • Becoming a Technical Leader: An Organic Problem-Solving Approach
  • The Mythical Man Month and Other Essays on Software Engineering
  • Peopleware: Productive Projects & Teams 2nd Edition

Thank God it’s just an excersise! Next time I tell the project’s stakeholders I know it’s not easy.

Hudson Bay start

Posted on by

I like good stories, the Hudson Bay story is one of my favourites. Johanna Rothman tells this story in her excellent book Manage IT.

“The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600–1700s in north eastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away.

By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies—before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

The Hudson Bay start is applicable to our world of software. See it as mini-phase, iteration, or sprint in your project plan. It’s not a waste of time or resources! Just run a “Hello World” program through your whole development process in your organisation. You will learn a lot by doing this exercise.

How would you react to someone who says: Look we have a 12 – 18 months project, don’t expect me to spare a day doing a Hello World exercise. (slap!)