Writing

This week I finally got started collecting some of my thought and ideas on product ownership in a scrum project in a more structured manor. Now I have the outline for a small text, which I'll publish here on my blog when I have something to show. I guess it will all add up to less than 100 pages, but you never know...

Having written training material for 15 years, it was harder than expected to get started. But again, I'm supposed to be off so a bit of slacking shouldn't be an issue. But then again, I know myself and I know that sweetness of a finish line. I would also be able to have something done before I'm taking the little guy on a small trip in the middle of December. Hey, why am I writing here when I should spend time on my booklet?

Scared or challenged?

Interesting film on the rapid changes of our and our kids reality (I haven't checked the actual numbers, but that's beside the point). Are you scared or do you see it as a challenge? The complete article can be found on Tyler Blain, thanks Scott!

Victory!

I fixed it!

It seems like the first installation of PC Suite failed but when I run remove program, the program was not removed. So when I reinstalled it, the error remained. But when I removed all the files manually and restarted the computer, I could complete the installation.

But the installation function of PC Suite is a shame for the industry and for Sony Ericsson. But I fixed it and that is what is most important right now.

Progress bars

Something that really amazes me is how progress bars are used in software. I might be getting old but a couple of years ago the progress bar showed progress. To get a visual image of how much of an installation has been completed and how much remains.

Now I think a progress bar says "no, you are imagining things, your computer is not dead".

The so called progess bar on the picture comes from PC Suite from Sony Ericsson, a program which I've come to love as much as I love ITunes. You know what I mean. The dialog box has this green thing and it doesn't say me anything. When it comes to the end it just starts over.

By the way, the text is in Swedish but what it does say is that there is an installation of drivers and that this will take a few minutes. The dialog box cannot be closed in the mean time. Well, I've tried this a couple of times and after an hour, I've given up and been forced to end the computer processes. This solution smells. I thought Sony Ericsson could do better. A solution which demands that everything goes right and there is no options for failure is a failure in itself. As an excellent programmer on my previous team said: a solution cannot be measured by how well it handles when the user confirms with 'yes', it is measured by how it can handle the 'no's'.

So what does the Sony Ericsson help say? The help on the web site is non existing and the help in the program.... Well, this seems to be the problem: I can't install it. And the support hasn´t getten back to me. So I guess my husband is going to read this and give it a try.

Back to Sony Ericsson

When buying a new private phone, I was leaving Windows Mobile behind. I've not used Sony Ericsson for about ten years and I was really wondering how fast I could come in to the different UI. Despite me trying to tap the screen, it went smoothly. Except two things: recurring calender events (I cannot understand how they've let those bugs get out in production) and the PC Suite, which I've not yet gotten to work. I'm now trying to reinstall the program, since the support hasen't gotten back to me with any kind of help. And the connectivity to the computer was something I really wanted. So, I'm not very satisfied with Sony Ericsson right now.

Gladly enough, I'm really happy with the actual phone after two not so lucky sessions with HTC Touch Dual and HTC Touch Cruise.

Employment retrospective

Today was my final, working, day at my current employer. I'll not be starting at my new position until January 14th, even if I'm spending half a day at Fritidsresor in december, so I'll really have some time to think back and have my own retrospective. I'm going to follow my favorite five exercises for the Agile Retrospective book. The objective is to learn what I should try to improve at my new position.

So, now I'm just going to relax for a couple of weeks and then I'm doing a bit of research to prepare for my coming position. Well, I've already started! Me and the son is heading for Gran Canaria for a week's fun in the sun. And I'm collecting some domain knowledge too.

Agile the reward, not the method

Some people failing following a diet says 'the diet does not work'. But most of them does not mean that if you follow the diet, they still does not loose weight. What they mean is that they cannot follow the diet.

Reading James Shore's excellent blog entry on the decline and fall of agile, I get the same feeling. When teams pick stuff from an agile methodology like scrum and call themselves a scrum team and it does not work they do not say "we couldn't follow the methodology" since it's easier to say the methodology does not work.

