I’m still on vacation but am at least online after two offline weeks in Crete. The photo is by my husband, Hakan, b t w.

For me, reading is essential to the ultimate vacation, and this is no exception. I’ve tried to stay away from software development literature, but I was not totally successful. When you’re working with something, I guess every book is somehow related to the subject. So, my head is packed with new interesting topics for this coming fall. And I’m starting off with the subject of risk. Is a risky project/task worth it?

A basic principle of agile is to try to get as much business value for the least resources. This would mean that you would pick story A of the following user stories:

Story Cost Business value A 10 10 B 20 10 C 10 5

But what happens if you take risk into consideration?

Story Cost Business value Risk A 10 10 10 B 10 20 20 C 10 5 30

What would you pick? A safer story with less business value or a riskier one with higher potential?

My basic instinct tells me to pick story A, and I’ve also felt somehow that the agile principles are backing me up on this. But would happen if we always pick the less risky stuff?

In Blue Ocean Strategy, W C Kim and R Maubourgne describes the differences between a red ocean and and a blue ocean when it comes to competitive situations and businesses. The principle is described very well in the current (July 2010) Wikipedia article, so feel free to take a detour if you prefer before going back here. To summarize; the red ocean is a business where the competition is dense and you need to fight for your position. If you have found a blue ocean, you’re competitors cannot truly compete with you. Of course, most blue oceans are temporary, but the successful organizations find new blue oceans when their current ones turn red. But what has this to do with my product backlog?

The answer is the question, in some ways, but you could also call it Innovation. How can you find a blue ocean? Well, it’s probably not by deselecting all the high risk items, is it?

David Andersson also points to this in his brilliant Agile Management for Software Engineering. If you’re shy of innovation, you will never be able to implement lean and agile values in a long term successful way. Implementing The Theory Of Constraints require a successful selection of both risky and non risky items. He also points at the importance of measuring the right stuff when it comes to high risk things: if you only measure the factual outcome, people will become shy of innovation and only pick the sure wins. This is probably the best way to stay in a red ocean. (And if you have not yet gotten this book, be sure to read it.)

But what are risky projects, items, tasks? It is very important to know why they are risky? Is it a risky technology? Are we unsure of the potential income? Are there special circumstances in the current project? David Andersson points at the importance of knowing WHY something is risky, but not deselecting for example all tasks with high technological risks. I’ve for example worked with a client who only worked with old versions of tools in order to lower the risk. Yes, the risks were lower but he lost out on innovation. But I’ve also worked with clients who ran for all new technology and had to be one of the first on all new versions. This is of course not good either. Now we’re not talking about risky user stories: we’re talking about misplaced focus. We won’t find the blue oceans because of new technology, but it can help us get there.

So, when my vacation is over in about two weeks, I will look differently at risk. Is there a potential blue ocean hiding there or can I get over another constraint while handling it? But now I’m heading back to my vacation.

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.

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?

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.

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.

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.

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.

Take a good look at this guy. What, you didn’t know who he is? Of course: he’s pope Gregory XIII, who created the Gregorian calendar.

Here is some Wikipedia quotes about the calendar:

The Gregorian calendar is the internationally accepted civil calendar.[1][2][3] It was introduced by Pope Gregory XIII, after whom the calendar was named, by a decree signed on 24 February 1582, a papal bull known by its opening words Inter gravissimas.[4] The reformed calendar was adopted later that year by a handful of countries, with other countries adopting it over the following centuries. The need for the Gregorian reform stemmed from the fact that the Julian calendar system assumes a length for the mean tropical year of 365 days and 6 hours, when the correct value is 365 days 5 hours 48 minutes and 45 seconds. At the time of its introduction the actual date of the vernal equinox was imperfectly known. At the time of the reform the length of the mean tropical year was also imperfectly known. A 400 – year intercalary cycle was introduced which gives an average length for the calendar year which is 27 seconds too long. In the twentieth century Eastern European governments, on the advice of astronomers, introduced a version with a 900 – year intercalary cycle which gives an average length for the calendar year which is only two seconds too long.[5]

