“Keeping you up to date with everything software engineering!”

XPDay Toronto 2005 Review

Conferences | February 23, 2005 | 3 comments

In my quest to become an honorary software engineer, I decided to attend (i.e. pay for) the XP day event held in Toronto this past February 19th 2005 and hosted/organized by J.B Rainsberger, the author of Junit Recipes: Practical Methods for Programmer Testing. J.B. was also a keynote for CUSEC 2005, where he gave an excellent opening keynote speech and played Texas Hold’em valiantly in room 907 on Saturday night.

To be honest, I was becoming a bit hesitant in the days leading up to the event, as I was unsure if the conference was really for me. To provide a bit of background, my main focus within the software realm is:

1. How software can make businesses more effective.
2. Explaining to executives how software can make their businesses more effective.
3. Usability and requirements analysis.
4. Managing the customer during development (high-level project management, customer feedback).

Hence a conference about XP development practices might not be suited for someone like me. But following a call with J.B. whereby I asked him “Will it be worth it for me to come to the conference?” and “Am I better off continuing to read about this stuff?” After taking the time to explain how the conference would be worth my while, I decided that I would take a chance and attend.

The day started with a keynote speech from Ron Jeffries, co-author of “Extreme Programming Installed”, entitled “Where is Extreme Programming going?” This really should have been entitled “Where is Agile going?” He asked the audience for Agile methodologies that they knew about or worked on. Methodologies that were focused on were XP, Scrum, Lean, DDD, and Crystal. He then went on to talk about each of these methodologies and pointed out that the goal of each of these methodologies is essentially the same: To develop effective software with predictable and reliable deliverables. He closed his talk by advising us not to blindly follow one practice over another in the sake of allegiance, but rather be open to all practices so that, on a per-project basis, we could develop the most effective software development methodology as it relates to the needs of the project in question.

Robert C. Martin, author of “Agile Software Development: Principles, Patterns and Practices” kicked off the tutorial sessions with an introduction to XP. He started his session by explaining that current popular software development methodologies can achieve only 3 out of the following 4 characteristics:

• The software project can be developed well.
• The software project can be developed quickly.
• The software project can meet the budget.
• The software project can be considered completed.

He then went on to give us a history of software development methodologies, most notably, the 2167 and 2167a software development methodology, more popularly known as the waterfall and iterative waterfall methodology respectively, developed by the department of defense in 1970. He then pointed out that of the $37B worth of DoD projects using 2167:

• 46% of the projects were never used.
• 20% required extensive rework.
• 34% were successful.

He also referenced a study performed by Fred Brooks which studied the production value of 400 software projects that were developed using waterfall. The study showed that only 5-15% of the code developed under the waterfall methodology was actually used in production. He went on to explain that the major problem with the waterfall software development process was based on the faulty premise that humans are good estimators.

To overcome our natural trait of poor estimation, he presented XP’s planning game. The planning game works essentially by gathering the stakeholders and the development team having them sit down in a meeting room together. This should be done once the project is ready to be kicked off. All the features of the project are listed on individual cue cards. A total story point value is then assigned whereby all the cue cards should add up to that number. To help explain the XP planning game, we used the example of an ATM machine. Suppose the total number of story points was assigned to be 80. The first cue card is given a story point assignment, without being based on any criteria. Suppose the first feature was login. The development team would deliberate and call it a 3 (although no criteria is used, often the fallback is degree of difficulty). The next card was logout and it was assigned a story point value of 1. The next card was deposit and this was assigned a story point value of 6. The process continued until all features were assigned with story points and the sum of all story points equaled 80. Ideally, the development team would then go back to all the features and justify or adjust the assigned story points for each feature, as each assignment is relative to the others.

For the first week of development, you pick a random number of story points to be completed. In this example, we used 40. You then ask the stakeholders which 40 story points they would like implemented. Bob explained in his experience, stakeholders would pick the features that were most important and cheapest to implement. During the first week of development suppose only 30 story points were completed. During next week’s planning session, you ask the stakeholders to only pick 30 story points to be completed. Essentially, the only week where you do not complete all planned work should be the first week. Over the course of the project, you should be able to determine the velocity of your development team. Velocity is basically story points/deliverable cycle. You should also be able to develop a story point burn rate chart. By providing these charts to managers of the project, they are presented with enough information to actually manage the project and steer the project so that it meets the Company’s business objectives.

Overall, this was a very interesting and entertaining tutorial session. The planning game can even be used in non-development projects and I have already started using it in the management of my professional tasks.

The next tutorial, Estimating and Planning, was held by Mike Cohn, author of User Stories Applied: For Agile Software Development. This was a bit repetitive of what Bob spoke about as Mike talked about the XP Planning game. Concepts he spoke about that Bob didn’t were:

