I just read a recent article on PMHut called “Schedule Questions: Pair Programming and the PNR Curve“. There is much in this article that is important for agile project management… and much that should be avoided at all costs!
The bulk of the article is an explanation of the PNR curve (Putnam Norden Rayleigh curve). The explanation is sufficient and can be checked against other web articles about software estimation. The basic idea of the PNR curve is to find an ideal number of people with which to staff a project based on an estimate of overall project size (e.g. 72 man-months).
Take a moment to go read Fantasy Estimation (the comments here provide good additional material).
It should be clear now that any initial sizing estimate based on units such as man-months is ridiculous. So what is our alternative? What about an agile approach to estimation and planning?
Well, at a minimum, in an agile approach to estimation, we need to resolve some of the problems identified in “Fantasy Estimation”. So, we:
- Get the whole team that will be doing the work to do the estimation
- We weight estimates based on team maturity, knowledge of tools, knowledge of the business domain and the physical proximity of team members to each other
- We adjust our estimates of work remaining based on our results for work completed
The great thing about an agile approach is that it allows all these things to be done and to be done well. Scrum has a specific set of “Drag Factors” that can be used to weight the team’s estimates. And using a team’s past estimates vs. “actuals” is possible on an iteration by iteration basis… and this is possible because every iteration the team is doing the “same thing”: delivering an increment of valuable results (working software, edited video, organizational change, whatever is contributing to the project goals).
The other thing that agile methods allow is to make a distinction between estimation for planning and estimation for commitment.
So. It’s cool to learn about the PNR Staffing curve and the thinking behind it. It’s a little scary to see it being applied in an agile context when we have tools that are much better.
Pairing and Estimation
At the end of the PMHut article, the author, Mike asks a question:
What about pair programming? When using pairs on a team we could either:
- Continue as is, use the model to determine optimal team size and then encourage pairing to increase efficiency.
- Treat a pair as one hyper-effective person, so count pairs not individuals and increase team sizes accordingly.
This second option seems counter intuitive to agile, we strive for small teams to reduce communication channels, so I’m not convinced by this idea. I would be very interested to hear people’s thoughts on agile staffing curves. So, lots more questions than answers in this post, please let me know if you have any research or thoughts on the matter.
I wrote in response:
Mike, I feel like the options you present in your question at the end actually miss the true point of pairing which has to do with communication. I have never seen pairing done in such a way that two people always work together as a pair. Rather, pairing is promiscuous: people switch pairs frequently throughout a day, iteration or project. This switching has two communication effects: 1) the human interaction and gradual diffusion of information as people switch pairs 2) helping everyone understand all parts of the work as a result of frequently working on many different things. From an estimation standpoint, I expect that neither of your two options is quite right. Rather, the third option is to continue as is with existing estimation and then encourage pairing to increase communication. Increased communication shows up in a number of different ways, not just efficiency: risk mitigation, accelerated individual and team learning etc.
I would like to expand on this just a little. To me, pair programming or pair work of any kind has always been able to provide a number of benefits to projects. Problem avoidance is one benefit (lower defect rates, better code quality through constant inspection, spotting each other). Better communication is another benefit. Increasing the Truck Factor is yet another benefit.
None of these benefits have any direct bearing on estimating a project at the start, particularly since most projects sacrifice quality for schedule. From an agile perspective, since planning estimation is not commitment, it actually doesn’t even really matter! Get a conservative estimate for you project using whatever method you like, then start working and get a commitment velocity and see what the team can really do.