When implementing the calendar, 11 days were removed to get in line with the new calendar.

During Agila Sverige, Albin Rännar from Nordic Investor Services, besides from giving a very interesting speech on the death of the budget, explained some of the problems which evolved from the good pope’s new calendar.

If you just look at the description, it looks like a really good idea to reform the calendar. In other words, fix those bugs in the calendar.

But as Rännar pointed at: what about the short term effects? Let’s say that you had a contract with a contractor and according to this contract, you would deliver on July 14th. And then suddenly, there was no  July 14th. What then? And even if the actual date was not removed, you might loose 11 days during which you could complete the delivery.

Another person (sorry, but I don’t remember exactly who it was who told the story) then told us about another problem they had when they fixed bugs. Sometimes there was a bug which users used in their business and by fixing that bug, a business opportunity disappeared with the release and without any warning.

And this brings us back to the definition of a bug. For the poor contractor, the missing 11 days was a bug and for the customer losing his business opportunity removing that loop hole probably feels like a bug.

Sometimes fixing a bug feels like creating one, even if there are no regressions.

can be found here. Most of it is in Swedish, but some is actually readable to a non Swede too. For example

Flight of the Agile View more presentations from Agila Sverige.

If you understand Swedish, I must recommend this presentation on T-competence.

Kasta ut experterna och fokusera på helheten View more presentations from Agila Sverige.

The other day on Agila Sverige, we discussed agile in an environment where Operations have implemented ITIL. The discussion moved to why ITIL is implemented. Operations want a stable production environment and all changes are a risk to that environment. By keeping that gate and requiring all these artifacts, chances are greater that no one just install something which doesn’t work.

Since it was also Monty Python Day, I couldn’t help thinking about this wonderful sketch  and I cannot help but recognizing myself when I’ve tried to get something done. I ask for something and someone shoves a process artifact down my throat. You said what? What did I need to do?

But the next thought was inevitable. How many times have I’ve been that knight who said Nii! in the eyes of a user, wanting some new functionality.

What I said: “No, you will have to wait because there is no product backlog item and the sprint has already started. Get it registered before the next release planning meeting and we can estimate how many story points it will require”

Interpreted as: “No, I won’t let that pass because I want you to bring me a shrubbery before I’ll get it fixed.”

We have all gates and artifacts for a reason but in too many cases we don’t explain this enough or perhaps really know ourselves so instead we just babble out one (or many) of those process artifact names in the face of the one making that requirement.

And the second part of sketch is also so telling. When the stakeholder finally got all that documentation ready in the specified form or formed the requirements as a user story, the process has changed and now they have adapt to that. Imagine all users getting used to scrum vocabulary now having to grasp kanban…

We might all this for a good reason but it is important that it doesn’t feel like everyone need to cut down a tree with a herring too.

A lesson learned from Predictably Irrational is to test usability in the situation the customer will be in when he will be making that decision/using that system. If you ask a sober young student during a day time study if he would drive under the influence, you might get another answer if you ask that question to the same man, drunk as a skunk, leaving a party.

It is so easy to bring in users in a testing environment, turning off their phones, and making them test the system. They will not behave the same way when they are trying to get all the figures ready for the important meeting, already late to pick up the kids from daycare and with the phone ringing and the high pitched voiced colleague babbling at the next table.

You can just imagine what the product developer for these sandals thought about the ease with which you can put on those shoes. Dead simple.

Guy with Sandal Problem.

Most of us don’t want anything bad to happen to our kids. In order to keep them safe, we make choices which secure their safety and we set up rules and regulations to prevent those unsecure situations. If it can save the life of a child, we should of course do it. To be on the safe side. Or should we?

David Eberhard, a Swedish psychiatrist, describes in his book “I trygghetsnarkomanernas land” (In the safesideoholics land) he describes a time when everything should be on the safe side but also a time when teens get a psychosis when they are dumped for the first time, where the psychological health is on an all time low and when more and more people get burned out.

