When the objective change

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?

Posted via email from forss’s posterous

Being clubbed by information

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?
   

Posted via email from forss’s posterous

The power of will power

Failing a project is never fun but in the case of my projects, they don’t result in death. Projects such as climbing Mount Everest most often result in death if they fail at the wrong moment of the project. If there is a storm and you’re near the summit, it’s a sure death. Or is it?

In this amazing film, Ken Kamler tells the amazing story of will power and how a person came back from death. But it’s also about making hard decisions and facing reality.

The power of the human mind and the human will power should never be estimated. Yes, I’m a sucker for these stories and Beck Weather’s own account for the incident is going up on my reading list.

But another reflection is that if will power can bring life and survival, bring project success; what happens in the case the will power is directed towards project failure? Do you have someone who really don’t want your project to succeed in your team? What will his will power do to your project?

A risk with verbal discussions?

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…

Posted via email from forss’s posterous

The risks of using quotations

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.

Posted via email from forss’s posterous

How do you know if your sprint delivery will fail?

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

Posted via email from forss’s posterous

Why am I even surprised anymore?

As nobody probably missed, my trust in Lotus Notes is below the freezing point. The quality is so low, the usability is a sad story and having used Outlook with Exchange, the lack of basic functionality in e-mail and calendar functionality amazes me. I shouldn’t be surprised anymore, but still….

 

Lotus Notes has two passwords, one for the Windows client and one for the web client. Today, I wanted to change the password for the web client. I looked in the horror story of Lotus Notes preferences and found nothing. Finally, I looked in the help section and I couldn’t believe my eyes. This is how you do it:

 

To change your Internet password manually, enter the URL for a Web application and add “?changepassword” after the database name at the end of the URL. For example, http://serverName.acme.com/databasename.nsf?changepassword.

In the Change Password screen, enter your old Internet password, enter a new Internet password, and then confirm your new Internet password by entering it again in the corresponding fields. The password quality guidelines are the same as the Lotus Notes password guidelines.

Click Submit.

Are they crazy? I couldn’t find that you could change the settings using the Windows client, perhaps you can, but in that case the help section does not include the correct information which is really bad. But I don’t know if that is worse than leaving the suggested solution the only one for us poor Lotus Notes users.

 

 

Posted via email from forss’s posterous

Carried away by numbers

I'm currently evaluating the result of a project completed before I started working for TUI Nordic. I'm going through objectives documents, requirement lists, budgets, time schedules and business cases trying to find out if the project was a success or not.

Since many of the people have moved on to other projects, it almost feel like I'm doing historic research and that is perhaps a curse of the movern project culture within software development. A project is planned, born, lives but dies when it's completed. Completed projects are almost like old newspapers. They are so dead.

But when I entered this project graveyard, I found myself consumed by these numbers and ideas from the not so distant past. I dug into the numbers, crunching them, comparing, trying to find the answer to my question. I had to stop myself many times, drawing conclusions from incomplete data. Our minds are hard wired to draw conclusions and see patterns, even when there aren't any.

It is all to easy to just take two numbers and draw conclusions, make calculations, etc. In a way it's easier to make these calculations than not to.

So, is the project a success? Well, I've not completed my review but my response will probably be that it depends. It depends on who you ask and which aspect you look at. When we talk about successful projects, it's easy getting stuck in Time, Quality/Features and Cost. But what about learnings? There are always stuff which works less than well in a large project but if you don't see that and act on it so you avoid it in the next project, that must be the greatest failure of all.

It's probably easier just to stick to the numbers and lists, comparing and calculating. But who said one must always pick the easy road?

Posted via email from forss’s posterous

The bliss of usability studies

Today, I and a colleague finished yet another round of usability studies. This time, we're not going for anything slightly scientific, but just another check-up among others.

The setup is easy, a semi-click able prototype, an open source screen capture program in the form of Cam Studio, a computer with two screens and we're ready to go. I select the users and my colleague has prepared a scenario. He explains for the user the scenario and watches him/her while I sit on the opposite of the table, taking notes and not interfering. As I mentioned, nothing fancy, but I really hope this will be an even more integrated part of our work from now on. Since we're using such light weight methods, we can test a little detail without it becoming expensive.

My colleague is a professional, while I'm not and that we have a professional on board is also so important. The small but important details in how he works makes a big difference on the result. Since I have a tester's and a computer trainer's experience, I can for myself see how I would approached this so differently and how much errors I would have done. I believe that my experience as a trainer and a tester helps me when discussing user experience and I probably stresses these questions more than other project managers, but differentiating between good and not so good solutions is better left to usability studies.

What does not cease to amaze me is how I can never in advance can see the greatest unclarities which the users identify. Of course there are always those areas in which you're struggling, but all those other spots where you haven't even thought there would be a problem, they pop up.

I just wish I started working like this many years ago… 

Posted via email from forss’s posterous

Who is to blame when quality is failing?

My blog post about my friend with the failing supplier resulted in one of my developer friends thinking that I was developer bashing. Not all customers want to pay for bug free software. And I agree. Most seasoned software users knows that there are always bugs in systems. The costs for those last 10% is higher than most of us are willing to pay so we find them in most software. Of course there is software where there's a 0 bug tolerance within for example aviation and medicine, but if we look aside from that my friend is correct.

But there is a big difference between small annoying bugs which is not spotted until you do something that is not easily expected and bugs which becomes apparent after just a few minutes of testing. It's a big difference between bugs which are annoying and bugs which makes the system not usable.

In the matrix we find these bug definitions. Most bugs are annoying and can be spotted using standard scenarios. That they are there is often no surprise to the team but priorities have resulted in them not being done. When I say annoying it could be that the bugs makes the system useless to one or a few users but it works for most users and that the main purpose in reached in spite of the bug. I would say that the annoying bugs which are only spotted using special scenarios are inevitable and also acceptable to most users.

When it comes to the bugs which makes the purpose of the system not being forfilled we have the bugs which are not easily spotted but anyway makes the system useless. These are the oops of the system. The things we hadn't thought of. These are costly to find and I think that in most cases customers can accept that this happens.

But what about the bugs which makes the system useless and can be spotted using standard scenarios? Many years ago Microsoft released a version of Microsoft Excel where the print functionality didn't work. Here we find the bugs which me and my friend where discussing. In his case, ll deliveries have bugs of this category.

So, who is responsible? I would say in principle the manager is responsible for the problem and if there was any bashing in my previous post it was management bashing. BUT the developers of the team should, if they had any pride in their work, should also feel a responsibility. I don't think it's about laziness, my experience is that these bugs are often a result of taking on too much and not making sure that no bugs in this quarters leaves one's desk because you're eager to start with the next task. Of course it happens to every developer that such bugs sneaks through the cracks and that's why we have testers. But if every delivery is infested by these bugs, this is more than just mistakes.

Posted via email from forss’s posterous