Here is a teaser (and perhaps now you see the parallells with diets):

These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff--the stuff that's really Agile--they're setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won't last.

The blog entry is really recommended to you, thinking about going agile, or thinking about dropping agile.

Precisly wrong or roughly right

When attending the Product Owner Class, Mike Cohn gave the reasons for estimations being given using story points and in a relative scale.

The reason is that an estimation should be roughly right rather than exactly wrong. If you give an estimation which is 350 hours, the risk for this not being the exact answer is great. But to say something is about twice as big as X, that is a completely different ball game.

This also applies to other areas than estimation of development work. How about a map. The picture is of an add for google map in the NY sub. The problem is that the map shows the wrong location.

The ultimate team

Have you ever felt there is someone missing on your team? Well, look at this scrum team who have found the missing role in scrum

The world just got a bit bigger

Take a good look at the image and that little spot. It's one of the first published images of a real planet, in another solar system.

First when I looked at the image I thought, well. What the... But then again. It's a planet. A planet. Somehow the world just became bigger. And smaller. At the same time

Lectures by Jim Collins in MP3 format

Getting the links to my previous post I found this little treasure at Jim Collins site: lectures by Collins on different subjects. So fill up your MP3-player!

http://www.jimcollins.com/hall/index.html

At least it was not my fault

From Good to great is a book I often recommend. It goes to the root of an organisation and discusses some basic traits which gives ground for a successful business. And one of the basic rules is the type of leader the organisation has. Collins boils it down to the guy who looks in the mirror for the reason for failures and out the window for the reason for success.

But this is of course not just true for company bosses: it's an interesting trait for all of us, as Uncle Bob points out in his interesting post on scrumdrels. So who are you going to blame next time?

A true leader

The word/title mom is quite interesting for me, being a mother of a boy of four. He uses the word in two ways. First, we have the vague "a mom" which he uses for every woman collecting their child at daycare or mothers of friends. Then we have the more passionatly used "my mom", which he uses when he talks about our special relationship. This is an honourary title he has granted my. I'm his special mommy.

Today, while reading an article on leadership, I sense the same dual use of these titles stating that someone is a bit up in an hierarchy. There are the use of the printed word on someone's business card and then it's how a person can be seen as something. The most obvious example is Leader. Look at this list, being traits of what Peter Scholtes thinks is a leader:

1. The ability to think in terms of systems, and knowing how to lead systems.
2. The ability to understand the variability of work in planning an problem solving
3. Understanding how we learn, develop and improve. Leading true learning and improvement.
4. Understanding people and why they behave as they do.
5. Understanding the interdependence and interaction between systems, variation, learning and human behavior. Knowing how each affects the other.
6. Giving visions, meaning, direction and focus to the organization.

Isn't this good traits for a mommy too? Or a daddy?

A good idea

Why make life complicated? Why choose the difficult solution?

We can laugh at the advice in the add but professionally, how often do we choose to swim in alligator infested water when we don't have to?

Sometimes when we choose between two options, one can be the alligator infested water. It can be obvious from start but there are also water which becomes alligator infested if you continue swimming for a while. Unmaintainable or untestable code are examples of this. The hardest choice is of course when you have to choose between the alligators and the sharks. And then you just have to pick your fight.

Reading list

Stumbled upon this page on kanban! My reading list for the winter!

http://availagility.wordpress.com/kanban/

Cost Value Curve

Reading about Kanban, I've stumbled on this nice article on scrum and kanban in gaming industry by Clinton Keith. I know that the gaming industry is very different from other software industries, but since the author is very good at pointing this out and stressing the specifics of his industry, it's not a problem. So, it's a very good article, which I recommend.

But I did react to this simple diagram. It states that you come to a breaking point where added costs don't add so much more value to the customer. I believe that it is somewhat true, but there is a greater challenge to the product owner than just spotting the breaking point. All costs are not created equally.

Que?

