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?
Pair Programming
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.
James Shore
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?
I have experimented with pair authoring several times and it works very well.
It wasn’t for requirements, but, in functional specifications.
I think I can sell it the same way I can sell the pair programming. Any work output that requires review, if made with a pair is immediately reviewed. From there comes the quality improvement and in the end the possible productivity improvement.
The downside for me is that contrary to programming, writing has no well defined consistency rules for prose and schematics’ style. So, you may loose in the way a “document feels”. This isn’t so serious in technical documentation as it is in novels or more artistic writings…
[e-mail corrected]
Luis,
Great point about immediate reviews.
Interesting point about the lack of “defined consistency rules” for writing. Do you think it is analogous to variations in coding style, or more like a lack of defined syntax?
I completely agree about novels/artistic writing, and I could see how writing style (phrasing, grammar, etc) would make a document awkward to read if it changed on a regular basis throughout the document. I know I struggle when reviewing someone else’s writing, when it comes to stylistic feedback. It is hard to avoid rewriting a paragraph that is “ok, but not the way I would do it.” How do programmers deal with this when pairing?