- Published: Saturday, 12 March 2011 00:00
- Published: Sunday, 20 February 2011 00:00
- Published: Saturday, 19 February 2011 18:40
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.
Now, 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!Write comment (0 Comments)
- Published: Thursday, 03 February 2011 00:00
- Published: Tuesday, 01 February 2011 00:00
- Published: Sunday, 30 January 2011 01:02
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.Write comment (0 Comments)
- Published: Saturday, 29 January 2011 00:00
- Published: Tuesday, 25 January 2011 00:00
It could be that I am misunderstanding the voice, but these flaws are rather scary in an elevator….Write comment (0 Comments)
- Published: Tuesday, 25 January 2011 00:00
- Published: Tuesday, 04 January 2011 00:00