Hold on to your hats folks. Something of a miracle just happened. Almost like a virgin birth. So, sit down and just listen. We've just started using Lotus Traveler on our company phones. I just followed the instructions, synchonized and it actually worked. I almost fell off my chair. I can still not believe it. I used Lotus Notes for something and it actually worked. Yes, the user interface does not follow the standard, it looks ugly and it's not very intuitive, but it worked.

But isn't this tragic? When the users take failure for granted. I tested this and never thought it would work.

I've seen systems where the customers hated upgrades. Yes, they wanted the new features but knew the system would be down after the upgrade. This should not be acceptable.

What does your users anticipate from your next release? Fear, suffering and bugs or a newer and better system? And no, the new features do not make up for the system being down.

Here the ultimate question can help. After each release, ask your real users (those affected by the new system - users and system administrators) if they would recommend you as a supplier after each release. No, you shouldn't just ask them but give them a means to register this anonymously. Share the result with the developers and the managers so it becomes transparent when a delivery does more harm than good.

Just thinking that the customers should be pleased by the new features and not to mad about the system failures is not a long term good way to treat a customer you want to keep.

So, why don't you ask that question? what are you afraid of?

My husband pointed me the other day to a web site, dedicated to The Theory of Constraints and today I happened to stumble upon the page on Dead Horse Strategy.

Here is an extract:

Dakota tribal wisdom says that when you discover you’re riding a dead horse, the best strategy is to dismount.  However in business we often try other strategies with dead horses, including the following;

Buy a stronger whip.

Change riders.

Threaten the horse with termination.

Say things like, “This is the way we have always ridden this horse.”

Appoint a committee to study the horse.

What is your organization's "dead horse"?

Sometimes, you just know you're right. But sometimes that does not mean that the other guy is wrong. You might both be right.

See this short but mindblowing presentation - Ted, as always!

http://www.ted.com/talks/derek_sivers_weird_or_just_different.html

When I close my eyes and think about "a pre study", I cannot help seeing a picture of a tedious, text file, filled with a lot of requirements. In other words, a document.

It is no wonder that I went into my current pre study with some mixed feelings. But there are pre studies and there are pre studies. A pre study can be exchanging of ideas. I see it as the famous words about plans and planning.

"In preparing for battle, I have always found that plans are useless, but planning is indispensable."
–General Dwight D. Eisenhower

You could say the same about pre studies: the process is indispensable but the document is pretty useless.

In the generic picture, the big pre study is also followed by the big implementation project but what I really like about this pre study is that we focus on both quick fixes and long term solutions. Since representatives from our development department participate in all the discussions, the pre study has already resulted in changes. Some things that users thought needed development was already doable and other things have just required small changes. And what feels better than coming home from a workshop and a week later, some of your most important issues have already been solved.

Sometimes you cannot help wondering how you´ve become who you are.

This evening, I´m on the train towards Lund in south of Sweden to meet
with a possible supplier. So, I have two hours of time available.

Great, I thought. Finally time to read W E Demings. So here I´m
reading a book called The New Economics for Industry, Government and
Education. Voluntarily. How did this happen... And even more
facinating; I enjoy the reading too.

But I guess that if I was one of all these young students around me, I
wouldn´t have had an idea of what he was talking about. This is one of
the books you wish students would read but you realize they have no
possibility to understand before they have worked for a number of
years. And to be frank, not all seasoned workers would understand it
either. Not that the language is difficult. It might be dry, but
clearly understandle. if you know what problem he´s covering. So, what
is about¿ It´s about Deming´s view on management for a long term
successful organization, an organization for which success does not
only happen but is created, maintained and improve.

Many of us has management as a part of work. It can be a school, team,
student group, company or a family. Deming does not let us place blame
on anything or anyone else but management. On all levels.

I will get back with examples, but remember that this a book which is
difficult to take the time to read, is easy to read but is hard to
understand if you as a part of your management style rely on ranking,
blaming and adoration of oneself. To be that manager though, is a life
long project. Now, back to reading

In an earlier post, I published a link to a film concerning the biggest catastrophe in modern day Mount Everest climbing history and this is an amazing story of will power. But there are also other learnings.

What happened to the objective?

