Final Report...

This final report will not contain final conclusions from my work this summer, because the work is ongoing. I will continue analyzing the data we collected as an independent study course. I will take time to discuss the many things gained from the Distributed Mentor Project.

So the summer has come and gone. Lessons have been learned. Challenges have been overcome; however the greatest challenge lies in documenting the knowledge gained through this experience. How do I begin to relay the information that I have acquired through the various means of communication? Verbal conversation, email, reading books, reading articles, reading notes, attending presentations, collecting survey data, etc are all ways in which I have communicated this summer.

Let me begin by recalling the projects I worked with this summer

• working with the pair programming tool
  
• analyzing the pair programming surveys
  
• writing a tutorial for Rational XDE
  
• making the XP survey robust
  
• attending the Agile Development Conference in Utah
  
• preparing for study with Sabre
  
• collecting data from Sabre

Programming for the tools (Pair Programming Tool, Extreme Programming Survey, Rational XDE Tutorial) required I learn or become very familiar with (or remember from class) JSP, HTML, SQL, UML, database design, Extreme Programming, Pair Programming, etc.

My time here in Raleigh, North Carolina was limited because of the conference in Utah and the study in Dallas. So I was unable to get very far in analyzing the pair programming surveys; however, I was unaware of the problem professors face when it came to cheating. Of course pair programming would have an affect on cheating, but what would it be? Hema is taking this study further. What I was able to pull away was that pair programming is accepted by many, although there remains much skepticism among others. Some people come into pair programming not knowing what to expect. After time they realize that having help readily available is a benefit along with learning from the "expert" of the system. I was lucky enough to see Laurie give her pair programming presentation. The interesting thing was I knew exactly what she was talking about because of the people I had interviewed. I could relate those conversations to her research findings.

The Sabre NCSU XP Assessment Study required much of my time this summer. For this study I familiarized myself with the twelve practices of Extreme Programming. I did this by reading as well as by practicing. Lucas and I utilized the practices while working with the survey site. I learned many things about Extreme Programming while at teh Agile Development Conference. I was able to here how individual companies altered the methodology to fit their situation.

Before going to Dallas, collaboratively Sabre and NCSU decided upon several goals for the project. These goals were derived from the Empirical Study Hypotheses as outlined in chapter 29 of Extreme Programming Perspectives. We reprioritized them based on time and availability of tools.

We established a system used to collect data from teams using XP. This system allows the team lead/coach to set the team's characteristics based on Barry Boehm and Richard Turner's spider chart in "Using Risk to Balance Agile and Plan-Driven Methods" in IEEE Software June 2003. The system also collects all survey data as taken from the developers on the XP team. The user of the survey rates him or her self on how he or she implements the XP practices. The data is taken from a set of drop down boxes which contain values 1-10; 10 being strong XP practices and 1 being weak practice execution.

We graphed the characteristics of each team as well as compared it to the team's XP Index value. We noticed trends that existed in the shapes of the spider charts. These comparisons left questions in our heads about correlations between the practices and the characteristics. After further examination we decided to interview several teams' developers and further analyze three teams' code. The teams we selected to do an in depth analysis of their code, were picked based on the following criteria: diverse spider charts, tool integration, level of automated unit testing, and team size.

At this point we have collected an enormous amount of data; nevertheless there are more items in which we wish to have information about before making any conclusions. The study has really just begun. We plan to pursue a "safe" subset of XP practices; those of which can not be discarded or underused. There lies more examination of the survey results. What correlations can we make between practices? Between spider charts? Between interview results? We will examine the data this fall through independent study.

As you can see my time was dissected among many activities; however it is not as easy to see the wisdom I gained from conversations with people along the way. I was able to learn from my mentor; success comes from hard work but does not have to interfere with your family life. The graduate students here at NC State have answered so many of my questions not to mention were patient with answering them. The Sabre folks were also patient in describing their process and work. What an amazing experience learning from developers using the methodologies I'm learning about.

This document can in no way encompass all that I have learned this summer. I am still processing the activities and conversations. This document is meant to describe in more detail what I have done and experienced while participating in the Computing Research Association Distributed Mentor Project.