Yesterday I posed a question: can pair programming techniques be used to improve other business processes?

One of the aspects of pair programming is information transfer—that two people who work directly with each other have a much stronger mutual understanding of the task at hand.

Where this seems to be most important is when crossing boundaries of responsibility. For example, I’m responsible for delivering a price and spec for an iteration, and Jason is responsible for delivering the code. In order for us to be responsible for what we’re doing and have confidence in our goals, we need to a thorough understanding of what and how we’re going to do it.

Where else in business can these boundaries be found? Off the top of my head:

  • Deployment and development: what are the deployment requirements for an application in development, and what are the deployment capabilities?
  • Development and sales: what does the customer want, and how much will it cost to build?
  • Sales and marketing: what do our potential customers respond to, and what through what channels can we reach them?
These are all things that fit the “pair” model well—they all generate persistent artifacts (documentation, code, marketing literature, etc.) and require detailed mutual understanding of the issue.

Where have you found these boundaries in your business?

comments powered by Disqus