Archive for February, 2010

The objective of a pre study

2010/02/25 1 comment
I'm currently planning a pre study. You agile guys out there probably freeze when I say that word: pre study. Seems like a load of waste, or?

Why a pre study? Why not make it an implementation project right away?

I was also struggling with this and it all boiled down to me trying to understand the Commander's intent of a pre study. I'm writing a project description to our project review group and I always try to use Commander's intent. Commander's intent is (for you who have not read all my posts and for which this is old news) is a way of stating an objective. The format forces you to say what the essence of the problem is. "Independent of all other things, we should have achieved X." This means that even if all plans goes south you know what the purpose is. It's a military term and the effects on US military are enormous.

So, what is the commander's intent of a pre study. Normally, I don't have problems writing (one of my biggest problems is that I write too much), but now even I was struggling. What can be the objective of a project which does not produce anything which you can use. It's just paper. Or?

If we go to the scientific method, we talk about observation, hypothesis, theory and fact. In common day language we might not view these terms as so different and you sometime hear people say "well, that's just a theory." In the scientific language it's not that easy. Here are the Wikipedia explanations:

Observation is either an activity of a living being (such as a human), consisting of receiving knowledge of the outside world through the senses, or the recording of data using scientific instruments.

A hypothesis (from Greek ὑπόθεσις; plural hypotheses) is a proposed explanation for an observable phenomenon.

A theory, in the scientific sense of the word, is an analytic structure designed to explain a set of empirical observations.

In the most basic sense, a scientific fact is an objective and verifiable observation; in contrast with a hypothesis or theory, which is intended to explain or interpret facts

What does this mean? Well, in many cases, someone observe something and based on that form a hypothesis. When this has been tested and verified using the scientific method, you can form a theory. When a theory has been proven right beyond any reasonable doubt, you can say that it's a scientific fact.

But what does this have to do with my prestudy? You could say that we have observed a problem. But we don't know if it's a fact that we're going to do about or even if we're going to do something about it. We don't have a solid theory about what we're going to do. In other words, we couldn't formulate a commander's intent for the implementation project.

Starting projects without a commander's intent is seldom successful and here we have the usage of pre studies. They can give us a better understanding what the problem really is. This does not mean that all pre studies are good. Too many result in Gantt charts and details but fail to supply the one important thing and that is to give meaning to implementation.

I will probably not write that the purpose of the pre study is to form a commander's intent but if you remove all the extra words, this will be the bottom line.

Categories: Agile

When you hope you hadn’t been right

2010/02/24 1 comment
In a previous post, I discussed how it can be painful to learn that you were wrong. As a project manager, you probably don't like to learn that your assumptions proved wrong and that you need to make new plans.

But sometimes it's painful to be right too. Software developers are often in this situation. They try to explain why something is harder than expected, the risks of a solution or how uncertain an estimate is. When they then are proven right, they often have to pay the price for making things right afterwards too. A not so sweet victory, if you don't take pleasure in proving others wrong, that is.

The other day, I had one of these sour victories. I wish I hadn't been right. I've been discussing a project with a friend of mine and she was so optimistic about a new system which they were implementing but I saw some troublesome risks in the user interface. We discussed this very openly and she accepted that if the problems would be factual, the project would be in serious problems and a large investment would be lost. As she is a professional project manager, she decided not to hide the problems to her customer, and she invited me to her customer for an informal lunch. The customer was informed about the risks and was asked if he would accept a total failure if my opinion on the user interface was shared by the user. I guess this is not the most normal situation because the customer listened, reflected and said that he would take the chance of risking this large investment. It would be acceptable to give the solution and try and if it was rejected by the users, then that would mean the end of the solution and bye-bye to money spent.

A couple of days ago, my friend called me. The system had now been in use for a couple of months and besides the draw-backs I had identified, the users had found even more and they are not willing to continue using the system. The customer, true to his word, has accepted this and will now go searching for another solution. He's not happy of course, but he knows he had the decision before things got really expensive and he's not shying away from responsibility.

I've been reflecting on this these last few days. I really wanted to be proven wrong this time. The project manager and the customer is really great people. I cannot really point to a specific error in the process. They were agile during the development producing solid deliveries every two week sprint, the quality was good and the leadership was probably better than average. And still everything ended up a failure. The problems in the user interface was such that you might not spot them during a demo or just using the system for a couple of days. It was more the long term use which made the problems evident. I only spotted the risks by having worked with similar systems in the past and had seen these problems then.

But there is a sort of happy end to the story and that is of course the next step. The customer is standing by his word. His users won't have to settle with a faulty solution and he's now using these findings in search of something better. A great leader takes responsibility and moves forward.

