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.
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.
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
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.
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?
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.
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.”
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:
You should instead see your product like this:
Take an hour and go one step towards The Whole Product concept:
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.