The Community Blog for Business Analysts

FergalMcGovern
FergalMcGovern

Moving to Agile Documentation – why ‘Pair Inspections’ make sense

One of the more controversial techniques fostered by some in the agile community is ‘Pair Programming’. It is a practice that originates from Extreme Programming, a specific Agile process pioneered by Kent Beck.

It is controversial, particularly for larger corporates because it seeks to adjust human behaviour patterns. In Pair Programming, developers sit side by side, sharing one machine and working in teams of two at all times on a single code base. In reality, it is one of the agile techniques that is likely least adopted and most controversial among programmers for a variety of reasons, mostly cultural and behavioural in nature. Most fundamentally, for a team to be successful at pair programming takes a lot of hard work. It’s a bit like a marriage really, personality compatibility is a key pre-requisite and just like marriages, the best work well but not all will be successful.

Pair Programming in Action

Pair Programming in action

The point of this post is not to get into the specific argument as it relates to agile developer activities for code, but rather to propose something that Project Managers and Business Analysts should actively consider for documentation and that is what I will call ‘Pair Inspections’ or PI.

The issues I have found with larger document sets in lager initiatives, especially larger documents such as BRDs and Detailed functional specifications and Test Plans is that they are:

  • generally authored by one and only one person with one vantage point
  • are worked on for a concentrated period of time by one person
  • do not combine the considerations of other relevant stakeholders
  • if inspections are going on, they are at a particular point in time, typically at a phase gate and are not that effective at spotting real issues. Infrequent code inspections suffer the same fate in my experience, if I reflect on my time running engineering teams

Now, I am not suggesting that we have co-authoring sessions for a single document. The nature of MS Word and the fact that many people are distributed make this in many cases impractical.

What I am suggesting however is that documents are reviewed actively & informally as part of the authoring & document production cycle. Let me suggest some simple measures that would achieve this:

  • Frequency: Conduct a Pair Inspection once a week. This may be ‘analysis phase’ in waterfall, or pre-sprint stage in Agile
  • Alternate stakeholders: Every other week try to include a stakeholder who wears a different hat, e.g. pair a BA with a Test Lead, pair a BA with a PM
  • Distributed Teams: For distributed BAs working in remote locations, use collaborative tools such as webex, gotomeeting or livemeeting.
  • Consistency: Put a solid recurring meeting in your calendar every week at the same time and take it seriously
  • Informality: Make pair inspections a way to gel stakeholders. Don’t impose rules but let the inspection process ‘self-organise’

The net effect is that substantially better documentation results when active & collaborative inspections and reviews occur, regardless of whether you are in a waterfall or agile environment.

Applying the above simple steps tightens document quality in very material ways.

------

Fergal McGovern, Founder VisibleThread.

See our main blog at: http://www.visiblethread.com/blog/

This entry was published on Nov 03, 2010 / FergalMcGovern. Posted in Project Management, Business Analysis, Leadership & Management, Agile Methods, Roles and Responsibilities, Tools. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  31 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
12 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC