It is very important for us to not compromise on paired programming.

If developers work independently on separate parts of an application on a continuous basis, even if they happen to be sitting at the same desk when they do that, then very important problems from solo-programming start to emerge.  (1) To the degree that each thread of work is separate, it happens without continuous code review. (2) The same is true about collaboration. Even occasional collaboration on these matters becomes less effective and less insightful because the other person has not built up the mental map of the code base that comes from being involved in the full development process.

And (3) if a developer is sick, quits, or gets fired, there will emerge large gaps in understanding of the code base and large sets of knowledge that are missing from the remaining team. Turnover can simply not be avoided; it happens everywhere. Indeed, the original developer does not even have to leave; that person could be engaged in another more urgent project, or involved in another completely unrelated role in another part of the company. Furthermore, programmers often assert that they would find it easier (or prefer) to rewrite entire applications rather than reverse engineer or try to figure out code that they did not write themselves. Not working in a pair on all major aspects of a project introduces big blocks of risk (bad things that could happen unpredictably at any time, and often at the worst possible time) versus the alternative of potentially slower development that is nonetheless much more predictable and dependable.

As an example, consider that earlier this year we spent about a month developing an application for a client with a single pair of developers. During the course of that month, we had two developers leave the project for various reasons. In the end, four programmers worked on the project, and only one was around for the entire duration. However, development hardly slowed despite the disruptions. We completed the project on schedule. The client noticed no interruptions or problems. And when the client came back to us to do more work a couple months later, we still had someone around who had worked on the entire project. This would not have happened without paired programming.

I would assert that if people are not working productively in a paired programming environment, that the problem is not paired programming. (1) Some people do not work well with other people. They may need to find a company that either deliberately or unwittingly is willing to let them work alone creating applications that are poorly understood by others and that have a high risk of never being completed or of being abandoned because the original developer has moved on. I would also suggest that people who do not work well with others might also have a higher likelihood of moving on, even halfway through a project. (2) Sometimes the problem is that developers are not paired properly with people at their same level. A very fast developer will find it hard to work with a slow developer. And a junior developer will have a hard time adding value to a senior developer. Sometimes a person who is unfamiliar with the programming language, environment, or application will have a hard time making contributions (although this pairing can be an excellent way to bring an otherwise productive person up to speed). And (3) there will be exceptional people and circumstances where someone working alone gets more done just as reliably and maintainably as a pair. But there are fewer people who are this exceptional than there are people who think they are this exceptional. Firms and projects take a risk when they decide that someone does not need to pair program because they are exceptional in this regard.

Everyone Pair Programs at East Agile, as shown in the photograph above.

One thing that seems to be very unique about us is that we really do paired programming. This practice is not for everyone by far. A lot of people don't get it and won't get it. But for those that get it, we are one of the few deep practitioners.  Pivotal Labs, of course, is another one. Just from talking to people from other leading development shops it seems like 90% or more of Ruby on Rails agile companies do not practice it to the extent that we do. Paired = higher quality & lower risk of project interruption.

Learn more about Paired Programming on Wikipedia, including information about research on its effectiveness.

If your screens don't look like this then (a) you have better screen hygiene than these developers, but perhaps (b) you're not doing eXtreme Programming right, and in particular, you're not doing paired programming.  Having fingerprints all over the screens is an artifact of active collaborative development.

Learn more about Paired Programming on Wikipedia, including references to research on its effectiveness.

 Development process

Please provide details of your process and the way you like to run projects. Do you use an Agile or iterative system - will we see regular releases throughout development?. Do you like to communicate via email, phone, IM? Do you have an issue tracker that you use with clients? Do you have weekly status meetings with clients? Do you send status reports every few days? Do you provide one point of contact? How do you handle change requests?

Whenever we have the option, we develop using eXtreme Programming methodologies. Pivotal Tracker (http://Pivotaltracker.com) manages our tasks, progress, client interaction, and bugs, chores, and issues.

We ask clients to provide at least 4 hours per week of time from a business or product manager who understands the product, how it should work from a user perspective, and most importantly is able to make business decisions about priorities. We work with that person on a daily or at least once weekly basis.

We typically do not use one point of contact, although one developer could be designated as such. Typically, all developers, or at least each pair, interact with the client product manager on a regular basis, primarily through Pivotal Tracker.

Our eXtreme Programming methodology involves Test Driven Development (TDD), paired programming (See Wikipedia, other discussions on this site), and weekly emergent iterations implementing prioritized features. We work with a (client) product or business manager to break up a product into relatively small user stories and features which we estimate time to deliver on (trivial to a full day of work). The client then chooses priorities by dragging and dropping these into our work queue in our Pivotal Tracker project managment software, which we implement on a strict priority basis. As work is done, the client sees "accept/reject" reject buttons on features, driving their role of deciding if the feature has met business objectives. Other tasks are also managed through this process, including chores and bugs. As work is done, a velocity is calculated using actual relationships between estimation and actual completion time, and all future work is automatically forecasted out using these current actual measurements. We attempt to make a release-ready version of an application every week or two. Development proceeds such that a release is a business decision and not an engineering one. Typically, clients see live functionality created on a daily basis.

Similarly, completion of a project is a business decision not an engineering one. Because we implement features from most important to least important, all the highest value and business critical features are done first. Over time each iteration should add less value than previous ones (except when innovation takes place during development, which does happen frequently). At some point, there might be nothing left to do, or we may be done from a business perspective when all the features that add strong business value have been done, and only marginal ideas or features remain in the "icebox" of tasks.

Changes requests are trivial in our agile methodology (on a time-and-materials contract). A client need just drag an unstarted feature in Pivotal Tracker from one location to another to change when it is done. Or a new one can be thrown into the icebox, our engineers asked to estimated it, and then the client can drag it to any point in the future to have it executed. All time estimates and release schedules are recalculated in realtime using actual performance measurements.  

In a fixed-bid contract the change request process could work much the same way: a client could add anything they wanted to the "icebox" of ideas, ask us to estimate it (minor, half day, full day). However, some sort of written agreement or notification would be needed before dragging a new feature into the project. And similarly, some sort of  written agreement or notification would be needed before removing a feature (and getting credit for that). The agreement/notification process would need to be defined in a contract.

We do sent daily progress reports, but much of our discussions and information get exchanged within Pivotal Tracker. We augment this with conference calls, email, and IM and screen sharing. Progress monitoring also take place using automatically generated graphs: release burn down, current iteration burn-up, velocity, story-breakdown (feature/bug/chore).