• Archetypal programmer: To provide an initial estimate on the project to a customer, Mike suggests that the project manager estimate the story points based on the ideal developer. This is a developer that is an expert with your development environment, company practices, fits with the corporate culture and is an excellent developer. In his experience, Mike has found that estimating this way is more accurate as you don’t ask any of your developers to assume ownership of a particular development assignment.
• Make sure there is a justification for each story point assignment: Can you distinguish a feature that was rated a 17 from one that was rated an 18? To overcome indistinctive assignments, Mike recommends using the Fibonacci number series (1, 2, 3, 5, 8, 13, 21…) All in all, the tutorial was about the planning game and unfortunately for Mike, Bob had already covered a lot of the points discussed.

Following lunch, I attended an open space session. The format for Open Space at the conference was that anyone could suggest a topic and post it for people to sign up to the session. The person who suggested the topic had to keep track of the issues discussed and at the end of the session, had to report in the conclusion of the session. The first session I attended was entitled “How to integrate non-developers into an XP development team”. The topic was interesting, but one thing I found was that the person who suggested the topic basically presented to us his own ideas on this topic and very few other people actually spoke. One person in our session from BEA actually chewed out a participant on how his comment was irrelevant to the discussion. Open space is about open communication and that comment, even though not addressed at me, totally turned me off. The good thing with Open Space is that you are free to walk around and jump in and out of other Open Space sessions, which is exactly what I did. Another session that was running concurrently was about planning. The one thing that struck me right away was the exchange in dialogue. Interestingly enough, all participants, including the topic creator, were seated. We had some really great dialogue in this session and I actually got to talk with Ron Jeffries and Bob Martin about techniques on improving velocity (I asked questions, they gave answers). All in all, I really enjoyed the open space session.

After the open space session, there was still 1 hour to go until Mike Hill’s presentation on Transitioning to XP. So after speaking to some locals, I ventured into the project room where J.B. and friends were in the process of developing a Texas Hold’em application. It was pretty cool watching everyone at work and the communication between the different development groups (all in pairs) was astounding. It really reminded me of my university days, where group communication was always incredible and it seemed as though you always got things done faster. Having never experience an XP development environment, it was beneficial for me to have received a sample of the workspace and work processes in place.

Onto the final tutorial of the day. Mike gave an excellent session on transitioning to XP. A lot of this tutorial was aimed at techniques for getting management to buy into XP and Mike’s own personal experience on convincing management to make the necessary changes to open up channels of communication. The points that I took away from this talk were:

• XP can not work without Open Space. The first step in implementing XP is drastically increasing communication. Be it by relocating everyone so that your team is sitting within close proximity of each other or if your office manager is resistant, get everyone together and work in the conference room. Essentially, do whatever you have to do to increase and allow for uninhibited communication.
• XP can not work if you have poor developers. In Mike’s experience he has found that a significant amount of time is often spent on re-training developers to produce production quality code.
• When implementing XP, take the time to eliminate the repeated time consumers. For example, builds. Although it may take some time to develop an automated build process, the efficiency your team gains will easily outweigh the initial development cost. Developing an automated build will encourage your team to build each time a change is made to the code. An excellent closing tutorial and personally, I can’t wait for his book to come out, “Transitioning to XP”.

All in all the conference was fairly informative, but what was really beneficial for me was that I got to experience a lot of the XP practices in person. I also learned how to play “Go”. Now to apply these concepts…

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

February 23, 2005 07:08 PM | Louis-Philippe Huberdeau commented:

Very interesting and complete review. Thanks for sharing.

The fun part about Agile is that it’s the total opposite of the software development stereotypes. Having everyone together in a room to communicate is the opposite of the guy coding in a cubicle.

February 24, 2005 10:24 AM | Anonymous commented:

I agree, very interesting. I have my doubts about XP, i can’t see why it would work well i real life. I think I have this idea because I only worked in an environnement with unexperienced developers. “XP can not work if you have poor developers. In Mike’s experience he has found that a significant amount of time is often spent on re-training developers to produce production quality code.” Now I see that it may be a prerequisite for XP to have efficient developers. (i.e people that also do not need to read the doc every now and then)

February 26, 2005 02:15 PM | Niraj Khanna commented:

Anonymous, during Mike Hill’s Transitioning to XP, he did mention that it is far easier to work with developers who are bad and “moldable” than those that think they’re awesome developers (except when they actually touch code it turns rotten). How bad were the developers in your team? If you have a few strong guys that adopt XP and if you actually start pairing with the weaker guys, 1 of 2 things will happen: 1) The weaker guys will improve or 2) Natural Selection will take place and the weaker developers will leave the project (unless you have management that doesn’t care about efficiency).

The beauty with XP is that you can practice it yourself (even if no-one else is). Test-driven development, refactoring, keeping your code in an executable state are all things you yourself can do on a regular-basis.

I’d love to hear why you don’t think XP will work in a real work environment. A lot of the practices are simply aimed towards eliminating ineffective development practices.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)