Stephan Schwab

Yesterday I gave a talk about Agile Development in Panama at the Atlanta JUG. I have to thank again Gunnar Hillert for inviting me and all the JUG members for their attendence and good questions.

This talk was a bit different than what you might expect at a Java Users Group meeting, as it wasn’t the typical technical talk. My goal was to provide a realistic image of the situation for software developers in Panama, which is a small Latin American nation of only 3 million people. A significant share of those 3 million is comprised of the members of four quite distinct indigenous tribes who live in autonomous regions on small islands or deep in the tropical rainforest. About 800,000 Panamians – it might be more – live the in very modern capital and the rest is scattered over several provinces where agriculture is the dominating business.

For software development it doesn’t need thousands or person. A few good ones make all the difference. So I’m particularly pleased that I had to opportunity to showcase the Panama JUG which is comprised of students of the Universidad Tecnologica and led by their teacher Aristides Villareal. The Panama JUG, together with other individuals elsewhere in the Spanish speaking world, is responsible for the translation of Sun’s Netbeans IDE into Spanish.

In two weeks we will have a big event in Chitre, the capital of the Herrera province. Please see my earlier post for more details.

The PDF of yesterdays’s talk is available for download. The file is 20 MB, as I had to print each stage of the slides.

Earlier today I cited from another blog and remarked that craming the team in a small space to me seems to be too distracting. Here is another comment on the same topic:

Vladimir Levin in Pair Programming Redux:
My conclusion is that pair programming does work, but it requires some care. First, developers have to respect each other and be willing to compromise. Also, pair programming 100% of the time doesn’t work. Sometimes when facing a design problem it helps to go off and work separately, then get back together and discuss later. Also, pair programming – constantly communicating, asking questions, explaining and justifying one’s own ideas throughout the day – is very demanding. After a period of time, burnout can occur. When that happens, I think it’s a good idea for people to be able to work on something alone for a while.

Have a look at the these two pictures of a team room. They appear on Ken H. Judy‘s blog in a post called Our Team Room:

Do you think you could work in such a small and crowded place? I’m sure I would not be able to concentrate. I know this is what XP is meant to look like, but I seriously doubt that this setting will create better quality software than a quite work environment where people can focus. To me this is more a room for training sessions than the place where you work for months on a product.

Instead I prefer and recommend private offices – with a door you can close – for each developer or a larger room for a small group of people who go well together and don’t distract themselves by talking to much. After all software development requires that you process a lot of complex information in your head and the last thing you are looking for is distraction.

Savila‘s issue list allows the team to focus on the current sprint’s stories:

And if you happen to use Eclipse, you can use Mylyn to even focus more on just the classes that are related to the task you are working on:

On the other hand such a “war room”, as some call it, might be well suited, if the task for a team is to fix a problem, some kind of an emergency. Then such a setting makes a lot of sense. Is software development about fixing something or is it about creating something? What’s the difference between the development of a product and integrating something into an existing system? I believe that when you create a new product, you should take your time and not do it in a hurry. New product development is more an exploration of a certain space, a journey and you don’t know where you will end up or you might even realize after some time that you better cancel the project, because you learned something about another solution on the way. That’s way different from integrating two systems or adding some smaller additional functionality to an existing system..

So I think that when we talk about work environment, Agile, Scrum and XP, we should as well define clearly what kind of work we are talking about and where we want to apply certain methodologies and techniques.