Archive for June, 2010

And so they lived happily ever after…

We all heard those fairytale stories in our childhood. The basic setup was almost always the same: A happy start, then the heroes had to fight some evil foes just to end up winning the show “and so they lived happily ever after”.

Most of us grow up and learn that the real hardship is not in that initial challenge, to cross that first victory line: the challenge is to stay that successful.

But somehow, in the world of project management, it sometimes feels like we still believe in fairies and magic. We still think that the challenge is to bring the project to an end and everyone that stands in the way is an evil troll or witch. “They keep changing their mind” “The requirements they write is not good enough” “Operations are not taking responsibility”.

Two weeks ago, the crown princess of Sweden finally tied the knot and this almost felt like that old story again but we are wise to listen to the words of the new HRH Daniel of Sweden.

We all, like HRH Daniel, know that when the happy end has been passed, the real work starts. The real work is the every day struggle to keep everyone as happy as they were on that happy project launch. Independent of if you’re working with princesses or just your average everyday user.

Categories: Agile, Leadership

Agile writing?

2010/06/10 2 comments

It’s kind of interesting that it’s so hard to stick to agile values. As I’m writing this, I’m trying to complete a huge report which I’m going to finish before the summer.

So, did I stick with an agile approach or did I go Waterfall? What do you think?

I started with setting the format templates: headings and text styles. Then I moved over to writing which headlines the document would hold. Then I started writing the first chapter, slowly progressing chapter by chapter. As is, the report is truly Work In Progress. Would I drop dead tomorrow, the first chapters are completed but the rest is just a bunch of headlines. The areas which I’ve covered can be read, but you would not get an overview of the complete subject.

But would it be more agile if I wrote something under each chapter? It would still be work in progress because then no part of the subject would have been completely covered and there would be huge room for misunderstanding under each chapter.

So, what is? Can you write using an agile approach and how do you do it? And would it bring any value?

Categories: Agile

Usability test in a non lab environment?

2010/06/09 1 comment

There are so many ways you can test usability and perform usability studies. I guess there is no final solution to how you should test your system: you probably need many tools and many types of studies but last week, we tested a study outside the lab environment.

A good thing about AB-testing and tools which record users while using the system is that you don’t test stuff in a lab environment. Normally, when you interview users you set up a meeting, invite them to a silent room and turn off the phones. The user can then test the system without being disturbed from the outside. But this is not how he will use the system. Then, the phones will be ringing and the deadline has been missed. This is when you see the tripple clicks.

With automated systems, you can see the more realistic usage but then you miss out on the face to face communication in the study. You cannot ask for details and sense the feelings from the participants.

So, in an effort to combine these types of studies, we performed a usability study in the environment in which our users reside. In a home, with kids running around. This will not be the sole test but will be one part of our usability studies.

But does the situation matter? Of course it does! As Dan Ariely found in this study, we make different choices and hold different values depending on the situation.

Categories: Usability

Requirements Specification or Overview

Today, I had a meeting during which one of my current projects were discussed. One of the participants asked me about the requirements specification. And my response was: we don’t have one; we’re trying to working with an agile approach. The response to this was quick – agile is not an excuse not to document. But I never said we don’t document.

For me, specification is not a positive word. If you consider the word “Law”, a picture can be the law book, and the book worm, preferring reading and reciting rather than meeting others. Here I find the word specification.


But the word “Law” can also have another side, illustrated by the following picture, when you way stuff. There is seldom a right and a false side. We just have to find the most fair way to view things. Here there are no specifications, but rather an idea, discussions and a general impression of what we want more off and what we need less off. Could you call it a requirements overview? I guess there is no correct word. My discussion partner asked if we instead had a backlog, but that term does not catch what I’m after.


We have mission statements, flowcharts, prototypes and user stories which describes what experience we want for the users. If you want to call that a specification, you may, but I need a better word which does not bring that book worm picture to my mind.

Categories: Agile, planning


First of all, as you might have already understood: we’re moving into the summer season and my blogging will probably be less frequent. The garden needs some constant handling. It’s almost like handling technical debt: you think that you’ve fixed something but next time you go back you can see that the weed has already started growing.

But I need to tell the story of Endurance. Sometimes the truth is so much amazing than real life and in which case is this more telling than the story of Endurance.

Imagine it’s 1914. WWI has just started. You are heading to the south pole to cross the continent on foot. Crazy is just the Christian name but this was Ernest Schackleton and this was the age of exploration. Almost like the IT bubble era but instead of building strange web sites people went to distant areas of the world. In both cases a lot of money was lost but the age of exploration also resulted in many lives lost in the Arctic ice.

Schackleton and his crew took their ship to the Antarctic but got caught in the ice and had to spend the Arctic winter on their boats. This was a amazing thing in itself but it was nothing compared to what was to come.

You might have thought that the summer would bring bliz but when it became warmer, the ice broke and with it, the ship broke too. So now they were on the ice, with just small boats. Far from everywhere. And no; there were no IPhones.

From Wikipedia: The end of Endurance and some time on the ice

Finally, after many hardship, they reached Elephant island, but this was an uninhabited island and they were 1300 kilometers open sea from habited land. They only had small life boats and winter was closing in again. It was an open sea trip in the worst conditions in the world. Add to this; they had survived on the ice for many months with almost no supplies.

Ernest Schackleton did not cross the Antarctic, but he gave us this amazing story and showed some traits which are desirable for any project manager. I will not here tell the end to the story but as you might have guessed, there were survivors.

So, which were the traits? I recommend you reading the book yourselves, but I would like to point out some interesting findings which I found especially intriguing:

  1. Endurance. This was the name of one of the ships, but also an important trait. Schackleton would not accept failure and death.
  2. Change of objectives when the objective became unreachable. Schackleton changed the objective when he couldn’t reach the goals. Instead of giving up, he picked the next important thing.
  3. No sentiment when it came to priorities. When it stood between death and a valued item, Schackleton picked what ever would keep them alive. But he also realized that social aspects were also important. A banjo and a deck of cards were kept while almost everything else got discarded since these items were important for the social knitting and to keep off boredom.
  4. Same rules applied to managers. When Schackleton told the guys that they needed to throw away everything, he pulled out a bible which he had received from the queen. He tore out the page with her dedication and threw away the rest, stating that only what could not be shed was to be shed.
  5. No hiding from possible conflicts. Schackleton identified trouble makers and depressed party members and took them into his own tent. He felt it was better that he could keep and eye on these than that they would poison everyone.

The day and age of the great explorers ended almost 100 years ago, but these traits with a leader seem endless.

Categories: Leadership

Cutting features or processes

The other week, I was participating in a process modeling workshop. We’ve been struggling a bit with project scope and objective, but now I think we’re getting there by focusing on cutting processes rather than cutting features.

In most projects I’ve been involved in, we’ve cut features. I’ve actually been part of two projects in which we added features, but this is as you all know not the normal scenario. When it comes near the project end, the ax is produced and we start cutting trees.


Or in some cases, we take out the lawn mover instead, making everything smaller.


But what is often the case is that the cut feature has some perhaps unexpected consequences. By cutting feature A, feature B and C becomes pretty useless, since they depend on feature A. Or if you use the mover, slimming everything down makes a lot of things useless since they don’t take the reality’s complexity into consideration.

But if you instead clarify the processes, you can see these dependencies and  cut processes instead. This in many cases means that you instead of cutting one feature, cut more. This is more like closing off a road.


It also becomes easier to communicate to stakeholders: what processes we should support and which processes are not supported. This does not make it easier. People never like their stuff being cut.


Categories: Agile, Modelling, planning