Creating a mindmap specification

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?

When it actually works

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?

dead horse strategies

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 the opposite is also true

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!

Pre study blizz

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.

Taking the train with dr Deming

Sometimes you cannot help wondering how you´ve become who you are.

This evening, I´m on the train towards Lund in south of Sweden to meet
with a possible supplier. So, I have two hours of time available.

Great, I thought. Finally time to read W E Demings. So here I´m
reading a book called The New Economics for Industry, Government and
Education. Voluntarily. How did this happen… And even more
facinating; I enjoy the reading too.

But I guess that if I was one of all these young students around me, I
wouldn´t have had an idea of what he was talking about. This is one of
the books you wish students would read but you realize they have no
possibility to understand before they have worked for a number of
years. And to be frank, not all seasoned workers would understand it
either. Not that the language is difficult. It might be dry, but
clearly understandle. if you know what problem he´s covering. So, what
is about¿ It´s about Deming´s view on management for a long term
successful organization, an organization for which success does not
only happen but is created, maintained and improve.

Many of us has management as a part of work. It can be a school, team,
student group, company or a family. Deming does not let us place blame
on anything or anyone else but management. On all levels.

I will get back with examples, but remember that this a book which is
difficult to take the time to read, is easy to read but is hard to
understand if you as a part of your management style rely on ranking,
blaming and adoration of oneself. To be that manager though, is a life
long project. Now, back to reading