The software version of: The Emperor’s New Clothes

People like to hear stories. So do I, stories can give insight to a problem from a different perspective. Recently I saw a parallel between a great story and the world of software. The story is about the Emperor’s New Clothes. Here is the short version of the story.

Many years ago there was an Emperor so exceedingly fond of new clothes that he spent all his money on being well dressed. Two weavers (the swindlers) offer to create a special set of clothes for the emperor. They tell the emperor and his followers that the clothes are invisible to people who are too stupid for their jobs. No one can see the clothing, but no one wants to admit this fact because they do not want to be identified as foolish.

“I’d like to know how those weavers are getting on with the cloth,” the Emperor thought after a while, but he felt slightly uncomfortable when he remembered that those who were unfit for their position would not be able to see the fabric. So he sends in his most trusted men to verify the progress of the weavers. None of them can see the clothes, but none did say so.

Well we all know how the story ends.  The little boy said at last, “but he has nothing on at all”.

So how does this work in our software world? First of all, remember that software (and progress) can be invisible like the clothes of the emperor. The development team can use all kinds of excuses. We can’t (will) show you the software right now because;

  • We haven’t integrated the latest module yet.
  • We haven’t tested the software yet, and don’t want you to run into all kinds of bugs.
  • We have no data in the system. This is planned for next week/month/year.
  • We are currently understaffed due to <some excuse>.
  • The configuration isn’t up to date in the test environment.
  • That’s normal in a <huge amount> dollar project.
  • We never show the software to our clients until the promised release date.

This can happen. Perhaps in the early stage of a software development project. Time flies. Now you have send your most trusted men to verify progress. Are you sure they return with the truth?

When do you need a little boy to reveal the truth about your project? (Will you even recognize the little boy?)

Microsoft fixes ’19-year-old’ bug

IBM researchers discovered the flaw, which affects Windows and Office products, in May this year – but worked with Microsoft to fix the problem before going public.

