BBQ & Software improvements

Who would refuse an improvement? Don’t we just love magic wands, we wave them, and voila, instant better results. “You, you, you, you are now a team, good luck”. Or how about this one; let’s implement tool X, and make it a mandatory tool for everybody, that will surely improve our production. Yeah, like a tool will solve our problems…sigh. Jerry Weinberg mentioned this about tools; “Don’t kid yourself. Software users will find ways of not using software they don’t want to use”.

So how do we get better results? Forget about agile, scrum, lean, prince2, automation, etc. Try something easier: practice!

Let me use a hobby of mine as an example: BBQ. It takes great skill to master your BBQ. It takes countless hours of practicing. I’m sure you experienced a terrible bad BBQ meal; burned sate, dry chicken, tough steak, and a destroyed brisket. Most people struggle with their BBQ, because they don’t practice. So how do you practice with a BBQ? It’s so simple! Do a dry run. A dry run is a good practice to calibrate your BBQ, so you know what it is doing and how it reacts to changes (coal burn down, vent openings). No food needed, so it’s cheap, but the information value is high. Today I practice the low and slow cooking with the Snake Method, because I want to improve my skills.

Daniel Pink told us a little secret: People want to get better at what they do. It’s called Mastery. So let them practice.


Request for future bugs

Dear Mr and Mrs. Bug

Please follow our corporate standard procedure of finding you. It will nice if you “hide” somewhere close to a written specification. We especially look in those areas which we assume to have a high risk profile.

We would deeply appreciate your corporation to our request.

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

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.

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. 🙂

The Universal Pattern of Huge Software Losses.

On my way to the Change Artistry Workshop, September 2013, I read an interesting article:
The Universal Pattern of Huge Software Losses, by Jerry Weinberg, one of the hosts of this monumental workshop.

Let me share a small section of the article:

The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:
1. There is an existing system in operation and it is considered reliable and crucial to the operation.
2. A quick change to the system is desired, usually from very high in the organization.
3. The change is labelled “trivial.”
4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.
5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.
6. The change is put directly into the normal operations.
7. The individual effect of the change is small, so that nobody notices immediately.
8. This small effect is multiplied by many uses, producing a large consequence.

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management’s first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.
10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.
11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]
12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.
13. Higher managers are left untouched. After all, what could they have done?

The article amused me. A few weeks after the workshop, an email was send from our IT supplier to the Testing Department (I was in the cc).

Hi Frank,

Please find a list of known open incidents that could be fixed for the next repair release (I refer to bug tracking system IDs), together with our point of view regarding risks.

5791: Typos/translations -> impact = low risk, we will fix it.
5802: Sorting in the table on attribute. ->impact = also low risk (one line of code has to be changed)
5839: expanding of the list in the table view ->impact = low risk, consequence: the list will be scrolled to the top, please comment that!

5841: Appearance of “unknown error message”-> impact = none, already fixed in next version
5845: Comma between first name and last name -> impact = low risk, should be fixed
5846: Double click function does not work for certain objects. -> impact = low risk, should be fixed
5857: English error text ->impact = low risk, should be fixed
5859: Expanding of the list for the export filter -> impact = low risk
5863: view object in read-only mode -> impact = low risk (just one flag needs to be set correctly), should be fixed
5865: Rename the object window -> impact = low risk, of course 
5867: small error in standard calculation behaviour.. is that really a blocker?!? -> impact = anyway, risk seems to be low, but developer is on leave! Very quick decision required!!!

Best regards,


Hmmm…..I notice a pattern….. we just covered steps 1, 2, 3 en 4. Time is running out, but we still have some weeks to make sure we don’t end up in Jerry’s updated version form this article.

Change Artistry Poem

Change, oh no not again,
A volcano melts into a plain,
Change remains the same.

A(n) (im)perfect plan,
Results in blame,
Change, oh no not again.

We enter the theater of change,
Always knowing that,
Change remains the same.

We turn the sets and,
Raise our Change Artistry thunderbolts,
Change, oh no not again.

The change is poised to be sustained,
The chorus recite,
Change remains the same.

Change Artistry,
Helped us joyfully play this game,
Change, yes please
Change remains the same.


By Jean, Stuart, Ronald
Albuquerque, New Mexico
Change Artist Workshop