eXtreme Programming: "extreme" or battle-tested?

Most people in the software industry would probably agree that managing the process of software development can at times be more challenging than building the actual software. Weird and wonderful things have happened to teams where the technical and the managerial parts spoke different languages. Bridging this gap and having efficient processes was the the theme of "eXtreme programming in practice" by Neal Ford and it was a tour de force describing the sometimes irrational forces affecting the profession of a software developer.

Neal's talk made a bold promise at the beginning: to show how to selectively replace some of the benefits of extreme programming (XP) while at the same time retaining some of its benefits.

According to Ford, one of the best way to retain the benefits of XP turns out to be not trying to make it less "extreme". (What is "extreme programming" anyway? From a manager's perspective, it could as well mean dealing with programmers with extreme body art. Not a very corporate-friendly image, and therefore, according to Ford, an unfortunate name for a software development methodology).

If this sounds paradoxical, consider that XP is simply "things that worked, pushed to the extreme" and as such they have a well-defined structure. Trying to make XP more "pragmatical" doesn't work unless one maintains the structure of the process: the many nested iterations, the smaller feedback loops within the larger feedback loops that eventually constitute the entire process. Take away the structure and you'll likely to harm the outcome!

Another nugget of information was how to better manage the estimation process (accurate estimation of the duration of a software project is one of the Very Hard Things of software development). The solution offered by Ford is:

A) Don't ask developers "how long will it take you to complete this". Ask instead: "how complex is it, within the domain of the given system". Then, let the Project Manager convert this complexity estimate into a realistic time estimate using a number of well-defined load factors.

B) Use well-defined, quantifiable metrics to arrive at the load factor. To this end:

   1) Define what it means to "be done";
   2) Use a binary completion convention, i.e. either you are 0% done or 100% done.

C) Track down and adjust these metrics constantly, so that you are continuously getting data about the their accuracy.

Lastly, some insights about Pair Programming. PP is valuable to the industry because it has a solid physiological justification: even when programming alone, one works both with the logical / analytical part-oriented view of the problem (left-brain activity) and the intuitive / synthesizing / whole-oriented view (right-brain). So PP is merely an externalization of these two ways of approaching an assignment, with two programmers switching roles to act as the "left brain" or the "right brain" interchangeably.

All in all, an enlightening and valuable talk rooted in considerable industry experience.