No, what I mean is that if you have a functionality X with the requirements A, B, C and D which for just simplicity reasons are as costly, they probably do not add equally value to the customer. It might be that D is what makes it all worth it - for the actual user. I've often seen projects where the thing that makes it all worth while is cut. "Now we've spent enough on X so D have to wait".

And more often than not D is not the most costly feature. More often it's the feature the less vocal user identifies but does not stress enough. And not seldom it's the stuff you hear responses like "well, they'll get used to that" or "it's a learning issue" from someone who does not understand why this is important. And it's often the stuff that when you do implement it is hardly noted since it is taken for granted. So we return to expected behaviour. D is the stuff which makes X have an expected behaviour.

So how do you work this? Well, one method used by for example Mike Cohn is that when you calculate business value you don't just calculate how much value a feature introduce, you also calculate how much it costs when it's not included. D might not bring so much business value but it costs a lot if it's not implemented. I think this is one of the best methods to give room to usability issues. For more on this subject I recommend Agile Estimating and Planning by Cohn.

A manual

Not having written a handbook or educational material for many years, starting up with a manual was hard. My final effort at my current position will be giving ground for a user manual.

But my first question was: which space does user documentation have during an agile project, for example if you're using scrum?

I believe it is important to include the people formulating the user manual in the team and the user manual should be part of the iteration increment. And the reason is this:

1. You have failed a product increment if there is no useable software delivered.
2. You have failed a product increment if the result cannot be used by the users.

And how can the users find the new stuff and how do they know how to use it without documentation. Of course you have the delivery notes but should a user collect all the delivery notes and try to find their way?

I'm currently thinking about the best form for a user manual in an agile project. One solution is of course a wiki: just add new pages and specify which version this applies to. Or something. But how does this work in an offline setting? For example, technicians in the fields. And not everyone loves reading on the screen: they like something to hold. Otherwise there wouldn't be so many books on for example Microsoft Word. As with everything else in an agile project you need to go back to the users and their user stories: which process do they want to follow when they get updated or learn about the application?

So, I'll be doing a classic Microsoft Word document with pictures and lists. And I'll continue thinking about how to deliver user manuals in agile projects.

90 years

As I wrote earlier, it is today 90 years since cease fire of World War I.

Reading the news today, it is obvious that this haven't made the headline news. World war II is much more interesting to the general public.

Wars never makes sense but perhaps the reasons for WW1 are harder to understand for the general public. When I read about WW1 during High School they talked about the shooting in Sarajevo, but how could that result in a world affecting war?

I see similarities with the recent Balkan wars - it was really hard to grasp what the real reason was. WWII had Hitler to blame but there is no clear villain in the Balkan Wars or WW1. And we love stories when you know who the bad guy is. In these other wars everyone seemed bad or good at different occasions. And we don't like that.

Perhaps it all boils down to how effective the winners were writing history: the allied during WWII made a lot of effort making it clear that they were the good guys after the war ended Probably the increased tension between the winners made this important. I don't know.

But I still recommend each and every one reading something on WW1. Being a Swede, I have the fortune to be able to read the Swedish historian Peter Englund's brilliant book.

Playing by the rules

It is easy to fall into the belief that you on the development team believe that the business people are far off in their priorities. "How can they think that X is important"? Well, as I discussed earlier, they have to live with the decision. And this is why you have a product backlog: the users can see what they get and what they don't get if they prioritizes in a certain way.

And what if you are wrong: their priorities suck. They have to live with that. It is a good thing if you, if you do not share their views, share your opinion. They might not have seen the stuff you see. Or perhaps you learn something: why the stuff they want is prioritized.

But don't fall in the pit that Andre Luiz fell into. I don't know what he did. I don't know if the referee made a faulty decision. Even if André didn't earn that yellow card, what everyone will remember is that he failed to understand the most fundamental rule of soccer: the referee is always right. He makes the decisions and you have to live with them. You can give your views, but it's the referee's call.

Charrette

