Navigating Difficult Times

I chose the word "navigating" deliberately. The current economic climate is very difficult for many people and companies throughout the world. And chances are that you are affected in some shape or form as well.

It appears that no 'rule' that worked in the past applies to the current situation. Is that really true? I think it doesn't really matter. The important bit is that if you carefully choose an approach that lets you quickly respond to whatever is waiting for you around the next corner then you will be better off in all likelihood.

Some people and companies still try to come up with a grand plan for how to go forward. And as long as that plan is really more like a description of the direction and the principles to be used I think that is fine. But what good would it do to you if you would spend planning time right now on what you would be working on in 12 months time if all that matters is what you are going to do next month, three months from now, or six months from now!

Respond and adapt. Do both as quickly as needed (but not faster!). Instead of locking down your plans for the next 12 months use rolling plans (a planning tool, actually), e.g. for the next 3 months or for the next 6 months. Then update these plans on a regular basis, either monthly or triggered by new relevant information that warrants a revisit of your plans. If your plans cover 3 months they are much easier and faster to adapt to new insights than plans at the same level of detail that cover 12 months. Trying to update plans that cover a larger time frame tends to result in a lot of waste.

Navigating these difficult and uncertain times is definitely easier if you choose an approach that allows for much faster response and adaptation to the changing environment. At the same time you will be much better off once your markets start to improve again.

To Pair or Not To Pair

Although I have been using pair programming as a standard practice with my teams since 2001 once in a while I still run into the question - usually asked by an uninformed outsider - whether pairing really makes any sense. The naive view is that it appears that two people are doing the work of one so it doubles the cost for most of the items.

Initially I was extremely adament about pair programming. It's called EXTREME programming after all! Quite some time ago I changed my position slightly. Today, when I start working with a team I make it clear that the default for doing any software engineering related work is to pair with a second person.

Does this mean that the people in the team I work with pair all the time? No, not according to my observations. There are quite a few occasions when people work by themselves.

One such case is if people would like to explore a new technology or tool. Different people prefer different learning styles. And before they present their findings to the team for further discussions most people want to understand enough about a topic before using their colleagues time. This gathering of information could be just surfing the web or reading a book on the subject. But it could equally be running a few experiments on a development workstation.

Then there are the usual other activities that most people prefer to do alone, e.g. email, filling in time sheets (yes, there are still a lot of companies who have them), etc. Also, you might want to call your doctor or spouse or log in to your broker without a colleague sitting next to you.

Unfortunately there seems to be only few studies out there on the subject. Laurie Williams' work is available in different versions, e.g. here and here, and also as a book. But some people would like to see additional researchers/authors who come to similar conclusions. Some studies have been conducted in an academic environment, e.g. with students. These studies are easily challenged when you try to use them in an industrial context. (Please note that I'm not saying these studies are useless.)

More generally I believe that reasoning about pair programming using a linear approach doesn't help. System thinking should be employed. Pairing (or not pairing) affects too many other factors. A simple linear cause-effect thinking tends to exclude critical factors.

Based on my observations and experience I would describe pair programming as an activity that has a positive impact on quality, team learning, soft skills, communication, productivity, innovation, creativity, collaboration, training, and many more. To pick one, let's look at productivity.

While many people believe that productivity goes done (two doing the work of one?), I believe that productivity actually goes up (or at least stays the same). My reasoning for that is - again - manyfold.

First of all, some people confuse body time with brain time. Have you ever walked through a development department where people work solo? Run a little experiment. Peek at the screens of the people and take a note of the percentage of people not currently looking at your IDE (or other work related tool). Now, do the same experiment with a team that uses pair programming as a standard practice. Or even better work with a partner and try to track your stock quotes at the same time... I think, you my point. With pairing there is no way to back out or to just doze off. You're in it full time. The ratio of brain time versus body time is much higher than with solo programming.

Next, a pair can and will be much more adament about the quality of the change set they deliver if they are members of a properly trained agile team. They will merciless refactor trying to use the simplest possible design and implementation to get the job done. They will be creative and innovative in doing so. They will have automated tests in place preventing other people from accidentally breaking their code. And once they have committed their change set they usually can focus entirely on the next task without having to go back to some past work.

There are other factors that are worth exploring, but I'll save them for now. I'd like to come back to them in a future post in this blog. As always, I would be very interested in hearing about your experiences and also about your feedback to this post. Thank you!

And another story

Let's see who thinks this time that I'm telling his/her story...

Again, I met a friend, let's call him Peter. Does he really exist? I don't care as that is completely besides the point. It is more about the story which, again, I have heard more than once from different people. In this case the first and the last account are several years apart.

The story goes like this: Peter is working for a consulting company. They developed and delivered a system that collects certain information across large geographical area. Part of the solution is using mobile devices for this, and once per day the data is transferred back to the head quarter to a central server.

The problems started when they started to work on the part of the software that deals with the transfer of the data to the central location. The firewall settings and the security policy of the company didn't allow for a direct connection, not using SSL (or any other secure means) and not even to a server in the DMZ (Demilitarized Zone). Then Peter asked whether they could sent the data via email, e.g. as an attachment which could then be picked up by a server. This solution wasn't acceptable either. Peter's client started internal discussions, and the went on and on.

At some point the delivery date of the project was at risk, and Peter couldn't wait any longer for a decision to be made. He had to come up with a solution.

Peter discussed the problem with his team. After some lengthy discussion, back and forth, they found the solution:

• Print the data
• Fax the data
• Enter the data

Yes, you are right! Faxing was ok. And then some people in the headquarter of Peter's customer would take the received faxes and enter the data manually! Crazy, but it saved the delivery date for the overall system.

Update: In the meantime the customer has settled on a much better solution and the data is now transferred via SSL to the DMZ, where it is picked up and transferred to the server within the firewall.

Morale: Sometimes you have to be very creative and adaptive to make the deadline. I think Peter and his team were very agile!

Apologies from Agile 2007 Conference Program Committee

In case you have submitted a paper, tutorial, etc. for the Agile 2007 conference, you most likely have noticed that the submission system had a system error. Here is a message from the conference chair on that regard:

I am finding as many opportunities as I can to express sincere apology for an error in the Agile 2007 submission system which caused multiple
accept/reject messages to be sent out. While all of us have experienced errors in our software projects, this is one that inconvenienced many people... for this, I apologize.

We can point accusations at the software developers and testers, but it will not accomplish anything. Instead, it is more effective to correct the error and move forward. We have sent revised accept/reject notices (with an apology) and will make every effort to learn from this experience.

We hope that this mistake will not cause you to overlook the countless other things our hard-working team of volunteers are doing so well in order to make the Agile 2007 conference fabulous in many, many ways.

Mary Lynn Manns
Conference Chair, Agile 2007

Being a member of the program committee myself, there is nothing I can add.

Fingerpointing, however, will not help. Instead, it is important to look at the situation, make the best out it, and move forward. I think Mary Lynn and the other members of the committee are doing this. We all want the Agile 2007 conference to be a success!