Pair programming is a bit of a foreign concept for many people in business. A few years ago, it was foreign to most programmers too. Pair programming is a powerful technique for software development because it allows two people to look at the same problem/solution from two different perspectives at the same time. Would that same approach work for business analysis?
We haven’t written an introductory article on pair programming, and after reading what James Shore has written on pair-programming as part of his book, The Art of Agile Development, there’s really no room for improvement.
Pairing involves two programmers (or, less often, a programmer and a customer, tester, or other team member) working together to accomplish a single task. The person with the keyboardâ€”the driverâ€”focuses on the details of the task. He thinks tactically. The other personâ€”the navigatorâ€”keeps the big picture in mind, ensuring that the task fits into the project as a whole, looking for ways to improve design, and keeping track of team guidelines. She thinks strategically.
The interesting dynamic that makes this work is that the two programmers switch roles on a regular basis. As frequently as every half hour. Read this intro to get a better feel for it.
[Segue: Please read, review, and provide feedback for James on his book. It is awesome that he is doing the book this way, and you also get to read the early stages of a great book before most people.]
Strategic and Tactical Programming
Great programming is about both design and execution. The navigation and the driving, as James puts it. Having been a pair-programmer in a past life, I can attest to the power of this dynamic. When I think about really powerful solutions and innovations, they have come from (or at the least been improved by) collaboration.
Even without pair-programming, we can get the same benefits through feedback and reviews of our designs and our code.
How does this apply to business analysis?
Strategic and Tactical Documentation
When we create requirements documents, use cases, object oriented diagrams, and other artifacts, it is no different than programming. Instead of source code being written for a compiler to read, our documents are written for a person to read. We just don’t have the benefit of a compiler to point out our grammar mistakes, a code-styler to suggest more concise ways to write or more universal terms to use, or a set of automated tests to identify ambiguity and incorrectness. We have to get feedback the old-fashioned way, by reviewing our documents. The ease with which stakeholders read our documents is analogous to the performance benchmarks for code.
The organization of our documents is analogous to the design of a programmers code. The details we write are the embodiment of that design, just as code is the manifestation of the design. There are significant parallels.
We should be able to benefit from pairing when writing requirements documents.
The Biggest Improvements
When I think about the biggest improvements that I’ve seen in the documents we are creating on our team for my current project, almost all of them have come from collaboration. Formal and informal reviews of documents, brainstorming about how to represent a process, and discussions about the tradeoffs of documenting things in one way versus another.
This feels a lot like the code-reads we do as programmers. People who have pair programmed consistently admit that it is better than the do-review-redo cycle of traditional development processes. Would the same hold true for documenting requirements and processes? What about any writing at all?
Here’s another quote from James:
Pair programming produces code through conversation. As you drive or navigate, think out loud. Explain your assumptions, your short term goals, and any relevant history of the feature or project. If you’re confused about something, ask questionsâ€”the discussion may enlighten your partner as much as they do you.
Sounds a lot like the best parts of the documentation process to me.
What Do You Think?
Do you think it would work? Do you think you could sell it (justify the staffing of it)? Is there a downside?