10-06-2014 by Sebastian Schürmann
Over the last years, I got many good Ideas from teams on how to use pairing in their daily work. It is very interesting how the initial idea is “hacked”, changed and adapted. Some traditional and not so traditional approaches here in a blog post.
Everyone pairs with everybody else is a nice way to get knowhow shared in your team. Sometimes it is a hard start, but when you have completed this for the first time, there will be foundations of teamwork that are hard to achieve otherwise. Some of the advantages of doing so.
You can pair in a environment with Unit-Tests and make a change not based on time (although it is good to set a maximum time limit) but when you go forward in the re-green-refactor loop. Use the following Cycle when starting with a green lit unit test suite:
Remark Always on green tests and rector make a commit. Push to master if you are done
This is very good to learn and internalize the way TDD in its purest form as in test first works. It will give you very good insight in the method and produce code. You can have a very fast cycle here as soon as the basics between the two persons pairing are sorted out.
This is a variant of the above, but with the exception that one person makes the tests green and refactors them. This is a little more training oriented and can be used to teach a newbie essential skills in software development and TDD.
Hint Even if it is hard for you as the expert: The newbie should write the code. Doing creates a way better understanding.
Speaking of newbies how about this: The next time you onboard a new team member you do not make his setup for the development environment for a week. Instead you let him pair with every member of your team for a longer time.
New colleagues in a company are still free from most of the organizational duty and are often stuck in a situation where they have to ask a lot of questions in order to be productive. Codebases are big and the details of implementations are specific: The new person will have a hard time to contribute to productive code and learn at once. By pairing with a experienced team member this problem can be solved. You do not even need a computer and this can be done from the moment a new person enters the office.
Remark This leads to a extremely lowered on boarding time. Additionally the person can actively bring his skills to the table.
Releases kinda suck. Always a bit. A little more when you do not have a complete Integration and Continuous Delivery pipeline set up and there is stuff to be made by “hand”. Often this “duty” will be on one person and thereby you create a single point of failure in many ways. It is hard to review a release. You just know if it worked or not. So working as a pair might be a good thing. Shitty duty gets more fun this way and the peer-pressure will keep the pair in line not to cross the many lines in a release process that can be harmful just for sloppiness. Releases suck. Been there done that.
Bug fixing kinda sucks too. At first something is not working. After it you will be looking for the source of the bug and then you will find out that you have made a very specific mistake (you as in team). This burden can be shared. It’s not that your colleagues have not made the same kind of errors (or worse) in the past. We are humans. So lets get this painful duty over with as a pair. The bugfixes will be more complete (because they are challenged by your navigator) and there will be less problem with regressions. Additionally: Two people learn at once what mistake not to make next time and two people can bring their knowhow to the table regarding this specific problem. It’s making a fail a win-win (as far as possible).
Writinglearning a User-story is often done by the product owner. And when the teams first re-views the story, a lot of technical remarks and constraints are added etc. In this situation, the product owner often resembles just to “write these informations down” and is not learning too much. Why? The amount of information that a team of developers generate in a grooming or estimation meeting is just to high in that moment very often. Change this a bit: Stay with the grooming meeting but let the product owner write down the User story together with one of the developers. Just use driver and navigator as in normal pairing and a blank text file. The story will be more dense of information and the additions that have to be made by the whole team a little less.
Coding experimental features to prove that something works is called a spike in XP. Another name for that is a “Research Task”. This is one of the cooler thing and might be very good to do it as a pair. Why?
It would be nice to get some other ideas from you here in the comments section. What is your special way of Pairprogramming?