Imagine a sailing boat with four guys onboard. They are all franticly working to make it to harbor. But they don’t have a map and they don’t have a compass. Can you imagine this scene?

And yet, this situation is not that different from the situation in which many software development teams are in today. Independent of software development or project method, many teams lack one or many of the following:

• A map which shows where they are
• A map which shows where they are heading
• A GPS which shows how they are progressing

Some teams have these tools but don’t update them that often. I’ve worked with projects where developers reported once a month. You can just imagine how long it took to act on a problem…

In order to act, you need to have quick and accurate updates – what is sometimes more dangerous than a map is a map which shows the wrong location (of you or the target) and if the update is a week old, chances are great that you act on the wrong stuff.

Besides having status updated, you need to keep it visual: a GPS or map is of no good kept in the pocket. If you don’t see the problems, you will still miss out opportunities to act on problems and also; if the status is displayed for everyone to see; chances are bigger that people will update their stuff to avoid questions.

My husband is now working on a digital tool to visualize progress. It’s built as a WPF application and is now based on Team Foundation Server (to visualize work items) but hopefully he will also include support for other data sources.

This pet project of his is called Virtual WIP (you guys into TOC or lean will probably get the word game) is very interesting and I hope to be able to implement this in an upcoming project. I guess many of you prefer analog tools, but working in an international organization, I need visualization which works long distance.

http://hakanforss.spaces.live.com/blog/cns!27CCB0417E50BA2/

His building of this application has gotten me (and him of course) thinking a lot about what you need in order to get us what sailors get from their maps and GPS:s. What would you need? If you have ideas, post them here or on Hakan’s blog.

Yesterday, I finally got started with ARIS Express. I’ve worked with current files before but this was the first time I was actually going to create something. So, here are my first impressions.

The installation…

During the installation, I was prompted to include a shortcut on the desktop. I hate desktop shortcuts. I’m the kind of gal who keeps at the most 10 e-mails in my Inbox (perhaps 20 in GMail) and try to keep my desktop clean. So I declined and couldn’t start the program since it cannot be found in the applications folder. I scanned Google and the Aris community for the command line command before giving up and installing again. So my first impression was not positive.

As a note, I was prompted to upgrade the other day but after that the shortcut on the desktop stopped working. Fortunately, there was a shortcut in the Recent folder. It seems like the application does not understand that I’ve upgraded and now I’m prompted to upgrade every time I start ARIS Express. Annoying.

The ALM people have some potential improvements to work with…

The startup

And then the application started. Not the quickest one around. I actually thought the application didn’t work but finally I was up and running. And now it was time to select model. I had no idea which to pick. I’m not used to the different types of models and was in vain looking for an UML diagram. No luck.

I finally settles for the BPMN type, fully aware of that I’m not used to the notation.

And then I waited. And waited. Again I thought that there was a problem. Perhaps I don’t have the quickest of computers but it’s not that bad. You might guess that I was a bit skeptical by now.

Modeling

And then I started working. The UI is simple and in most cases intuitive – if you’ve used VISIO and such programs this is not so hard, but there are some functions that are well hidden.

But I soon get to really like it! It actually felt more intuitive than VISIO and I came to feel well at ease. Of course my lacking knowledge of the notation probably makes my model impossible to understand for an seasoned BPMN expert.

But here is the result:

So, what is the final take on my first impression? The installation is a shame but the functionality after that is better than expected. I will probably pick ARIS Express over Visio in the future.

During this summer and autumn, I’ve been discussing and reading even more on kanban, Theory of Constraint and how to deliver more business value. Reading David Andersson has really been a revelation, and I’m looking forward trying to implement some of his findings at work.

One of the many things that caught my attention was his discussion of the value of a feature. His idea is that the moment an idea is born, it starts to loose value. The longer it stays on the shelf, it looses value. Like the products at the store. Last year’s ideas are not worth as much anymore.

Rationally, this should not be the case: the value should be the same independent of if we develop the feature this or next year, but if we think about it: of course this is the truth in many cases. If you see an idea as a potential Blue Ocean or an Innovation, the risk that someone else thinks of the same idea becomes greater every day. Being second is seldom as valuable. What is hot today may not be that hot tomorrow.

This is of course more true with the cool features.

Another aspect is of course the perceived value with the idea creator. He is probably very happy if his idea is implemented soon, but many just get frustrated if the same feature sits on the product backlog a year before implementation.

This is of course just one reason among many for keeping short cycle time and speedy delivery, but this was something I hadn’t thought of before.

