At the RAMIRI training I followed in Trieste this week, one sentence particularly resonated with me. It was by Kimo Koski (CSC Finland) who was remarking that it takes effort to keep an organization customer focused as it grows.

Starting at about 100 people an organization can keep it self fully busy without ever serving a customer.

While I was working for Bruker AXS, our Sales director Paul Ulrich Pennartz used to say something related sometimes when he was in a cynical mood:

Without those pesky customers we would finally be able to concentrate on our work.

 If you've ever wondered why small companies are more responsive than large ones, I think these two people summarize the cause quite well. 

(Note: both quotes were reproduced in essence, this is not literally what they said)

Axe in a block of woodWhen more than one task must be completed, it is always better to do one before the other. I discussed that earlier in the post Parallel processing in a project team.

An individual customer with a new question could think that it is even quicker if you fit his project in between. We have to make them aware that if we allow interruptions of any kind in an agile sprint, nothing will ever be completely done. What can we tell them? There will be other people with new requests while we are working on your task.... should we honor their requests to interrupt our work too?

They should understand: agile sprints are not interrupted. They are either completed, or canceled.

Image from Flickr by brittgow

In an organization with more than two people, most likely there is a hierarchy. Some people are managing others.

On the other hand, project leaders are not necessarily managers of the members of the project team. Project leaders can not give orders to get things done. In our organization it is even worse: project team members are employed by different universities and hospitals, and the project leaders are in our separate group. Orders will not work.

A question that comes up sometimes is: how can one manage a project and its team members without giving orders? Sometimes this comes in the form: for you things are much easier, you are the boss and can tell everyone what to do; I do not have such power over the project team. My answer to that is: how often do I order you what to do? And if I'm not ordering you what to do, how do we run a coherent organization?

The clue is: don't tell people what to do, convince them instead. Build trust (this takes a while), and then use your expertise to convince the members of the team to align.

In fact in larger organizations, managers do not use orders a whole lot. Trust (and expertise) are much more effective. And this gets stronger higher up in the organization, up to the CEO. The biggest problem with managerial power is that it wears off when you use it. Trust grows when used properly.

Don't manage by giving orders. Act like the big company CEO.

For more inspiration, listen to this Manager Tools cast.

[Image credit: Giving orders by on flickr]


There are two ways of car navigation: non-agile and agile. Non agile navigation is when you take a sheet of paper with you with instructions like this:

Drive 5km. Take a left. At the third light to the right, then before the blue building to the left.  Stop when you arrive at a gas station.

Non-agile navigation works fine if there is a path to the destination that is well known, and where you can't make a mistake. If anything changes on the path, if there are roadworks, if you make any mistake along the route: there is no contingency; it will be impossible to reach the destination. Furthermore: If there is nobody around that has been to the same destination (even several times), it will be impossible to get a detailed description of the route.

Agile navigation is using road signs. To get to the San Francisco Museum of Modern Art, you first follow signs to California, then San Francisco, and when you arrive there, you follow signs for SFMOMA. The only thing you need to know is where you're going, and roughly where that is (recursively, if you want). This method of navigation is very robust: even if a street becomes a one-way street, or if the blue building is torn down, you will still be able to get to your destination. What's even better is that if, along the way, your exact goal changes, you will still be able to change your plans. On your way to San Francisco, you may still decide that you want to visit the Golden Gate instead.

Golden GateNow, of course, I am not trying to teach you how to navigate a car. I just want to use this as a metaphor for the development of software.

How is software development like navigation? You normally do not exactly know what you need to develop. And only rarely can you exactly follow the tracks of somebody else. Software development is not like the known path that is suitable to non-agile navigation.

Nevertheless, a lot of software is still developed using non-agile methods. Specifications are fixed completely before the development is started. The exact steps required are written up in detail. Contracts are signed. And then road blocks occur, and the project goes over budget and falls behind schedule. And when the project is delivered, the customer is not happy with the functionality because either his ideas have changed, or he has not been able to express himself accurately enough in the specifications.

Agile software development has all of the advantages of agile navigation. You can go to unknown places. You can even change the details of your plans along the way. And it is very robust against unexpected road blocks. It is clearly the right choice.