The climbers all went up there with a clear and obvious objective. For one reason or the other, they wanted to reach the top of the world. But in an instance, as an effect of outside aspects, the objective changed to something completely differently. Instead of reaching the top, people just wanted to survive and in some cases, the objective changed again. Faced with the fact that he was going to die, one of the climbers just wanted to talk one more time with his pregnant wife.

In this case, it was obvious that the objective had changed, and I guess everyone switched objectives. But in most projects, it's not that easy. Objectives can be elusive, changing and moving. And in many cases, the objective has changed without us even noticing it. In many cases, the objective has changed for some of the team members, while some are still struggling towards the old objective.

When we talk agile, it's easy to just concentrate on the relative priority of different stories. We move stuff up and down on the list, but sometimes we really need to look at that top objective and really think if that is really what we want now and if that is what we're really struggling to reach.

But it's also not good if you change objectives too often. In one of my projects, we're struggling with the objective. It felt very clear from start but the main objective has changed a couple of times over time. That is not good. But it's a lesser evil than continue struggling towards something that is not very important anymore.

Anyone else who is struggling with changing objectives?

During my college years, I was active in student organizations. The students who were active were so well educated and brought tons of arguments for their cause. The effect was long, tedious, information packed discussions and meetings. One of the years when I attended the yearly National Student Union's meeting, I got sick about two a clock in the night. I rushed to the hospital, and after getting treatment, I could return two hours later. Since I was kind of agitated, I couldn't go to sleep so I went back to the meeting. They were not discussing the same sentence as when I had left, but had just discussed two more sentences. It was crazy.

When I later became a board member for this national organization, one of the board members really stood out. She wanted to strike everything we wrote. Her standard request when we were discussing any text was to strike every sentence. Since everyone else wanted to add new sentences, I asked her about her strategy. She said that she wanted all sentences and all words to bring unique value to a text and that if you add one superfluous word, that will decrease the value of the rest of the text. I had never thought of it like that, but her words were an eye opener and I've tried practicing her ideas ever since. Do tell a story, but don't pack it with unnecessary details.

Many think the more details and information, the better the decision will be. But I don't think that is true. When superfluous details are flooding us, we make bad decisions and try to put value to this information which brings no value. Our brains are hard wired to see patterns and make thing intelligible. Many times this is a blessing but in our information packed world, it can be devastating. My high school math teacher used this many times to make his assignments more challenging. By adding details which were unnecessary to solve problems, he made them harder to crack.

Research also backs up that unnecessary information makes our decision making harder. In Wisdom of the Crowds, James Surowiecki points to a study performed by Jack Treynor. He asked college students to guess how many beans there were in a jar. The mean guess was 871 when there was 850 beans in the jar. A really good guess, in other words. But when Treynor added the information that the jar was of glass, the mean guess was  off by 15%. The jar was of glass, so he didn't provide with any false information, but he clogged up the student's minds.

We see and hear patterns. And we give meaning to  things that does not have meaning. This is also illustrated in an episode on reverse speak on Skeptoid.

The journal Science published an article in 1981 by Remez, Rubin, Pisoni, and Carrell called Speech perception without traditional speech cues. By playing what they called a "three-tone sinusoidal replica", or a complicated sine wave sound, they found that people were able to perceive speech, when in fact there were no traditional speech sounds present in the signal. So rather than laughing at a reverse speech advocate, instead appreciate the fact that there is good science driving their perception of what they're hearing. They're not making anything up, they're just unaware of the natural explanation for their phenomenon.

Here is one amazing example. Listen to it. It does sounds like words, doesn't? But when you've heard this, and then listen to the first sound file, it sounds even more like words.

So, when you're making a presentation or participate in a discussion: how often do you add superfluous details? Let every slide, picture and word fight for their right to exist. Ask yourself if it adds meaning or simply detract dito. Did the blog picture make the story more intelligible?
   

I'm a sucker for informal, IRL meetings and discussions and decision making.

But there are risks too. When you rise a question with someone, you're probably place great value in the question and the answer. But what if the person you're talking to? Is he just semi concentrated? How big are the risks that he, the minute you leave the meeting, rushes to the next question and meeting, not remembering the question and not paying so much attention to the decision or even that he made a decision.

I fell into this trap last week, which lead to a lot of confusion and unnecessary heat.