The bug had been present in every version of Windows since 95, IBM said. Attackers could exploit the bug to remotely control a PC, and so users are being urged to download updates.” (BBC, 12 November, http://www.bbc.com/news/technology-30019976)

Wow, fixing a critical bug in the software that had existed for 19 years. 19 years!

I can’t even estimate the amount of testing hours Microsoft did over the years, 19 years it took them to find this bug. According to IBM the bug had been “sitting in plain sight”. (how rude to hide in plain sight)

So this happened to Microsoft, could it happen to all of us? Missing a bug, missing a critical bug for 19 years? Even if you test the software, you asked those testers to test “all” didn’t you? Making a decision to release the software with that bug?

Yes.

Yes it happens all the time, because we seem to forget/ignore the fact that testing is sampling. There is no way you can test 100% of your software product. You don’t have the time and money to do it. Sure you are testing “risk based” perhaps even in an agile environment.  It is no guarantee you find all your critical bugs.

Microsoft just reminded me of the lesson that you never know all the information about the quality of the product at the time you need it. I’ll apply this lesson next time I hear some saying “I’m done with the testing”.

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.

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

Hans Teeuwen on Agilists

I just finished reading a blog about “religious wars” between different Agile schools of thought. Interesting short article, which ends with to striking sentences: (1) Do our customers really care, and (2) it is about the results. True.

Hans Teeuwen (Dutch comedian) would probably say the following about this religious discussion: “It strikes me that Agilists often have a tendency to claim to have the monopoly on the truth.

Both got me thinking about Jerry’s  Rule of Three, which says; “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.” Replacing the word plans to solution (i.e. Agile) still makes the Rule of Three valid.

Let’s keep Agile a good practice and not the “best practice”. Let’s focus on the results.

 

 

 

Quality vs. Speed Simulation; a Project Management Retrospective

When asked the pressing question: “How does a project get to be a year late?” Frederick P. Brooks, Jr. (The Mythical Man-Month, 1975) gave the sobering answer, “One day at a time”. More often than not, projects seem to have to deal with small planning setbacks on an everyday basis. A conference hall has been double-booked, your programmer has suffered more than was expected from the after-effects of a visit to the dentist, the server you ordered has accidentally been left behind in the mail room, a seemingly simple hotfix hasn’t worked. The result is that projects often find there are not enough man-days in a month. According to Frederick Brooks, one of the major reasons for this is that schedules are drawn up under the assumption that everything will go according to plan. But isn’t it so that projects by definition do not run as planned? (Frederick Brooks doesn’t put it in these exact words, but he does give a guarantee of sorts that projects will not go as planned.)

Bearing this wisdom in mind, I put to myself the question of what unscheduled incidents we had encountered in our Quality vs. Speed Simulation (originally thought up by Gerald M. Weinberg). I decided to make a list. The list was meant to help me in drawing up schedules in the future.

The simulation was focused on the quality vs. speed (time2market) dilemma. Small teams competed against each other for the highest possible product score. The product score was determined by the number of bugs that remained in the product and by the remaining budget. The teams did not know the quality of the product in advance. The difficult questions the teams faced included: To what extent and how often do we want to assess the quality of the product (testing)? What price do we want to pay to raise the quality of the product (fixing)? With what (estimated) quality should we launch the product on the market?

Several unscheduled incidents

1. The team consisting of myself, Tom Breur and Ronald Damhof knew one another but had never facilitated this simulation together. A try-out was needed. The combination of full diaries, available space and the availability of the participants made this an impossible mission in the short term. Ronald Damhof had to spend several weeks in the US but luckily Tom Breur’s son Tim was able to come to the rescue.

2. The simulation consisted of an element that required two marbles of different colours. We didn’t have those resources. For us, the days of playing marbles in the playground lay in the dim, distant past and, unfortunately, that also applied to the ranges on offer in toy shops. Online shopping seemed to be the solution but sadly the marbles we ordered never arrived in the Netherlands. Buying in a considerable number of bags of M&M’s resolved the problem.

3. Another major element in the simulation was (Monopoly) money. We had invited quite a lot of people and they ALL turned out to be present! That meant we didn’t have enough money. Who could ever have assumed that everyone who had promised to come, would actually turn up? The consequence was that we quite literally had only had two minutes to print off extra money.

4. The idea was for Tom and Tim to direct the simulation, and that I would try and learn as much as possible as an observer. A well-thought-through plan. Reality proved less compliant. Tom and Tim were running their legs off and I wasn’t able to be with all three groups at once, which meant I couldn’t properly observe the dynamic of each group. We’ll do that differently next time.

5. The try-out took place in a time box of two hours. The most common complaint immediately after the end was: “We want to play the game again!” Maybe so, but there was no more time. Gerald Weinberg’s statement “quality is value to some person at some time that matters” (Quality Software Management, 1992) ran through our minds. Fortunately, in the days that followed we received lots of positive feedback from the participants. If you want to obtain different (read: better) results, you definitely shouldn’t keep doing the same thing. The lessons learned from the try-out were written down. We made some adjustments and concluded, with satisfaction, that we had become much wiser.

6. December 2012, it was winter in the Netherlands. The cold and snow had the country in their grip. Indoors, the heating was on high in the simulation room where the (three-hour long) morning session had started. The simulation was going well and we had not yet been confronted by the relationship between a high room temperature and chocolate M&M’s. However, once the afternoon session was underway, we soon became familiar with the natural phenomenon of melting. A considerable number of M&M’s got broken, and soon, alongside our red and yellow M&M’s, we were also using orange ones in the random samples. Fortunately, everyone was able to see the funny side.

7. We added an extra game element to expand the complexity of the simulation. In the middle of the room we set up a table with pens, paper and calculators. These aids were literally there for the taking and, to our thinking, were very useful. No one, and I mean not one single person, used them.

Conclusions

Naturally, this is not a complete list of everything that ‘happened’ to us, but at least it gives you a picture. Time to take stock.

Even a relatively simple project like facilitating a workshop involves a degree of complexity that inevitably leads to surprises. You can design projects to succeed or to fail. Don’t let yourself be surprised by “an accumulation of setbacks”.

Test your plan early and frequently, and modify it if necessary. A pilot (try-out) or a Hudson Bay Start (Rothman, 2007) can provide you with fast and inexpensive insight into whether or not you will be successful. You don’t need to work in an ‘agile’ organisation to implement agile elements. It’s simply good sense to apply the agile principle of Fail Fast, Learn Fast.

Your ‘single point of failure’ (for example, M&M’s, an essential colleague) will fail during the project. Get rid of it.

And now it’s now time to reflect philosophically on the article. The Temple of Apollo at Delphi is said to have borne the inscription “Know Thyself”. Thank you BIPODIUM for giving me the opportunity to remind myself of lessons I have already learned!

Behind the Chinese Wall

Walls. Some problems crossed my mind.

Problem nr 1: noticing the wall.
Walls are high, especially the Chinese Wall variant, you might not even recognize it as a wall. Perhaps you are to close to the wall to even see it?

Problem nr 2: climbing the wall.
Walls…intended to protect something we (they) value…hmmm….we might benefit if only we know what it is that needs protection. Curiousity is required here.

We need a ladder, put it against our wall, and start climbing. It will not be an easy task, it can even be scared, and involves risks.

Problem nr 3: understanding the value behind the wall
We managed to get behind the wall. Applause, many before us never made it.

We see people, working hard, doing the best they can given certain constraints. But we don’t understand them, they seem to speak a different language. (“Weirdos”)

Let me share a secret: they are working is a similair “container” just like you.

Oh by the way, if you invest time to get to know them..guess what? You will benefit!

The correct answer to the question is

No, not 42. That would be the answer to the ultimate question of life, the Universe, and everything.

Worthwhile projects involves risks, they should. Risk-free projects are doubtful; you can question their value proposition. There must be a reason why they weren’t done long ago. Risks can materialize into problems. And some problems do have the potential (yes they do!) to let the project fail big time.

That raises the following question: when do you want to know your project is heading for trouble?

The only correct answer to the question is: as soon as possible. Duh! So why do so many projects fail at the end? #designyourproject2succeed, #feedbackloop