Archive

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.

Posted via email from forss’s posterous

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

Posted via email from forss’s posterous

Categories: Agile

Pain is temporary, planning lasts forever

2010/02/22 1 comment

Do you know who this guy is?

image

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

Posted via email from forss’s posterous

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

Yes.

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?

image

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.

image

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

Posted via email from forss’s posterous

Categories: Agile

Experience is the product

2010/02/14 1 comment

Having started my career as a consultant, I’m always a consultant. My users are my customers and that is how they are treated. Like customers. Does not mean that I’m their slave, but they should be treated by respect and my main purpose is to bring business value, through the business people.

But also having worked for a product company, everything I work with is regarded as a product. Our web sites are products which our users consume. In this wonderful presentation, Peter Merholtz describes the importance of Experience of a product.

When you might see your product like this:

image

You should instead see your product like this:

 

image image

Take an hour and go one step towards The Whole Product concept:

Categories: Business

How a clown can teach you to use your full potential

When we were on vacation this winter, we often viewed the evening entertainment for kids. My son loves slapstick and clowns and he immediate became very involved, acting out. Just like the entertainers of a kids show wants. But the other children kept seated and after a couple of minutes, my son realized that he was the only one dancing. So, he sat down like the rest.This is not uncommon in the workplace. There are almost always those who act out, using their full potential. But if they realize that they are the only ones working hard, there is a big risk that they stop working so hard, quit their job or that they try to make up for the others, burning themselves out.

An important job for a manager is to spot this and act on it. The sole high performer is not a long term solution. In most cases, the management is responsible for this situation. If people are not using their full potential, there is a big chance is that this is because management is failing. Sure, there are always slackers, but I believe most slackers are created by unclear and bad management.

In the case of Peter’s entertainers, they realized that their show didn’t work. By leaving the stage and getting more involved with the kids, soon most of them were up on their feet dancing. Peter included.

Peter as the only child engaged in the entertainment was a crisis and so is staff getting burned out at work.

As discussed in Jim Collins research (presented in for example From Good to Great), lean literature as The Goal and Our Icebergs are melting, you can tell a lot about a company ho it handles crisis and distress. One example is of course current problems like downsizing and burned out staff. If management and the organization has problems handling these situations, they will probably be poor in handling success to. In an article in Connecticut post, former Morgan Stanley and Charles Schwab manager Mike Stallard and researcher Lisa Stafford give us a shortlist on how to handle and not to handle these situations. They point to that in the time of downsizing, many managers focus on getting rid of the unwanted and thinks that the remaining staff will be motivated by feeling lucky to still have a job. But they don’t feel like they’re in control of the situation and that stops them from working their full potential. The clown at our resort could have kept up his act, blaming the kids for being a bore. But that is a bad entertainer.

These are the advice from Mike Stallard concerning managers in the situation of staff burnouts and cut backs:

– Engage Employees — Make employees aware of your expectations, address their concerns and relate to them on a personal level. This can help build trust and loyalty, improve communication and create a more positive work environment.

– Motivate Employees — Recognize and reward employees for their accomplishments and contributions. This will show that you care about them and their work and will provide greater incentive for completing tasks.

– Give Employees More Control — If employees have a problem, engage them in a solution. Give them more choices in their job (even if it is a small choice, employees are more likely to feel positive about their work).

– Don’t Be Afraid to Have Fun — Allow employees to socialize and have fun in the workplace. Employers might consider throwing a birthday party or barbecue to improve workplace relations and relieve tension.

– Be Transparent About Downsizing — If layoffs are being considered, keep employees in the loop by providing a timeline and discussing the health of the company. This will help to dispel rumors and anxieties, which often serve as distractions.

What I’m a bit afraid about in Stallard’s list is that he don’t stress that you cannot just do one of the points. I’ve too many times seen management focusing on one of the points on the list, thinking that they are doing something. The most pathetic example was the manager who thought that his jovial way would bring motivation. Instead, he just made the sensible people de motivated since they didn’t feel in control of their situation. Fun is simply not enough for the serious worker.

What is telling from the story of Peter and the children’s entertainment is how this spread. In this first evening, he was the sole dancer in front of the stage. Later that evening, when the clown had changed his act, four kids were engaged. The next evening, some other kids had seen the previous act from a distance and now they turned up too. The number of engaged children increased every night. When you see others using their full potential, you also get motivated.

Posted via email from forss’s posterous

Categories: Agile

A sure way to project failure

When I'm planning for a upcoming project, I use Microsoft Project for estimating costs and to make a rough plan for when we could expect to be done. I make a rough estimate of what need to do and then estimate which people are necessary and how much time it would take to get a result. Yes, I know it sounds dangerously close to waterfall, but this is to learn if this is a one million SEK project or 5. Are we finished by this summer or Christmas?

But what happens is that when I see the result, an immediate thought is "This cannot be. It cannot take this much time and it cannot cost all this money."

And here lies a sure way to project failure and that is to act on that question and start cutting so that it doesn't feel that awful.

But it's better if it feels awful before you start, that you are amazed by the costs upfront instead of wondering why you couldn't keep that budget. If you're in the middle of a project and feel the budget is slipping; ask yourself if you cut corners in the budget even before you started working. Building software is amazingly expensive and take so much time.

Posted via email from forss’s posterous

Categories: Agile