But as I now reflect on the incident, I must say that the problem is not the verbal discussion or the verbal decision making. I really think that had we had the conversion using e-mail, more attention might not have been placed to the question. Many probably read and answer more e-mails than they have verbal discussions during a normal work day. The only difference I think is that if you use e-mail, you have some proof of the conversation. But how would that help with the real problem? And what is the real problem anyway?

Gotta think about this a little bit more...

I guess there are few people reading this blog who don't recognize the guy on the picture. Einstein was not only one of the brightest ever; he's a true icon. But he's also probably one of the people who has been misunderstood and mis quoted the most. When I say mis quoted I don't only mean that people falsely state that Einstein has said something. We also have the situations where his quotations are used in the wrong context and as an alternative to true arguments.

I'm here especially thinking about the more vague quotations, which does not directly refer to specific numbers or research, but those nice oneliners which build up quotation databases.

Direct misquotations
When it comes to the direct misquotations we for example have "No amount of experimentation can ever prove me right; a single experiment can prove me wrong". This quotation is discussed in the Swedish skeptic organization VoF latest number of Folkvett by Sven Ove Hansson. The quotation is today used by climate skeptics but when Hansson tracked the quotation, it became clear that the sources does not point to Einstein ever stating this. Well, of course he might, but there is no preserved evidence for this and the source from which the quotation derive, points to a text where Einstein says no such thing.

Quotations out of context
It's all relative. If there is a statement which is pinned to Einstein this is probably it. But it's important to remember that he was talking about the laws of physics and his theories. He was not talking about health issues, history descriptions and morale. You can therefore not use his quotation as an argument for these areas.

Quotations instead of arguments
This is too often used in combination with direct misquotations and quotations out of context. In a debate, someone is pressed for arguments, validating a claim, but instead of giving this, a person present a quotation from someone else.

Today, we're debating the best practices in agile software development. Scrum or Kanban? Lean software development or not? XP or RUP? These discussions too often fall back to quotations made by the big guys like Mike Cohn, Jeff Sutherland, Mary Poppendieck, Ken Schwaber. We should all be weary for falling into quotation traps out there. Also, we have another risk, which was not as evident in the times of Albert Einstein. We have the more ad hoc publications and blogs. I've been blogging for a couple of years now and much of the stuff I wrote in the beginning, I now believe to be false, simplifications or irrelevant. Perhaps I should delete those blog posts. Perhaps I should go over them, entering comments stating my current viewpoint. But I won't; for me, the blog is almost like journal, giving my current state of mind. Changing the blog posts afterwards would almost feel like changing the historic documentation. I'm very proud of that I've changed my mind over the years and I would be ashamed if I hadn't. But this does not mean that I would want anyone to use those old texts as the sole arguments in a discussion. As a complement to your own arguments, a quotation from someone else can help building your case, but a generic quotation is not an argument in itself.

Sometimes software development feels like when I doing gymnastics in my youth. Just like the boy on the picture, you start your pace slowly, carefully. You know where the finish line is. Then you start to wobble. Trying to keep yourself up, you increase the speed, hoping that you will make it to the other side. Often you didn't and fell down. Other times you barely made it, just to crash on the other side.

To some, this happened sometimes, to others it happened over and over again. Somehow, the repetition did not help in the learning process.

Another example is from when I was taking my driver's license. Here in Sweden you must complete training on icy roads. The teacher used a very clear method. We were instructed to go around the course a number of times. The first time we were told to keep a specific speed, 30 km/hours. Everyone made it. Then he told us to go 50 km/h. No one made it. And then he told us to change whatever we thought suitable to ensure that we would complete the course. 20 out of 21 students decreased the speed and made it. One kept up the speed and of course he didn't make it. As he could see the speed of all the other drivers, one would guess that he would understand but when he was given the chance to again change anything to complete the course, he didn't change the speed and was again the only one not to complete the course.

I really hope that guy never got his license but we all know those guys are out there, those who just speed up, crashes and never learn. And when those guys are into software development, there are failed releases.

Change This is a wonderful little site, dedicated to change and one of the manifests discusses product launches but it can as easily be applied to any software development delivery. There are some handy rules out there and what I like most is the integration of outside stakeholders. In the manifesto, salespeople are mentioned but they can as easily be anyone caring for the software on which they depend. Happy reading.

http://changethis.com/manifesto/issue/68.05.ProductLaunch#view