Agile Software Development

I've been thinking a lot about the collocation of agile development teams (or any development team for that matter). Some people argue that collocated team members are essential to successful software development while others argue that it doesn't make any difference. The more I think about it, and the more we operate with geographically dispersed teams, the more I'm starting to believe that collocation matters.

Currently, our team is spread out between Ft. Collins, CO, and Orlando and Jacksonville, FL. While things have not gone terribly wrong having dispersed team members, I have noticed a difference in communications. The difference is that in the Ft. Collins office (and I'm sure in Orlando and Jacksonville), there is a lot of informal communication that occurs amongst collocated team members. You know, the kind of discussions that happen spontaneously. When these happen, a lot of project information gets passed between team members that doesn't get transmitted to other remote team members. There is no malicious intent to not communicate. It's just that the impromptu discussions don't usually inspire anyone to dial in to a teleconference number and all that...precisely because they are impromptu.

"Honesty is the best policy — when there is money in it."
- Mark Twain

XP requires constant communication between team members. More specifically, XP and Agile teams depend on honest communication between stakeholders, including developers, testers, managers, and customers.

We expect manufacturers and vendors to be honest to us about the products and services they offer and market to us. Our customers expect the same. Honesty is especially crucial during iterative development where a minor course correction early in the schedule can save significant time down the road.

This is part 2 of an indefinite series of posts centered on using agile techniques in distributed development scenarios. (See also Part 1 on Reinterpreting th Manifesto)

At work, most of our projects have daily Scrums. For some of our projects this simple activity becomes much more laborious because part of the team is in a different time zone. In this post I will write about some key guidelines that we follow to make sure that Scrums remain productive and interesting. Without further ado, here we go:

I work for a software company which has their development center in India. A large portion of the work that we take on has to do with product co-development. These clients are typically ISVs who have active product development teams. They usually partner with us to augment their team sizes to take advantage of the extended daily development cycle. So, for a client who is in the US, for example, our team here takes over from the US team when they come into the office and then hand over to the US team when they leave; this allows almost round-the-clock development.

In such a scenario, where two separate teams are working in close coordination with each other, the right kind interpersonal relationship within team members can really boost productivity and efficiency. So, how do you get a proper relationship going?

This is Part 1 of an indefinite series of posts centered on the topic of distributed development and using agile methodologies in distributed teams.

Problem
One of the principles of the Agile Manifesto is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” The manifesto was put together in 2001; a long time ago by software industry standard. At that time, offshore development (the primary scenario for distributed development) was beginning to gather momentum, but most such development occurred using the traditional heavy-weight development methodologies.

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of communication is to explicitly state that XP teams consider sharing the status of pretty much everything being important. Even though the useless meetings are not too welcome in any methodology, in general XP teams prefer the risk of over-communicating to under-communicating.

Agile software development processes by any definition encourage the in- and-out team communication via various practices from pair-programming to informative workspace to retrospectives. With the respect to all the usual practices there is one more often underestimated way of getting the in-team feedback - the hallway testing. The term Hallway Usability Test coined by Joel Spolsky stands for "grabbing the next person that passes by in the hallway and forcing them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code."

On Joel's Multitasking in the Workplace

Multitasking in the Workplace:
Joel Spolsky, a known writer on software development related topics is a long standing advocate of private offices for every developer, perfect working conditions and managers whose main role is to “move furniture out of the way, so people can concentrate on their work”. Lately he found the support in the published in the NY Times research report claiming that in the cubicle space people loose hell a lot of time on interruptions. I believe that there is a proven way to unite the advantages of the open-space communication and private office focus.