Pair programming has been used by software developers in most progressive software companies to help churn out quality products and ensure that context is shared across the teams. For the uninitiated, traditional pair programming is a practice where 2 programmers work on developing a piece of software functionality in tandem.
This practice helps improve code quality, since you have 2 sets of eyes and minds trying to solve the problem. As one person writes the code, the other continuously reviews it, thereby eliminating the need to have separate code review sessions. If the pair has worked efficiently, mistakes in design get caught upfront, thereby eliminating any waste caused by defects which would have been discovered at a later stage. The concept of pair programming has mostly been applied to the working of software developers. Other roles haven’t quite adapted it yet, but if applied, pairing may prove to be useful in other scenarios as well. My primary role is that of a business analyst (BA) and I want to share my experiences where I’ve paired with other BAs to a fair degree of success. This piece is my attempt to not only share some of the lessons I’ve learnt, but also hopefully generate some healthy discussions around this concept.
Pair programming for business analysts - why is it important?
Business analysts (in general) are used to working in an individual capacity, since most teams have a single BA. In fact, a lot of analysts find it hard to work with other analysts in an amicable manner! This is mostly because business analysis is not an exact science and there are multiple ways to achieve the stated goal. My guess is that since there is a dearth of opportunities to work with others, the skills needed to work with others doesn't get developed easily.
"Business Analysts, User Experience (UX) Analysts, Project Managers, and (to a lesser degree) Quality Analysts are used to working alone, and may need to work out how to deal with situations where they too need to collaborate among the community, and deliver.”
The Basics
Before we go into any specifics of how to pair as Business Analysts, we need to get some basics right.
Any successful working relationship needs to have these elements at the core, the absence of these will render any attempt at pairing to be futile.
- Commitment to work by the individuals in question
- Mutual Respect
- Equal sharing of tasks and responsibilities
- Leverage each others’ strengths and work around the rough edges.
- Willingness to take feedback from each other and work towards improvement
- Helping each other through personal time-offs by temporarily taking ownership of tasks
- Ability to share a laugh and work through stressful situations
- Sitting in close proximity is common for pairing practices, so brownie points for good personal hygiene!
Pairing Practices
When we look at business analysis in an agile project, the following tasks would generally have to be undertaken on a day-to-day basis.
Daily Sign-ups - The day generally starts with a stand-up where the entire team participates and thereafter programmers, quality analysts and business analysts sign up for their tasks. It’s important that the BAs get together and list down the tasks that they intend to pick during the course of the day and sign up for them based on an equal distribution.
This activity is important, since there can be multiple things (other than story detailing) that need to be addressed during the day - like responding to emails sent by the customer, escalating blockers, reviewing analysed stories etc. And these tasks need to be identified and responded to as a team.
Tools/Practices: When the BAs are co-located, it makes sense for them to sit next to each other and list the tasks on a notebook or stickies and striking them off as they get done. However, when the BAs are working in different timezones (or geographies) then apart from a 15-30 min daily catch-up, the sign-ups can be managed via a lightweight task list manager like Trello.
Story Detailing - This is the most significant task that BAs undertake and pairing here can help set a mutually agreed direction that the BA detailing the story can take.
Tools/Practices: The tool being used here is the most effective one i.e. conversations. The BA who has taken the ownership of a feature will explain the approach that he/she plans to take and solicit inputs from the other BAs. This ensures that context is shared and also helps build a better story right upfront (fail fast).
Story Review (Internal) - In Extreme Programming, programmers use peer review to ensure that the coding practices are being followed. Keeping in mind the same principles, BAs should get their stories reviewed by another set of eyes just to make sure that all the bases are covered.
Tools/Practices: Ensuring that all stories (especially the complex ones) are peer reviewed by at least one business analyst to capture any obvious omissions/errors.
Story Review (with Customer) - Stories need to be signed off by customers before they can be picked up by programmers. These meetings can be managed better if you work as a team. If the BAs have followed the earlier steps, they will take a uniform message and present a unified voice to the customer.
Tools/Practices: Having feature kick-offs, where as a team you present the outline of the requirement and get inputs from the customer.
Iteration Planning - The stories that need to be picked in the forthcoming iterations need to be planned and communicated to the customer. It's important that this activity takes into account the dependencies and priorities that are associated with the stories and features.
Tools/Practices: Rotate the responsibility of creating the iteration plan among the BAs and then review the plan that has been set forth as a team. Again, this helps get inputs from a larger group and in the absence of one of the BAs, the others can take over the iteration planning meeting with the team and/or customer.
Difficult conversations - When we talk about scope and prioritization with customers, there is always the possibility of conversations turning hostile, especially if the team is set up in the onsite-offshore model. Added to this is the fact that customers can be very direct, demanding and (sometimes) just plain uncooperative. All this could lead to frustrating conversations which can test the BA's patience, communication, and negotiation skills.
Tools/Practices: If one BA is feeling particularly frustrated and bogged down by the conversations and not able to respond in a calm and composed manner, which is a perfectly natural feeling to have in such tense situations (maybe it's just not their day). The other BA should have the ability to sense this and attempt to bring the calmness and logic back into the conversations. This obviously means that the BA who is not able to respond in a calm manner should back off and let the other BA lead the discussion this time around. Good teamwork requires people to understand the personality (and mood) of their colleagues and support them adequately.
I've found pairing for business analysts to be very rewarding. If you've tried any of these methods, let me know how it has worked!