Master
ThoughtWorks
Menu
Close
  • What we do
    • Go to overview
    • Customer Experience, Product and Design
    • Data Strategy, Engineering and Analytics
    • Digital Transformation and Operations
    • Enterprise Modernization, Platforms and Cloud
  • Who we work with
    • Go to overview
    • Automotive
    • Healthcare
    • Public Sector
    • Cleantech, Energy and Utilities
    • Media and Publishing
    • Retail and E-commerce
    • Financial Services and Insurance
    • Not-for-profit
    • Travel and Transport
  • Insights
    • Go to overview
    • Featured

      • Technology

        An in-depth exploration of enterprise technology and engineering excellence

      • Business

        Keep up to date with the latest business and industry insights for digital leaders

      • Culture

        The place for career-building content and tips, and our view on social justice and inclusivity

    • Digital Publications and Tools

      • Technology Radar

        An opinionated guide to technology frontiers

      • Perspectives

        A publication for digital leaders

      • Digital Fluency Model

        A model for prioritizing the digital capabilities needed to navigate uncertainty

      • Decoder

        The business execs' A-Z guide to technology

    • All Insights

      • Articles

        Expert insights to help your business grow

      • Blogs

        Personal perspectives from ThoughtWorkers around the globe

      • Books

        Explore our extensive library

      • Podcasts

        Captivating conversations on the latest in business and tech

  • Careers
    • Go to overview
    • Application process

      What to expect as you interview with us

    • Grads and career changers

      Start your tech career on the right foot

    • Search jobs

      Find open positions in your region

    • Stay connected

      Sign up for our monthly newsletter

  • About
    • Go to overview
    • Our Purpose
    • Awards and Recognition
    • Diversity and Inclusion
    • Our Leaders
    • Partnerships
    • News
    • Conferences and Events
  • Contact
Global | English
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
Blogs
Select a topic
View all topicsClose
Technology 
Agile Project Management Cloud Continuous Delivery  Data Science & Engineering Defending the Free Internet Evolutionary Architecture Experience Design IoT Languages, Tools & Frameworks Legacy Modernization Machine Learning & Artificial Intelligence Microservices Platforms Security Software Testing Technology Strategy 
Business 
Financial Services Global Health Innovation Retail  Transformation 
Careers 
Career Hacks Diversity & Inclusion Social Change 
Blogs

Topics

Choose a topic
  • Technology
    Technology
  • Technology Overview
  • Agile Project Management
  • Cloud
  • Continuous Delivery
  • Data Science & Engineering
  • Defending the Free Internet
  • Evolutionary Architecture
  • Experience Design
  • IoT
  • Languages, Tools & Frameworks
  • Legacy Modernization
  • Machine Learning & Artificial Intelligence
  • Microservices
  • Platforms
  • Security
  • Software Testing
  • Technology Strategy
  • Business
    Business
  • Business Overview
  • Financial Services
  • Global Health
  • Innovation
  • Retail
  • Transformation
  • Careers
    Careers
  • Careers Overview
  • Career Hacks
  • Diversity & Inclusion
  • Social Change
Agile Project ManagementTechnology

Pairing for Business Analysts - Our Story

Jagbir Singh Lehl Jagbir Singh Lehl

Published: Oct 7, 2014

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.

The Basics

  • 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.

Tools and Practices

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! 

Master
Privacy policy | Modern Slavery statement | Accessibility
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.