VersionOne vs. PivotalTracker

VersionOne and PivotalTracker are two competing Agile management tools. I've used both. Here's a quick comparison:

Arguments in favor of VersionOne

1. There is a large community of users for VersionOne with lots of support, whereas PivotalTracker is relatively new.
2. VersionOne is a feature-rich enterprise-capable tool, whereas PivotalTracker is a purposely feature-strict "opinionated" tool.
3. VersionOne can be hosted on your own servers or in the cloud, whereas PivotalTracker is only hosted in the cloud.

Arguments in favor of PivotalTracker

1. PivotalTracker is easy to use and has a slick interface, whereas VersionOne is a (more) complex tool.
2. PivotalTracker is free, whereas VersionOne is not (except for the 10-user "Team" version).
3. PivotalTracker enforces Agile best practices by limiting your flexibility, whereas VersionOne is flexible to the point of (arguably) allowing bad practices.

Loosely Coupled Highly Cohesive Teams

A while back I blogged on telecommuting. I want to apply my argument against physical separation of staff to a global organization.

Teams or individuals who are physically separated from other team members, regardless of whether or not you call it "telecommuting", suffer from the same communication problems.

Here are some givens:

1) Communication is the #1 cause of software project failure.

2) Physically separated teams are often a business reality.

3) Physical separation leads to communication problems.

I think it is safe to say that physical separation is something that has to be overcome, so if you can avoid it, you should avoid it. Having said that, many companies are global and cannot avoid it, so let me put this another way: Don't be cavalier about the cost of physical separation, and design your organization in such a way as to minimize the risk of it.

So, if you do have physically separated teams, how can you deal with it? There are many ways. The one I want to talk about is called "loose coupling".

In software design (and hardware design, and product design), most people are familiar with the concept of loose coupling and high cohesion. Whether or not they employ the concept is another story. When it comes to organizational design, the same concept is valid, but my experience has been that decision makers don't apply the concept; and they should.

It is better for each physically separated team to own one or more of a set of loosely-coupled "things" (unit of work) in their entirety. In other words, for any given unit of work, the product ownership, project management, development, and testing should all be co-located.

What you should not do, without serious business justification, is take a unit of work and split its core functions among people in physically separated locations. A classic mistake, for example, is to do development in one location and the testing in a different location, without understanding the true cost. Another mistake is to put half the development team in one city and the other half in another, or to put the product owner in one location and the development team in another; and to not understand the ramifications.

What I often see is very shallow analysis -- E.g. "Labor cost for testing is $x/hr cheaper in country Y, therefore we will do testing there"; or "I have a team of developers available in another location who can help you, so we should use them and we'll get the project done quicker because they are available now". Splitting resources across geographic boundaries, while not adhering to the principle of loose coupling and high cohesion, it seems to me, increases the communication overhead in some unpleasant non-linear fashion. Re-working my labor-cost example to be loosely coupled and highly cohesive, I think it would be better to say "Labor cost is $x/hr cheaper in country Y. We have a module that fits their skill profile (i.e. they have the ability to do it). Let's have them create (and test, and deliver) that module."

Recent advances in the state of software development practice, which advocate things such as co-location, and emphasize team cohesion, and stipulate that testing is a development activity to be owned by "the team", support what I am saying.