Categories: Agile

Pain is temporary, planning lasts forever

2010/02/22 1 comment

Do you know who this guy is?


His name was Trofim Lysenko and he was the father of vernalization. He thought he could make wheat cold- and humidity tolerant by exposing it to this the same way you can learn a person tolerate pain by exposing him to it. It might seem like evolution but the difference is that evolution does not act on the current generation; it affects future generations by making the tolerant strains more common.

Lysenko make farmers plant soaked seeds in frozen lands. The result was a disaster. The yield did not triple as Lysenko had promised and instead it decreased or ceased.

This would have been the end to this story hadn’t it been for a number of sad coincidences. We are in Stalin times and land. So, even if the plan failed and people died by the millions, the practice did not only stay but grew all over the Soviet Union. It was not until the 1960’s that the Soviet Union lifted the ban on genetics and slowly started turning away from vernilization. The cost in human lives is incomprehensible but we’re talking about millions of individuals, starving to death. So, what went wrong?

Well, if we for a second ignore the guy with the huge mustache and just look at Lysenko and his crew, I would claim that the problem was not the idea. Yes, it proved wrong, but having wild ideas is not a problem. The problem was that they stuck to the plan even if it obviously did not work.

Realizing that you are wrong is often painful. Depending on your pride, it can be very painful but if you’re a sane person this pain should subside. This pain is temporary.

If you instead use the scientific approach and keep on planning, keep on evaluating, if you stay agile, you can exchange that pain with the joy of succeeding.

I don’t know if Lysenko realized that he was wrong. He died in 1976, and I find it hard to believe that he never in the deepest roots of his heart did not realize that he had been wrong. One or two of the guys on his team must have wondered, anyway. And still, it took so many decades before actions were taken.

In software development, we project managers often find ourselves in Lysenko’s shoes, having made the wrong assumption about a problem or a plan. And we need to face the fact that we were wrong. We need to meet our stakeholders explaining the new plan and the new hypothesis. The pain will not be lesser if we wait. Just look at Lysenko, how many find it OK that this continued for so long?

Hence, Pain Is Temporary, Planning lasts forever.

The saying is of course also a game with another famous saying from Lance Armstrong. The original is “Pain is temporary, quitting lasts forever”. And if you stop planning, if you stop acting on changes and new input; you have quitted your responsibility. The project manager who keeps holding on to the failing plan is quitting his responsible as a manager and becomes an administrator. I guess he’s not as bad as Lysenko, but most of us aren’t working for Stalin.

Categories: Agile, Leadership, planning

Losing faith

Just before we went on our winter vacation to Thailand in November, I
purchased a camcorder. I’m not usually the one in our family who wants
new technical stuff but I wanted this.

After some careful thinking I stuck with our usual brand, Canon. As I
said to my husband in the store – I just wanted it to work.

It was not a cheap thing, it was a bit more expensive than I had
calculated, but the good film quality, the possibility of extra lamp
made it a done deal.

I’ve seldom been as disappointed. Not with the features as such. The
films are brilliant, but the UI is an insult to a customer. The
camcorder is OK but it’s the PC software which is ugly, almost
impossible to use and filled with misspellings.

In an earlier post, I discussed the clean and bare UI as a strategy
for a specific type of user. This is not the case here. The UI and the
so called “user manual” has gravely affected my view on the Canon
brand. In other words, this has made me lose faith in the Canon brand.

And as all that once lost faith knows, regaining faith is hard, almost
impossible. What is interesting is that it was not the product in
itself but the experience that failed.

If you take pride in your product, you take pride in the experience.
The people struggling to realize the wonderful film quality should be
mad by the bare thought that their effort is bundled with such low
quality manuals and software.

I’ve now filed a ticket at canon helpdesk. It will be interesting to
see if this will make me at least an agnostic again

Categories: Agile

How to write a good principle or objective

2010/02/19 2 comments

Have you ever seen objectives or principles which are something like this:

“Our solutions are future safe, uses the best of technology and is easily integrated with our other systems”.


Sounds well, doesn’t it? My former college professor once said that a valid objective is one that someone could rewrite so the aim was the opposite and someone could also see that as a valid objective. So, “future safe solutions” is not a valid objective since no one would ever want a solutions which wasn’t future safe. An objective is only interesting if it helps us make decisions and these type of “happy” objectives are therefore in principle useless.

So, how do you avoid these useless objectives? How do we formulate them so they give meaning and direction? There are probably many ways, but here are some favorites from the agile dame in Enskede, Stockholm:

N is better than M

Why does the agile manifesto help us? Well, because it tells us something about the relative priority. If I get to choose between following the process and interacting with people, I choose the people. Since someone could say that process is more important than the human (and sometimes this is true, for example in aviation regulations you have to follow the procedure), this is a valid objective also given my professor’s definition. But this is only if someone could be standing selecting between N and M.

Commander’s intent

The Commander’s intent is used in US military and according the the principle you should always in a sentence say “Independent of how everything else goes, we should have achieved X”. This also gives a relative priority. X is more important than anything else there is. This would mean that if we said future safe is the commander’s intent, that should be reached independent of other priorities.

The pronounceable sentence

It’s too common that an objective is formulated in a long, complicated sentence which you have to read many many times before it becomes clear. These objectives are written like law text but cannot be part of everyday life. So, write your objective so anyone can remember it. Both commander’s intents and N better than M objectives can and should meet this criteria too.

Better missing one objective than all

What are the chances that you would remember if you had one, and just one objective? What would they be if you had 100? We sometimes try to cover everything in our objectives so we write too many.

In 7 habits, we talk about 3 wildly important objectives. That is probably a limit. One of the projects I’ve been struggling with for a couple of months now have three objectives and that is too many. It gets confusing. Better focus on one.

Write it down

Do you think that everyone knows the objective(s)? You don’t have to write it down? You’re wrong. Write it down and post it on the team wall. When the guys look up, it should be the first thing they see.


One final insight. I love concrete stuff. When it gets fluffy and lots of words, I loose focus. But don’t mistake abstract with not concrete. Just look at Nike’s brilliant logo. Just do it! Isn’t that just a wonderful objective which can give you guidance when you’re wondering if you should really run in that cold rain?


Categories: 7 habits, Agile, Leadership

Survival of the fittest does not mean designing the smartest of solutions

2010/02/17 1 comment

Having followed my husband’s, Anders Hesselbom’s and Marcus Ahnve’s discussion about the evolution saying of “survival of the fittest” and it’s baring on software development, I want to clarify some misunderstandings concerning “survival of the fittest”.

Many believe that survival of the fittest equals the winning of the best solution. The best and the strongest survives the competition. But that is not what survival of the fittest mean in software development.

Look at the vagus nerve in a human. It starts up in the brain, goes down under the aortic arch and then back up to the throat. Is this the most elegant possible solution to building that nerve? No, only an idiot would design the nerve like this if he started from scratch. A person on which the nerve goes directly would probably be considered as better or stronger. If you consider that the same type of problem of the rerouted nerve exists in for example giraffes, you can see the extent of the problem.


So, what is survival of the fittest? When the ancestors way back in time lacked our long necks, one or a number of individuals mutated so that their necks became slightly longer. The nerve became a tiny bit longer too, but the upside of the longer neck was bigger, so the group with the neck survived long enough to reproduce in greater amount than those without it. And step by step, the necks became longer. The side effect of the elongated nerve was always a lesser disadvantage than the longer neck. Of course, after many generations we had that absurd situation we find today, but the chance that a mutation surfaced where the nerve was instead directly routed and the rerouting was successful is very slim. And since the nerve as is does not result in an enough big disadvantage in reproduction, the design remains.

If you’re a software developer, close your eyes and relax. Then think about which system and which code the solution of the vagus nerve remind you off. Is it that neat and beautiful solution you’re so proud of? Well, I hope not. It is probably some kind of legacy code or legacy system. It was probably a good solution way back, when someone made a quick and dirty solution to a simple problem. The solution was just temporary, but remained and steadily became a bigger and bigger headache.

What you really would want is to cut that nerve, rebuild it in a smarter and more future safe way. But your manager might not see it as a problem. It works, doesn’t it? Which are the risks with cutting the nerve? Are you sure that we will survive and that things will be better afterwards?

Evolution is The Greatest Show on Earth. Wonderful to see, amazing when it comes to giving birth to amazing solutions, but don’t be so sure that you have the nicest and best design.

Categories: Agile, Architecture, lean

The myth of multi tasking

Sometimes I wish there was something like the show The Mythbusters which handled all the myths in project management and software development. First on my wish list would be multi tasking – they perception of feeling productive. Here are some new research results from Stanford University, shared by the Heath Brothers.

This is a multi tasker:

“They’re suckers for irrelevancy,” said communication Professor Clifford Nass, one of the researchers whose findings are published in the Aug. 24 edition of the Proceedings of the National Academy of Sciences. “Everything distracts them.”

Categories: Agile