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
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/