Thursday, 7 November 15:30-17:00 Exhibit Hall 4B
To Be Extreme, or Not to Be Extreme
Moderator: Steven Fraser
eXtreme Programming is built atop a canon of 12 software engineering best-practices. Debate continues on the necessity of application of all 12 practices for the success of a project. Heresy (methodological differences) persists in the community on the subject of missing practices, i.e. teams that have reported success while not embracing all XP practices.
This panel will provide a lively, informative, highly interactive session to debate differences and similarities in approach. Audience members will be interrogated at regular intervals for their opinions and observations. Panelists come from a variety of contexts (corporate, consulting, and academic) to share their opinions, biases, and experiences. The panel will be pair-moderated by Steven Fraser and Rachel Reinitz.
Kent Beck Three Rivers Institute
We are looking down into a pool of water. Clouds are reflected in the water. We recognize shapes in the clouds we see. Along comes a gust of wind and ruffles the water. The familiar looking cloud shapes are now distorted beyond recognition. What really matters is what really good people do to participate in really successful projects. These behaviors with differ wildly with context. Some few features are consistently recognizable, like values. Others seem to contradict each other. In my mind as we began XP as a physics experiment, where you remove all the variables possible so what you're left with is repeatable. Some of the usual variables we eliminated:
Having done this, we succeeded wildly using a set of practices that no one (including me) thought would work. If this were physics, we would then start re-introducing variables to see which ones are actually significant. We (the community) have done this un-self-consciously, because the nature of the experiment was never made clear. One point of genuine disagreement is which of these variables (or combinations of variables) are actually significant, in the sense that they would change the practices required for success. Kent is learning about holes in his programming technique as he works on Test-Driven Development, his fifth book. He enjoys programming, music, and gardening.
Ron Jeffries Object Mentor
After a long and fruitless life in software development, during which he built software producing revenues of over half a billion dollars for some companies, and drove others to destruction, Ron Jeffries was chosen by Kent Beck to help with Extreme Programming. He was hand-picked by Beck for a very important reason: Ron lived near Detroit, where the first XP gig took place. Since that happy day when for the first time his true qualifications had been recognized, Ron has been an avid, not to say vicious proponent of XP. He claims that any application, no matter how complex, can deliver business value every two weeks from beginning to end. We'll see about that.
Erik Lundh - Compelcon
eXtreme Programming is currently the best way, that I know of, to give individuals and teams an experience of success and an insatiable appetite for process improvement. I have introduced the agile mindset through carefully selected all-out XP pilot projects in both small and large organizations. The agile coach adapts the process to the team, talents and domain, while going by the book(s) of XP. Like a true musician performing a familiar tune, it's all in the phrasing and tempo. Like in many martial arts, the coach teaches the team to execute a basic system, while gaining experience to evolve. The team goes from feed me to improvise and adapt, the attitude goes from rules to patterns. The art of coaching is also the art of knowing when to step back.
Erik Lundh has developed software for products the last 20 years. His work takes him inside both boardrooms and R&D labs. He equally enjoys being coach and director. Erik got involved in XP while looking for a sustainable form for cross-industrial teams, from established industries with differing engineering traditions, to work together in a rich environment. He coaches one team, including the customer. That means coaching the customer on team from a business perspective and developers from both business and technical perspective. Erik is proud that his XP-teams ship products in volumes today. Erik promotes and supports software industry/academic networks/SPINs, with international exchanges, on a national level SPIN-SWEDEN, and in his own regional SPIN-SYD, a peer network of people from 35 software companies in the south of Sweden. Erik is also instrumental in the startup of new SPINs in Sweden. Erik lives with his family in Helsingborg, Sweden. Across the water lies Kronborg, the mythical castle of Shakespeare's Prince Hamlet.
Rob Mee Pivotal Computer Systems
Everyone, it seems, wants to be Xtreme these days. At least if you define everyone as every methodologist. Is XP variation of our method? Sure, plug it in, we play. Not XP? Well, we're Agile; XP is Agile, right? Ok, good enough. Let's ride this wagon. This panel asks: What constitutes being Xtreme or not being Xtreme and does it really matter? Hell yes, it matters. My position, on this panel, is that practices matter. Details matter. Extremities matter. I am currently consulting in Germany, where I coach an Xtreme project at the oldest life insurance company in Munich - and drinking more beer than I knew was humanly possible.
Gary Pollice Rational Software Corporation
Extreme practices are not new. We used to label teams that practiced them with other names, such as skunk works. They are simply those practices that emerge from highly successful individuals and teams. It is human nature to try to take what works for us and transmit it to others, so they can succeed in similar fashion. And, like self-help programs and diets, XP and other methods appeal and work for some, but not all people and teams. Being truly extreme should mean that an individual or team is able to decide on a project-by-project basis (or a moment-to-moment basis if necessary) what is the best set of practices for them. It really doesnt matter whether they use all twelve (or however many it might be) practices of XP, or just a couple of them along with a Gantt chart and a diagram or two. Extreme is having the biggest set of intellectual tools, and knowing how and when to use them. If the team delivers value to their customers, and they learn, grow, and find satisfaction in the process then that is what matters.
A curmudgeon is a crusty, ill-tempered, usually old man. The RUP Curmudgeon (Gary Pollice) tries not to be too ill tempered (some people say he's really a nice guy), but he does admit to often being crusty, and unfortunately there's nothing he can do about being old. Gary has been developing software for a very long time and is passionate about producing high-quality products that satisfy customers. He spends a lot of time meeting customers to find out what their needs are and how Rational can best meet those needs. Gary has been involved in IT software development as well as developing software tools, particularly compilers. Gary has a B.A. in mathematics and an M.S. in computer science. He is an adjunct professor of computer science at Worcester Polytechnic Institute. He also has a life outside of work, but no one can figure out what it is.
Charlie Poole Consultant
There has been much commentary related to the statement or proposition that XP is something that is only applicable in small teams around small development projects. That when a project gets big or is distributed across several sites XP becomes less relevant. Yet I have seen XP work in just these situations. Are there things that happen in these large distributed environments that represent new practices? Do experiences around customer teams or customer proxies in such an environment reflect new practices or are they simply extensions of existing practices? How does one motivate change in such a way that large teams benefit in the same way that small teams can and have? Over the past 15 years Charlie has moved from the waterfalls and requirements of developing military and government hardware and software systems to the ad-hoc approaches present in start-up enterprises. It has left a deep and indelible image (and not a few scars) of development and development management in a variety of environments. XP enlightenment came at the peak of some despair trying to maintain and support a wonderfully complex set of products for several thousand customers. The successes and failures of implementing XP in that environment have led to efforts to extend XP to large geographically distributed product development organizations. Can you imagine such a thing?
Convener and Moderator: Steve Fraser , Consultant firstname.lastname@example.org
Since leaving Nortel earlier this year Steve is looking for new career opportunities, consulting, traveling, and generally having fun. For 15 years Steve served in a variety of diverse software technology program management roles at Nortel Networks including: Process Architect, Senior Manager (Disruptive Technology), Process Engineering Advisor, and Software Reuse Evangelist. Steve served as the initiator, Chair, and Event Director of the Nortel Networks Design Forum, a proprietary global technology transfer event run by video, audio and web conferencing. In 1994 he served a year as 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. Steve is an avid operatunist, videographer and still enjoys travel.
Moderator: Rachel Reinitz - IBM email@example.com
Rachel is an experienced eXtreme Programming coach and has applied XP practices for the past four years. Rachel developed her XP talents at the Evant, the startup recognized for their XP projects. Rachel has been a frequent instructor with Industrial Logic's eXtreme Programming Workshop. Rachel recently returned to IBM as a senior consultant focused on Web Services and WebSphere. She continues to advocate the use of XP within IBM and with customers. Rachel led projects for major banks, insurance corporations, telecommunications companies, and start-ups. Rachel was a technical lead at the B2B marketplace builder, Ventro (formerly Chemdex)