Eberhard does not buy the official reasons for this: that the pressure is so high today. He believes that the cocoon like state we put our kids in are ruining their chances to learn how to cope with risks, failures, pressure and sorrow. So, when they are finally in a  risky situation they don’t recognize it (since they are used to everything being safe) and when they are faced with a sad situation, they panic. Our “On the safe side” mentally are killing their possibility to live life to its fullest.

The social pressure is also a factor: we talk negatively about the parent who lets her kids cross the street on themselves and these stories are great headline news. It’s better to follow the crowd. To be on the safe side.

I recognize the situation all too well. I have friends who’ve brought their kids to the E.R. for symptoms I would say points to a common cold. Not just once, but many times, and still they continue this habit even if they keep coming back with the same conclusions from the doctors. To us other parents they say: well, it was perhaps not anything dangerous this time but you want to be sure when it’s your kids, don’t you? I don’t know how many times I have had to bite my tongue: No, I don’t think it’s OK to waste precious E.R medics time. And no, I don’t think it’s OK to spoil the weekend for that kid, having to spend yet another day in the waiting room. And I don’t think it’s OK that really sick people get to wait even longer because of this.

What is really sad about Eberhard’s conclusions are though that he thinks that the main concern of these parents are not the kid, but themselves. No parents can forgive themselves if they did something (or didn’t do something) which caused harm to their kids. In other words: we are afraid of the feeling which we would cause ourselves if something happens.

Sometimes while reading this book, I started to think about all these projects out there. All these efforts to introduce agile values in software development. Yes, it’s probably sick to think about that all the time, but I couldn’t help but see the consequences in my work situation.

What happens when the failure afraid, security manic safesideoholic parent come to work and get to plan that project? What does he feel about an agile approach, when he don’t get an estimate in hours but in story points? When he cannot see which date which functionality is delivered a year in advance?

No wonder that many thinks that the traditional waterfall approach is nice and comfortable. It feels great to wait with starting the development to after we have that thick pre study. We have really done everything to get to the bottom with this problem. If they project goes south, no one can say that we didn’t analyze the problem before we got started.

And what are the consequences for the project and the project group? Well, if you’re into agile values, you probably have an idea about this not giving ground for the most innovative development.

In one of my projects, one of the lead developers asked me for a flow chart, describing the things we’re building. Far from the scrum product backlog, yes, but I decided to give it a try.

I downloaded XMind, a free software with a PRO version with really useful functions, but since I’m just testing the concept as a product owner, I decided to test the free version.

The result, many hours later, is a number of connected flow charts which all looks something like this:

I started with setting up the basic flow chart, and identified the main steps. All these main steps were given their own page in the workflow workbook and then I started drilling down. I looked at all steps and identified which functions I wanted to be available from that step and if there were any special scenarios. To help me out, I have the work from our user interface designer, so all I had to do was translate his work into this flowchart and identify these special scenarios. Well, “all I had to do” is perhaps to simplify the task. I will not hide that it was hard and sometimes gruesome work. For each step I covered, I identified more special cases which I need to find solutions for.

But after a while I got to really like this approach. I focused on one step at the time. Took a good look at that step and tried to think about if I’d really seen all the ways to which one could come to that step and I tried so see which steps were possible from there. The nice little note functionality made it possible to add all those special scenarios and questions.

In a couple of hours I had documented all those discussions we’d had in the project group and I would say that what we have is a number of user stories, but in another format. I can better see the links between stories, and it’s easier to track what the story applies to, without having to write too many X:s under “As a X” if I’d used the user story format.

Also, the diagram does something that user story cards don’t: it puts the story in a context. Yes, a user story does say why we do the story, but it does not show what happens next and what we take for granted has happened before.

So, what about the output? There is a HTML export function which exports not only the image but also the comments and pictures.

WHat about the next step? the next step is to see if the developers like it or not. And if they do, we have to find a way to build using this. But the first step is to see if this is the way to go. What do you think?

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.