Agile software development is not easy. But it is less prone to utter failure than the traditional method.  Let's learn to navigate on the road signs!

We did experiment quite a bit with different ways of having our group meetings. At most of our meetings some of the group members are joining us from remote locations, and we want the remote members to be full meeting participants.

For a little while we only shared the sound with the remote participants, using skype. That worked rather well, but it brought the difficulty that the remote participants could not see the same screen that we were projecting on the wall in our meeting room. If we had only one remote participant, we could transmit a lo-fi image through video skype, but this was hardly better than no screen at all.

We then started trying different web-meeting software: a free trial of gotomeeting, and the free version of dimdim (when it was still available). Gotomeeting had the problem that it is not supporting Windows, Mac and Linux equally. Dimdim had better support for different operating systems, but had much worse sound quality and the video was sometimes completely black or delayed by as much as 10 seconds.  These "official" solutions did therefore not lead to better communication for us.

Our problem was solved when we realized that we could use skype for audio, and all share the same screen by using VNC. We installed a VNC server with (readonly) java client on one of our linux servers. During a meeting, the meeting facilitator is in control via a read-write VNC session while the other participants only watch. Audio connection is done via skype as before, delivering good quality audio through a special external speaker/microphone combination.

This made us very happy, without monthly subscription costs. I'd like to hear in the comments about other alternatives you have explored.

Update: David van Enckevort explains in a posting on his blog how to set up a VNC server like we did.

One of the first stages in the development of a new tool (software or hardware) is a functional specification. The functional specification matures in discussions between the developers (department of R&D) and the customer representatives (often the departments of marketing and sales).

Of course a functional specification is useful: it is very hard to develop something new without an idea of how the new tool will be used and what it will be compared with. However, defining a functional specification can also be taken too far. In some organizations, the functional specifications are spelled out in the tiniest details. At the end of a long formal procedure, the book of specifications is signed like a contract between marketing and development. The development can only be started when the list of signatures is complete and will be performed in splendid isolation from the world of potential users. Why do organizations do specifications this way? It is often an attempt to separate the responsibilities of the departments, so that if anything fails the appropriate party can be blamed. If the final product does not meet the functional specifications, this can be blamed on the developers. And if the product does not succeed even though it meets all the functional specifications, this will be blamed on marketing.

I have a serious problem with this approach: using this procedure, how can one ensure that the product will be useful? After two years without interaction, development may produce exactly what marketing asked for (making all deadlines and within budget), but the market has changed and does no longer need the designed product. Or technology has changed, and better specifications would have been within reach and are offered by the competition. Or maybe marketing truly made a mistake, and asked for something the world is not waiting for. In these cases, clearly the development department can not be blamed! But if you develop an obsolete product this way, where does that leave the organization as a whole? And if this is not the best solution for the organization as a whole, will it be good for the development department? Even though everyone did exactly what was expected, people may be laid off because development costs can not be recovered.

The solution is, as often, to keep a middle road. Using e.g. Agile or LEAN development methods,  developers can stay in constant communication with marketing. Iterative  and modular design procedures can be used to verify that the new tool does what it should, without relying on the capacity of people to describe specifications in words beforehand. And because the communication with the market is not lost during the development process, the tool will have a significantly higher chance of actually being useful at the moment of introduction.

Image (by QuiteLucid on Flickr): "a camel is a racing horse designed by a committee".

Imagine a mechanical workshop. You come with a problem that they will solve. What do you expect? You expect to work together with them, roughly in the following five-step procedure:

  1. Specify. You will describe the problem in the form of a functional specification
  2. Design. They will make a drawing
  3. Pieces. They (possibly multiple people in parallel) will use the design to select and manufacture pieces
  4. Product. They will weld the pieces together into the tool you need
  5. Test. You test it, and it may require minor adjustments

Now imagine a software workshop. You come with a problem that they will solve. What do you expect?

  1. Specify. You will describe the problem in the form of a functional specification
  2. Product. They will make the software tool
  3. Test. You alpha test, they fix, you beta test, they fix. Repeat until satisfactory

