Monday, 23 June 2014

EXTREME ANALYSIS - Pairing for Business Analysts

Extreme Analysis in action
Pair programming has been used by software developers in most progressive software companies to help churn out quality products and to ensure that context is shared across the teams. For the uninitiated, traditional pair programming (in short) 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 brains trying to solve the problem and as one person writes the code, the other continuously reviews it, thereby eliminating the need to have separate code review sessions. Also, if the pair has worked efficiently then any mistakes in design have been caught upfront, thereby eliminating any waste caused by defects which would have been discovered at a later stage. This concept has mostly been applied to the working of software developers and other roles have not quite adapted it, as yet.

Why is this important? - Business Analysts (in general) are used to working in an individual capacity since most team's have a single BA, and a lot of analysts find it hard to work with other analysts in an amicable manner. My guess is that since there is a dearth of opportunities to work with other's, the skills to work with others does not get the opportunity to blossom.

“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.”

My primary role is of a Business Analyst, and I had wanted to share my experiences on the projects that I executed at ThoughtWorks, where I was able to pair with the other BAs with some level of success. This piece is my attempt to not only share some of those lessons and experiences, but hopefully also generate some healthy debate/discussions.

The Basics

Before we go into any specifics of how to pair as Business Analysts we need to first 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 from the individuals in question
  • Mutual Respect
  • Equal sharing of tasks and responsibilities
  • Leverage on 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
  • Personal Hygiene, since the expectation is for both to sit in reasonably close proximity to each other, personal hygiene will be an important factor. :-P

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. I hope to tie the practices we used and make my case for "EXTREME ANALYSIS".

Daily Sign-ups - The day generally starts with a stand-up where the entire team participates and thereafter programmers, quality analyst and Business analysts sign-up for their tasks. Its 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 then it makes sense 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. Its web-based, free to use, and simple as hell.

Story Detailing - This is the most significant task that BAs undertake and pairing here can help to 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 in brief 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, Business Analysts 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 atleast 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 and 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. Its 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 of the BA's 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.

No comments:

Post a Comment