By chance, I stumpled on the term charette, and thought about the need for including charettes in software development projects. A charette is, according to Wikipedia, is an 'intense period of design'. The wikipedia article is interesting, again the similarities between software and urban development are many.

And so with the term charette: it describes a very creative and positive phase but it can also have another meaning:

'Historically, the term charrette also has been applied to the cart or tumbril used to carry the condemned to the guillotine.'

So, what becomes of your creative phases: do they evolve into magical software or do they make way to project death?

A historic moment

It happened just a few days ago. Windows 3.x died. You might have thought that Windows 3.x met the Gods years ago but until November 1st, Windows 3.x survived in some imbedded systems. For example on air planes.

Being an old Mac gal, the transition to Windows was hard, and there is still some kind of sorrow and feeling of loss. But why? What I felt as a Mac user was that the people making the user interface had the user in mind when they thought of ideas. They were not just thinking usability but predictability. Then, that you ejected the floppy by putting it in the trash and some other stuff wasn't that easy on my poor users. Or that the computer icon was on the desktop, but the stuff you saved on the desktop was saved on the computer. Strange.

Involving users

Getting users involved is hard. They don't appreciate what you have done. They ask for more. They say stuff you do not understand and make demands that make no sense.

Is that so? well, they are paying that cool stuff back at your home. And the shirt on you back. The food you put in your mouth.

The problem is that the longer you wait getting them involved, the problems described in the first sentence just becomes more severe. The gap between you and the user just becomes wider with each thing you build. And the frustration goes both ways: when you feel that they don't appreciate what you do they think you don't listen to them since the stuff you built wasn't what they wanted. Or more often: you're somewhat right but missed something really important.

I get amazed watching developers standing having long discussions on a functionality, using terms like "well, they want it this way" without involving an actual user. Well, if they are really far away or cannot be reached, this is of course acceptable. But when they are not further than the next room, it is showing disrespect. You're just coding stuff: they are the ones that have to live with it. So, if you're having this kind of discussion and it takes more than ten minutes, go grab yourself a real user. And not the type that don't use the product but just talks about it in a conference room.

Tranquility

Is there something better than waking up early a Saturday morning at a hotel in Karlskrona? The guys are sleeping so you go for a run around Trossö, an outpost to the Baltic sea. It's kind of frosty outside and the sun is just coming up from the sea and meeting the yellow sky.

The silence is breath taking. The view is splendid. The run is wonderful.

Coming back, everyone's still a sleep.

A quick shower. An empty breakfast area with just the stuff you like.

A nice breakfast by the open fire, slow jazz playing on low volume and a new book on WW1.

Isn't it amazing how wonderful the small treats can be.

Taking for granted

Since I'm leaving my current position, the product owner hat has been passed to another person and I have the chance to view the role from the outside. And this gives some new insight.

First: a product owner should never take for granted that he understand how other prioritizes or what other think is important. Especially a product owner who lacks actual business experience. It is so easy to believe that something is probably not that important and ignore it. But this is one of the worst errors you can do. The reasons are mainly two: first, you do not know and the only way to know is to ask - before you cut the stuff which do do not believe is important. Second: if you cut something stating it is not important without checking with the people who do know, you will loose their faith in you. It is easy to loose someones trust and rebuilding trust is very hard.

I think the core trait is thinking that you use the word 'believe' instead of 'know'. It is one thing to believe that something is not important, another to know something is not important. And the only way to move from believing to knowing is communication and getting knowledge. And don't forget that thinking agile is realizing that you never know, you just get less uncertain.

Why believe in gnomes when there is a magnetic portal between the sun and earth

Mother nature is amazing. This article from Nasa proves that you don't have to believe in God or gnomes or fairies or mystical non traceable electric fields to live in an amazing world.

Star Trek, here we come!

Patterns and practices Acceptance testing

Got a tip from Richard Fennell that a beta on Patterns and practices for acceptance testing is to be released on Codeplex.

Sure read for yours truly! According to Fennell it will include several methods for acceptance testing, both working agile and waterfall. The download includes a table of content for you interested folks