How come this list contains only three instead of five steps? And why is the last step always causing so much pain? Could this difference be the origin of why so many software products fail? What is the real difference between software and hardware development?

Rather than trying to solve the software problem at once, first imagine a hardware workshop that works like this:

  1. Specify. You will describe the problem in the form of a functional specification
  2. Product. They will weld materials together into a tool
  3. Test. You test, they fix, you test again, they fix. Repeat until satisfactory

How likely would it be that this procedure is faster than the five step procedure? How obvious is it which pieces need to be welded together? Will this allow multiple people to work together on the product? And how much work is the testing for you? How much waste is produced in the process? You would not accept this kind of quackery! And my point: you should not accept it from a software workshop either.

A good software workshop would use the same five steps the good mechanical workshop uses:

  1. Specify. You will describe the problem in the form of a functional specification
  2. Design. They will make a (modular) design
  3. Pieces. They (possibly multiple programmers in parallel) will use the design to build and select software modules 
  4. Product. They will use the modules to build the software you need
  5. Test. You test it, and it may require minor adjustments

Investment in a design will result in a solution that will truly solve your stated problem, and not require endless iterations to get right. It may look like a slow solution, but that is deception: you will actually get a result that gets you where you want to be, also when you have new additional requirements in the future.

I'd like to thank a former colleague at Bruker AXS that gave me this nice comparison. I know he wishes to remain anonymous on the 'net. Image credits: Dystopos on Flickr.

Screenshot Pacman

After every radical change in an organization, there is a need for a phase of quiet thoughtful improvements. Expecting miracles from huge corporate reorganizations is a fallacy that leads to reorganization upon reorganization potentially resulting in complete destruction of the organization.

Have you ever played a game of Pac-man? It is a simple game where you control a little eater eating dots on the screen, while ghosts are chasing you. The game is an excellent mirror of business life in a changing environment:

  • In Pac-man, you are trying to improve your health at every step by eating a dot and staying out of the way of the ghosts.
  • In business life, you are making small changes to your products and procedures to sell more and stay out of the way of your competitors.

There is a further analogy:

  • In Pac-man, sometimes things get stuck. Ghosts are closing in from all sides, and there is no escape. At such a point, you can use the teleport: a panic key that takes you to a random spot in the scene in an instant.
  • In business life, sometimes things get stuck. Competitors are closing in and it seems there is no way out. At such a point the CEO will call (often quickly without consulting all those that are involved) for a radical reorganization.

In business there is an important lesson we can learn from the teleport feature in Pac-man: A teleport is far from a guaranteed save! It can bring you into a very dangerous situation. The goal of the teleport is not an immediate improvement in the flow of the game, it is to escape from a hopelessly stuck situation, from impending disaster. Directly after a teleport, you have to act and make steps to regain control. Similarly, in business a radical reorganization will rarely take you to a better situation immediately. A reorganization is meant to shake up the bowl and escape from a hopelessly stuck situation (often invisible to many of the employees). After the relatively thoughtless jump that has to be executed quickly to avoid an immediate game over, the organization will need to go into a thoughtful phase in which small improvements are made to optimize the situation.

If you realize that a reorganization has not brought you immediate gains, try to refrain from making further reorganizations. Instead, look for opportunities for small changes, and give it some time.

Not everybody likes the same kind of work. This is a great opportunity for people involved in a group, if it is recognized, and if communication about what everyone likes and dislikes is open.

I once heard a terrifying story of an old couple that celebrated their 40th wedding anniversary. As one of the parts of the celebration they made the appointment that they would communicate for once about something they dislike about the other. The man starts: "my dearest, I love almost everything you do for me. But if there is one thing that I would like to change it is the way you cut the bread. You always serve me the heels of the bread, and I much prefer a normal center slice". Upon this, the woman nearly fainted. She had served her husband the heels of the bread for 40 years, only because this is the part she likes best.

In any enterprise it is important that all jobs are done, including the dirty ones. Sometimes we just have to do things we do not like. But in a collaborative effort, it is important to communicate about which parts of the work we like and dislike. Maybe, just maybe, a colleague would love to take over part of the work that you despise.