The Agile Tribe

Are two heads better than one?

on January 21, 2010

Authors: Alexandra Hooper and Tammy White

During the graduate program and in permanent positions, we have worked on several projects and are still puzzled by the way in which Business Analysts and Developers are resourced. One thing we have noticed is how pair programming is used as a standard practice amongst developers but not by other disciplines (for example, Business Analysts), particularly given the obvious advantages that pair programming provides in the developer ‘world’, like:

  1. Improved quality
  2. Reduced cost of development
  3. Learning and training
  4. Overcoming difficult problems
  5. Improved morale
  6. Decreased management risk
  7. Increased discipline and better time management
  8. Resilient flow
  9. Fewer interruptions.

With such benefits we wondered why more often than not, is only a single Business Analyst assigned to a project or stream especially within a large program of work? Surely many of the same benefits that developers experience could be achieved through a Business Analyst partnership/BA pairing. So why is this technique not used in the Business Analyst ‘world’?

At a Business Analyst team discussion recently a comment was made around the variation of skillsets amongst the Business Analysts in the room. Each person had different business experiences and knowledge of tools to offer, which could have led to a truly complementary partnership.

So this made us ponder a couple of questions.

  • Can we really expect a single Business Analyst to understand and facilitate the use of all analytical tools on a range of projects?
  • Why stop at pair programming with developers, why not expand such an effective practice across other disciplines on a project like to business analysts?

In summary, are two heads better than one?

Advertisements

8 responses to “Are two heads better than one?

  1. Ed Butler says:

    I have used the practice of pairing successfully when bringing new employees up to speed on product support & processes in our organisation. I can see value in pairing across the board in any organisation. I think we all do it to some degree informally now. Everyone has their own personal strength or area of expertise that can & should be harnessed.

  2. Fiona Mullen says:

    I totally agree with your suggestion about pair programming in the BA space. This approach would certainly accelerate skills transfer and upskilling. Why not trial it and measure the success!

  3. Alexandra and Tammy says:

    Ed,

    It is great to hear that someone has employed pairing successfully in disciplines other than development. We completely agree that we are all doing it informally now, but how much more opportunity is there if rather than one in ten conversations were shared, every conversation is?

    We would be interested to know if you have noticed a significant difference in resource overhead by implementing pairing or if the quality of work being delivered outweighed it.

  4. Alexandra and Tammy says:

    Fiona,

    Fingers crossed an opportunity arises that enables us to trial the practice sometime soon!

  5. Linda Eng says:

    I can vouch for pair “BA-ing” as I previously did that in my last project. Not only do you share the work, but you learn from each other. It’s a fantastic idea but understandably due to factors like other projects and resourcing contraints, having two BA’s on a project can be hard to do.

  6. Ginn says:

    Alex & Tammy

    I totaly agree with this idea – I Yammered this sveral months ago and listeded further benefits of Pair BA/PL.

    Check it

    https://www.yammer.com/suncorp.com.au/messages/23342594

  7. Brad says:

    I think Kelly Waters brings up some really relevants points about pair programming (http://agile.dzone.com/news/pair-programming-extremely) which lends themselves to why pairing Business Analysts is perhaps not so natural. Yes, there are the benefits you talk of in your blog but as Kelly points out – pairing can be just as detrimental if the personalities of the pair don’t mesh.

    One of his final comments is that like many agile development practices, you have to look at the unique circumstances of your team, and understanding these factors, decide for yourself when and if to adopt pair programming and I would suggest pair business analysis. It just might not be the right thing for the projects that your organisation works with.

  8. Alexandra and Tammy says:

    Thanks for the comments.

    It is good to hear that people have had positive experiences using BA pairing.

    We agree that it is essential to not just have the right skillsets working on an Agile project but also have the right people. Every project is unique and Kelly’s article does bring up some great points.

    Pair BA’ing and pair programming is not for every project but if the quality of deliverables and benefits outweigh the limitations then maybe it is worth applying in a safe to fail environment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s