Abstract

XP is gaining recognition.  Many development managers newly exposed to XP practices are now asking the question:  "Is XP right for me?". Questions abound with regard to resource requirements (staffing, office configuration, tools, culture, training, ...), applicability, and scalability. Setting expectations for both staff and senior management is essential.  This panel will address both the pain and the gain of the transition to XP.   

Format

The format of the session is adapted from a talk show.  The moderator will introduce each panelist who will have a brief opportunity make introductory remarks (three minutes).  The moderator will then go out into the audience to solicit questions for the panelists, occasionally interjecting his own observations and comments, and perhaps asking members of the audience a question or two.  The objective of the panel is to exchange relevant information, views, opinions, and perhaps even stir up a bit of controversy...and of course - have fun!

Panelist Positions and Bios

Ronald E Jeffries:         

"To the death!"  -- Humperdinck
"No! To the pain!"  -- Westley

I suppose most organizations only change when they feel pain where they are. I've seen people go into XP because their old ways were producing bad code, or because they never delivered anything. The gain they expect is generally better software, a more responsive organization, a happier customer.

The pain once you get to doing XP comes at the interfaces. Perhaps your organization really runs on paper, and wants you to produce piles of it before you are allowed to do something. That will slow you down, and there's nothing you can do about it. Perhaps your organization has a separate QA organization that insists on testing things manually. That will slow you down, but there is something you can do about it.

With XP done right in a healthy, engaged organization, I believe there is no necessary pain. This is more than a useless reverse definition of "doing it right". My basic philosophy is this: Pain is nature's way of telling us to try something different. Adjust what you do until it doesn't hurt. To do that adjustment, you need to go back to the basics. That's what XP is about.

Ron Jeffries has been developing software since 1961, when he accidentally got a summer job at the Strategic Air Command Headquarters, and they accidentally gave him a FORTRAN manual.  He and his teams have built operating systems, languages compilers, relational and set-theoretic database systems, manufacturing control, and applications software, producing about a half-billion dollars in revenue, and he wonders why he didn't get any of it! For the past few years he has been learning, applying, and teaching the Extreme Programming discipline.

Robert Martin ("Uncle Bob"):   XP seems like a process made by programmers for programmers.  Indeed, the temptation for programmers is just to start "doing" XP and let the rest of the organization catch up.  I don't think this works. In fact, XP is represents a radical change to the whole organization, not just the developers.  This change upsets existing power and responsibility structures.  Unless the transition to XP is carefully managed across the entire business, it will fail.

Robert C. Martin has been a software professional since 1970. He is president of Object Mentor Inc., a firm of highly experienced experts that offers high level object-oriented software design consulting, training, and development services to major corporations around the world. In 1995, he authored the best-selling book: Designing Object Oriented C++ Applications using the Booch Method, published by Prentice Hall. In 1997, he was chief editor of the book: Pattern Languages of Program Design 3, published by Addison Wesley. In 2000, he was editor of the book More C++ Gems, published by Cambridge Press. From 1996 to 1998, he was the editor-in-chief of the C++ Report. He has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He is currently working in the area of lightweight productive processes and is a strong advocate and supporter of Extreme Programming.

Don Wells   The strengths of XP can all be translated into areas of fear for many people.  The four values translate as follows: Communication translates into social interaction, which makes many people feel uncomfortable. Feedback translates into tight loops and repetition, which can be hard to get going and keep going.  Simplicity translates into highly subjective criteria for success, which makes it difficult to access your own progress.  Courage translates into not making excuses and assigning blame, which many people have based entire careers on.  Of course these are all negative ways to view the 4 values, but that is often the way they are viewed by people facing the real possibility of changing their way of doing things.

It isn't until these people have been experienced in XP that the potential gain can be realized on a personal level.  Many people will avoid the change and run away to another project.  While it has been well documented that after the transition people are happier and feel better about their work it is not obvious to an outsider.  The potential gain is very large, but to get to it you must overcome the resistance to change.

The gain in XP can also be realized by the organization. Knowing in advance when problems arise is critical to avoiding a disaster.  Getting more done is very important to the organization.  Getting the right things done is even more important still. These things are enabled by XP.  It could be argued correctly that XP is not the only enabling methodology.  But XP does enable these advantages and that is the notable point for this discussion.

There is an equal amount of pain for the organization too.  Hard decisions must be made that could be postponed or ignored before.  You can not start a project without the full attention of one of your best people acting as the customer.  You will know early in the life cycle what can realistically be accomplished.  Managers will be confronted with the truth about a given project and many do not like that!  After all what do you do with such information?  Pass it up to the directors?  Admit failure early in the project?  These issues are real in many corporate cultures.  XP is not welcomed there.

Someone who realizes that the current process is not working and needs to make a change is not necessarily ready to change it.  These are two very different things.  It is often difficult and painful to make a change when there is a great deal of momentum behind the current way of doing things even when you know you must.  We are reminded one again that change no matter how productive is painful.

There are also changes that need to be made to realize the full potential of this new way of doing things.  Many people are so glued to their old ways that they make moving to XP more painful than needed.  One of the biggest changes in XP isn't about design; testing or even pair programming it is about attitude. So many people approach XP from the attitude of what must be done. They say to themselves: "I didn't write any unit tests this week I will never catch up." XP is about drawing a line in the sand and saying:  "this where we are now, let's start from here and make a new plan."

Don Wells has over two decades of programming experience. He has built financial applications, military applications, expert systems, cockpit simulators, computer aided engineering (CAE) systems, web sites, and even published a video game. Don has been on projects ranging in size from 1 to 150 people. He has developed custom software to run on large corporate mainframes, shrink-wrapped software for home computers, and everything in between.  He has been experimenting with ad hoc software development methods for many years.  In 1996 he worked on the Chrysler Comprehensive Compensation project followed by the VCAPS project where Extreme Programming was successful applied.  Don has adopted Extreme Programming as his software methodology of choice.

Impresario

Steven Fraser is a senior manager in the Disruptive Network Technology group in Global External Research at Nortel Networks in Santa Clara, California. From 1995 to 1999 Steven was a tech transfer agent within Nortel Networks for software engineering best practices and Chair of the Nortel Design Forum.  Prior to this Steven was a software reuse evangelist at BNR's Computing Research Laboratory in Ottawa, Canada. In 1994 he was a Visiting Scientist at the Software Engineering Institute (SEI) collaborating with the Application of Software Models project on the development of team-based domain analysis techniques. He is an avid operatunist and photographer.