What's so eXtreme About Doing Things Right?

This is a Panel Session for OOPSLA 2003, October 26-30, 2003, Anaheim, CA. This is a modified version of the panel description that appears in the OOPSLA 2003 Companion. Panel participants:

ABSTRACT

Agile Methods are advocated as a way of producing better software. Advocates of agile methods suggest that practices such as keeping in close communication with your customers, frequent integration, and frequent assessment of project status will enable us to produce software that has value for the customer - quality software. It's hard to argue with that. But why is this any different than simply "good" software development practice? Why does saying "Scrum" "Agile" or "XP" grab peoples' attention? Why does it take a name for useful practices to be accepted?

This panel will help us understand the role of hype in getting useful practices accepted or rejected. We will explore why it is that these good ideas have not been more widely used. Some of the questions that the panel and the audience will explore are: Why do we ignore proven practices until we see them packaged as a "method?" Can we do something different in the workplace or in school to teach these practices? Or is it the case that these practices are not universally good?

This panel talks about agility in a different context than what is typical: we won't just discuss what agile practices are. We will explore why they are not more widely adopted, especially when not packaged as part of a "named" method like XP. And we will discuss why projects suffer even when the methods that can help them are well known.

This panel will provide an entertaining and thought provoking forum for discussing an issue that is ever present in the world of technology: the role of hype. We concentrate on agile practices, moving beyond simply enumerating them, to discussing why they are not more widely adopted.

Panel Description and Position Statements

Steve Berczuk, steve@berczuk.com

Steve has been developing object-oriented software applications since 1989, often as part of geographically distributed teams where flexibility and agility were essential. He has been an active member of the Software Patterns community since 1994 and has published a number of articles on the relationship between organization, software architecture, and design patterns. He has an M.S. in Operations Research from Stanford University and an S.B. in Electrical Engineering from MIT. Steve is the author of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration, published by Addison Wesley (www.scmpatterns.com), which is about software configuration management in an agile environment.

Steve wonders why some projects fail because they don't use practices known to be effective, and why others fail because they use "hyped" processes inappropriately. This panel presents an opportunity to have an interesting and productive discussion on the role of hype in acceptance and rejection of effective techniques. Between the contributions of the panelists and those of the audience this panel should be informative and entertaining.

Neil Harrison, nbharrison@avaya.com

Neil Harrison is a researcher at Avaya Labs, where he consults with software projects in software architecture, process, organizations, estimation, and product line engineering. He has studied the application of agile development methods in large organizations, and has practiced agile software development. He has been involved in software patterns since 1994. He has organized pattern conferences and has taught many courses on patterns, especially in the area of pattern shepherding. He is currently a member of the board of directors of the Hillside group. He has published patterns and articles in several pattern books, and was the lead editor of Pattern Languages of Program Design, Volume 4.

Neil sees many attitudes towards agile methods, and two of particular interest: One camp has been doing agile practices for years, and wonders what all the fuss is about. The other camp sees that not all practices are appropriate in all situations, and correctly asks, "What's so right about doing things eXtreme?" These are two of several reasons that agile practices aren't adopted: first, that they are already being done, and second, that they sometimes shouldn't be done.

Kevlin Henney, kevlin@curbralan.com

Kevlin Henney is an independent consultant and trainer. The focus of his work is in programming languages, OO, CBD, UML, patterns, and software architecture. He is a regular columnist for Application Development Advisor (UK), JavaSpektrum (Germany), and C/C++ Users Journal online, and a former columnist with Java Report and C++ Report. He is also program chair for the EuroPLoP 2003 conference, a member of Hillside Europe and the OT conference program committee, as well a regular speaker at conferences in the US and Europe.

Kevlin's position on this issue is that if practice makes perfect, the absence of practice is one of the main problems that many companies, projects and individuals seem to be suffering from. Sometimes it feels like companies would rather adopt practices in name only, leaving adoption in deed as an irrelevant implementation detail.

Joshua Kerievsky, joshua@industriallogic.com

Joshua Kerievsky has been programming professionally since 1987, and is the founder of Industrial Logic (http://industriallogic.com), a company specializing in Extreme Programming (XP). Since 1999, Joshua has been coaching and programming on small, large and distributed XP projects and teaching XP to people throughout the world. He is the author of numerous XP and patterns-based articles, simulations and games, including the forthcoming book, Refactoring to Patterns (http://industriallogic.com/xp/refactoring)

Joshua's perspective on this issue is that long before the agile hype, small numbers of talented teams and organizations successfully practiced agile processes. Yet we never heard about their successes. Large-scale, agile development adoption only occurred after the world inherited simple, concise explanations of the magic. We remain indebted to such authors to this day.

Linda Rising, risingl@acm.org

Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching experience as well as work in industry in the areas of telecommunications, avionics, and strategic weapons systems. She has been working with object technologies since 1983. Linda is an independent consultant who helps organizations get started with agile methods, especially Scrum

She is the author, with Mary Lynn Manns, of the book Fear Less and Other Patterns for Introducing New Ideas into Organizations, and is the editor of A Patterns Handbook, A Pattern Almanac 2000, and Design Patterns in Communications Software. She has a number of publications including: The Scrum Software Development Process for Small Teams, IEEE Software, July-August 2001, Agile Meetings, STQQE, July/August 2002, and The Role of Product Champion STQE, March 2003. These and other articles are available on her web site: lindarising.org. She is a regular contributor to the DDC-I On-line Newsletter: ddci.com/news_latest_news_archive.shtml.

Linda sees some instant successes and some slow adopters. Some teams want to say they're agile--they get caught up in the hype -but just keep on doing development as usual. She keeps learning about what works well and what should be done differently with each experience.

Ken Schwaber, ken.schwaber@verizon.net

Ken is one of the developers of the Scrum agile process and is an author to the Agile Manifesto. He is currently Chair of the Agile Alliance, has presented at numerous conferences and user groups, and is author of Agile Software Development with Scrum with Mike Beedle. Ken has developed, managed and consulted about software development for over 30 years.

He is concerned as Scrum and Agile move from the early adopters to the mainstream that it retain its vigor, integrity, and utility. Similarly to CMM, he has more frequently been hearing of Agile users that are agile in name only.

Bobby Woolf, woolf@acm.org

Bobby Woolf has been developing multi-tier object-oriented business applications for thirteen years using Java/J2EE, Smalltalk, and embedded systems for messaging, workflow, business rules, and persistence. He is a co-author of the new book Enterprise Integration Patterns (www.eaipatterns.com) from Addison-Wesley. He became focused on writing and using patterns after watching projects fail for lack of simple, well-known solutions. Now he's seeing projects fail for lack of simple, well-known practices.

Kent Beck said it best, quoting Ron Jefferies, "XP is what programmers do in their own natural environment." As my friend Randy Stafford is fond of saying, "Why should we debate what the machine will do best? Why don't we ask the machine what it does best?" As developers, we know when we're making progress. And customers can see when we're making progress. When we don't know how well the machine will make progress, try something and see how it goes. The problem with XP is that it relies on doing what works, regardless of the consequences, and that is not in fact the goal of a lot of organizations. The question to ask is: Which is more important, doing things your way, or producing good software?