The previous weekend had its share of driving as we travelled from Stockholm to Billund in Denmark. While driving, I sometimes play mind games and this time I thought about dogs and software. Not how dogs respond to software but rather how similar they are.

Since I work with software and am since more than eight years the proud owner of a Golden Retriever, there is something in both dogs and software that I like. So perhaps they share similarities. So, this was the basis for my silly game. You will probably not learn something new in this post, so if you’re just into bare facts, you can just stop here. I’m still in holiday mood.

Here goes.

First we have the aspect of age. There are puppies, adult dogs and old dogs.

Puppies are cute, fluffy, funny and adorable. Who doesn’t love puppies? Well, puppies tend to make a mess. They require lots of work and you and your dog need to be trained. All the time. Just like a new application: funny and amusing but lots of work and learning. Some people just love the puppy /new software phase. Others cannot stand it.

The adult dog is someone you’ve gotten to know well and depending on how the puppy stage was handled, the dog can now be the perfect companion or just like an overgrown puppy: making a mess and requiring a lot of work. The same goes with software: if you don’t take of the quality issues during the first period you will probably have a messy system as it grows mature.

Then there’s the old dog. This one just loves sleeping and eating. You know what you have but chances are great that the dog is slow, have poor eye sight, don’t hear to well and is struck by breed specific diseases. And software is no different. The problems which were not handled from start are now greater than ever and at the same time the system tend to feel slower and not so responsive.

But then there are different breeds of dogs…

First off is the Retriever. This is like Microsoft Excel. Something for everyone and people seems to think that this is something which just works, independent of how you work with it. Most people are bitten by Retrievers and I believe that too many people are bitten by Excel applications too.

The mobile applications are the Chihuahuas of software. You can carry them where ever you go and they are something that is worn like an accessory by some owners. They tend to feel expensive to buy: you seem to get more dog for the money if you choose something else. And they tend to think that they are a much larger dog than they are. More noise than strength…

The creative software is like the puddles. Look very nice to people who love that type but for the rest of us, they just look weird. You need to put in a large chunk of time just to keep up.

The security programs are like Rottweiler’s. They tend to make a lot of noise and they scare the crap out of many people not used to them. They can tend to bark at most stuff so you might not even notice when the really bad guy is around.

Large Business Applications are like a bulldog. Ugly, sturdy built but you need to get a C section just to give birth to them.

Then there is everything Open Source. There we have the cats. But hey, that’s no dog!? Well, I said it was a silly mind game… The cat don’t live with you; you live with the cat. Many think that cats are easier and cheaper to keep and there are cat people, just like there are dog people.

Well, this was about the time we came to Ödeshög and my husband took over the wheel. But what was the result, then, besides from me having something to think about while driving? The most important thing is that problems we have with software development and systems are not that different from other problems in life. And I should probably get back to work…

In my previous blog post, Risky Business, I discussed why we shouldn’t be shy of risks. But of course there are risks what simply are not worth it. But how do we recognize them? I believe that the answer is that we in most cases don’t. The risks we in most cases should avoid are not the big obvious ones.

In Between a rock and a hard place, Aron Rolston tells a story of a beautiful morning. He decided as so many mornings before that to go climbing for the day. He jumped into his car, drove some miles and hiked to a mountain. He fell and his hand got stuck between a rock and the wall:

Image from Aron Ralston, taken during the ordeal. Photo credit: Aron Ralston

So, what happened? First, Aron cursed his bad luck, but during the upcoming days and nights stuck in that canyon, Aron realized that the problem was that he had done as always. Slacking on security he had not packed enough supplies and he hadn’t notified anyone where he was going. Basic security precautions. He had done the same hundreds of times before but had never seen that this was not a risk worth taking. The potential gain of his behavior had been negligible. Yes, he had had some kind of feeling of independence and freedom but he could have gain this too by leaving a note where he’d gone. Without even thinking about it, he had gradually become a person who felt that since he was such a good climber, he didn’t have to bother.

It is so easy to think that since you’re a class A climber of project manager or developer that the rules don’t apply to you. You don’t have to think about these risks. But you need to ask yourself: what do you stand to gain and what would be the consequences if you fall?

For example, we have the curse of multi tasking. Study after study tells us that multi tasking does not makes things completed faster. Quite the opposite. But still, we have concurrent tasks and projects and are amazed by the fact that things seem just to go slower.

Risk taking is sometimes fun and exciting. It can lead to real innovation and is a natural part of every day life but this does not mean that you should take all risks and most importantly: don’t forget the fundamental and every day risks which are easy to forget. Don’t get stuck between a rock and a hard place without having had the chance to gain something truly grand.

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.