Agile – Pair Rotation in a team for effective pair programming

This might be controversial but here it goes!

We have worked on a real time systems where one of the past bosses of mine suggested that let's do AGILE! It was easy to win management on that really; however, it was easier said than done.

The concept of stories is good - but to be very upfront, it is quite vague. What is a story, really? The real issue is that using stories alone (and much the same holds for Use cases as well) have several issues - as follows:

1. Requirements cannot be out of context (unless you are making gross repetitions so many times). There are assumptions, background knowledge and other requirements which are linked too a given requirement; they make sense only under a context and only under a specific order. Implementing most important one first makes business sense but when you file them at least - keep a complete referencing right from the beginning when yo collect them. Requirement word itself is complex and is not really limited to Use-Case / Stories. Indeed stories are actionable, but then there are requirements that may not be actionable, such as performance, constraints to be met, business rules etc.

2. Requirements needs to be appropriate in size and in quantifiable manner else you can never have a need for more than 1 large story! What forms exactly 1 story?

   • is it one full detailed scenario? (e.g. one story when ATM rejects a transaction)
   • is it one set of action that user performs? (e.g. full story about withdrawal)
   • or is it one screen in the user interface? (e.g. withdrawal screen as a full story).
   • How do really quantify very crisp business rules with stories? Honestly, it can be any of the above. The point is how much confined and granular you go is quite a personal style. If it works -it is fine;

3. Domain knowledge is really requirement! A simple example, of an Architect who knows various properties of Glass, Steel and Wood. this knowledge is not part of the requirement document for the building per say! Same way, if you are writing a banking software - there are whole bunch of concepts about banking. Stating them, as Requirement itself makes it non-tractable because it doesn't tell you what should software do as opposed to how the world works. Does story includes such domain intricacies? or does it exclude this?

4. Modeling the world is prerequisite not quite supported by.
   There has been a lot of literature on Modeling which focuses on just understanding how the world works is a background knowledge. Modeling forms firm foundation on which requirements gain clear meaning; however such a thing should be upfront. Unfortunately, most of the agile practices refuses value in upfront modeling in the interest of quicker and leaner deliveries; but that i still think is a major show stopper when things has to scale. Many project do succeed not because modeling is irrelevant - but seasoned engineers know them in their head and doesn't need much explicit guidance.

So coming to your question:

Is writing specs based on stories a good idea? Have we written the stories in the wrong way?

I think user stories does have value as explicit verdict given by customer. But if they are poorly organized and insufficiently detailed (or vague) there is a problem. Unless you have a larger structure to accumulate the broader understanding (domain knowledge) and scope (total spec). User stories only for segments or elements within larger such system.

PS: I have exact opinion about Use cases (as they are depicted in oval diagrams) that unless you put them in appropriate context and at appropriate granularity they don't do any good job. (I call them useless cases). The only credible source i find to make Use case writing truly scalable and meaningful is Writing effective Use cases by Cockburn

Partly, it depends on how you are doing pair programming. In some instances, the driver of the pair is writing code, while the second member of the pair is observing and discussing the design and implementation details of the system. Another instance of pair programming involves both people writing code simultaneously - one person is writing the implemented functionality and the other is actively developing and writing test code at the unit and integration level, again discussing the design and implementation details of the system.

Regardless of the type of pair programming, it effectively serves as a continuous code review. You have two people's eyes on the code, watching for errors before they escape into a later system/acceptance testing environment or the field. You also have two people who understand a particular part of the system very well, to serve as a redundancy to minimize your bus factor. Both catching defects early and spreading system knowledge around the team reduces the cost of building a system.

The spreading of knowledge isn't just limited to the technical knowledge of the team, either. Depending on who the pair is, it can allow for information to flow between a more senior member of the company to a new member about other things that transcend the project - coding style, company culture, expectations, and so on. It can also allow someone who is more familiar with a technology or tool to share their knowledge in that technology or tool in a real-world applied setting.

As you mentioned, it also does help keep developers focused and in flow. In addition to flow, many individuals are less likely to interrupt multiple people working on something than a single individual working on something. If you walk by someone's desk and they are working alone, but you need to talk to them, you might knock and talk to them. This is less likely if you see two or more people collaboratively working or having a discussion - you won't interrupt them. Interruptions cost time, and spending more time means higher costs. It's in the best interests of the business to maximize productivity of the employees.

However, there are some challenges that must be overcome to make pair programming viable. Consider things like personality clashes or choosing the pairs to properly distribute the knowledge. There's also consideration of exactly when to rotate pairs. Pair programming done haphazardly probably won't be effective as one that's planned out. Depending on the makeup of your team, it might not be effective to pair people at all.