TEXT TRANSCRIPT: 15 March 2001
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Announcer: Welcome to Quality Plus e-Talk! with Carol Dekkers, brought to you by StickyMinds.com, the online resource for building better software. This program will focus on the latest in the field of technology. All comments, views, and opinions are those of the host, guests, and callers. Now let's join your host, Carol Dekkers.

Carol: And welcome to show number eleven of Quality Plus e-Talk! with Carol Dekkers. I'm Carol Dekkers. I'd like to welcome you from wherever you're listening to us. This week's show carries on with some of the things we've talked about for the last eleven weeks. We've talked about building better software and focusing on that. And today's guest is one of the cream of the crop guests. They just keep coming and coming. And people said to me this week at the Software Engineering Process Group conference I was at in New Orleans, "Where do you get all your guests?" And I've said that I'm just incredibly fortunate to be able to know and contact some of the best in the industry. And today's guest is no exception. We're going to be talking to Jim Highsmith on the topic of "Introducing Adaptive Software Development - Lightweight Methods for the New Millennium." So I'm quite excited to have Jim here. Welcome to the show, Jim.

Jim: Thanks, Carol. Carol: And I'd like to tell people a little bit about what I do and a little bit about the calendars that we've been offering. We introduce function point analysis and software measurement, not only for getting numbers to be able to manage your metrics and to be able to manage with, but really to be able to leverage your software practices. This week, with the Capability Maturity Model, there were a lot of presentations on how to increase, not the complexity, but increase the effectiveness of your processes. And the best way to do that is to be able to find out which software development processes aren't working right, which ones are working better, and to be able to leverage the best practices. The only way to do that is to measure things. So again, this week I'd like to offer you a copy of our free calendar. If you send me an email to [email protected], I'd be happy to mail one out to you. Please include your mailing address, because I haven't figured out how to send by email anything that's a paper copy. I'd like to thank our sponsor, StickyMinds.com, for being our sponsor, and I'd like to introduce something that a lot of people have been waiting for. They've been waiting for the past shows, where we've had just an incredible line-up of guests. And people have said, you know, "I missed the show with Bret Pettichord" or "I missed the show with Johanna Rothman or Howard Rubin, and I'd really like to be able to have some idea of what was said." Well, StickyMinds.com, if you go out to www.stickyminds.com, you can see downloadable transcripts, actually paper copies of the transcripts, word for word, including the "ums" and the "yeahs" and also streaming audio - exactly what we've said on a number of different shows. Now we've got five of them up right now, including Ed Yourdon, Esther Derby, Howard Rubin, Johanna Rothman, Bret Pettichord, and eventually, all 26 shows from this series and the last 13, we will have all 26 shows up on StickyMinds.com that you can take a look at, download for free.

Without further ado, I'd like to introduce you to Jim Highsmith, who's the director of the Cutter Consortium's E-Project Management Practice. He's the author of a best-selling book, "Adaptive Software Development, A Collaborative Approach to Managing Complex Systems," and editor of E-Business Application Delivery, published by Cutter Information Corp. He's had 30 years of experience as a consultant, software developer, a manager and a writer. He's published dozens of articles in major industry publications, and his ideas about project management in the Internet era were featured in a recent issue of Computerworld. He's worked with IT organizations, software companies, all around the world, most notably in the U.S., Europe, Canada, South Africa, India, Australia, Japan, and New Zealand, to help them adapt to the accelerated pace of development in increasingly complex, uncertain environments. Welcome to the show, Jim. I am absolutely thrilled to have you here.

Jim: Thanks, Carol. It's really great to be here.

Carol: One of the things that struck me. There's a couple things that I'd really like to get into. One is something that you've called the Manifesto for Agile Software Development, which I'd like to get into in a little bit, which is pretty exciting, I think, something that not a lot of people know about.

Jim: Well, it's pretty new.

Carol: Well, that's probably why they don't know about it. Second thing is, I'd first like to talk a little bit about, what is adaptive system development? What is a lightweight method? And what's the difference between lightweight methods, adaptive software development, and the XP, the extreme programming, that we've been talking about for a few weeks? Jim: Okay. I think first of all that light, or lightweight, methods, we've sort of now adopted the term "agile methods" or "agile processes" or "agile methodologies." And we look at things like adaptive software development, like extreme programming, scrum, lean development, crystal methods, feature-driven development, as instances of that whole category of "agile methodologies." And if we look at those things, what the group has been trying to come up with is a set of common values and principles around agile methodologies, but that each of the individual approaches may be different in its practices, in sort of its emphasis on different things. And so I look at extreme programming, for example, as one instance of an agile methodology that has a particular domain of expertise. Adaptive development would be one that would be a little bit different, focused on a little bit different kinds of things.

Carol: Interesting. So you'd look at it as being kind of a family of methods that can all fit under an umbrella, they can work together, there's different pluses and minuses, I'm assuming, in all of the different methods.

Jim: Yes, I think so. You know, some organizations might, for example, think scrum is more appropriate to them for what they're doing at a particular time. Others might think extreme programming, but actually one of the common values, I think, of all the agile methodologists is this belief that there is no one-size-fits-all, that in fact every organization and every project is a little bit different, and that any methodology needs to be tailored to a particular organization. And I would be quite,  even in a particular organization, that you know, one project team might use extreme programming, and another project team might use crystal methods, and that would be appropriate. Carol: Now, for any of our listeners who may not be completely up to date on extreme programming, scrum, and crystal methods, can you just give us like a 30-second capsule snapshot of what are the commonalities, what are the common features, of what these agile, or agile I guess, I don't know how to pronounce it.

Jim: Well, Martin Fowler, who was one of the people at the meeting that came up with this. He had, the only objective, objection to the word "agile", he's from Great Britain, and he said that Americans don't know how to pronounce the word.

Carol: How does he pronounce it?

Jim: I'm not sure how they pronounce it. Agile, I believe.

Carol: Well, okay, I'm Canadian, so that's why I pronounce it that way. I guess I pronounce it properly too.

Jim: But I think, Martin Fowler wrote an article recently on what he calls the New Methodologies, and he sort of I think summarized it in two phrases, the idea that people are more important than process, and that adaptability is more important than prediction. And I think those two things, sort of at a high level, summarize it in that we believe that processes and tools are important, but that in fact it's the people aspect that is much more important, and that I think if you look back into the early '90s and the rise of things like business process reengineering, there was a time period when I think the focus on process was such that people thought we can implement these processes, be they software development processes or business processes, and that we don't have to worry quite as much about the people who populate those processes. And I think that trend has definitely changed, and that we really are more dependent, or realize that we're more dependent, on people and their individual skills and capability, and the capability of the group to collaborate and solve difficult problems. I think the second part of this that is particularly important today is with new business models, the rise and fall of a lot of the dot-com business models, the tremendous new technology that's just emerging, that being able to predict where a project is going to go is much more difficult than it used to be, and therefore our plans that we make are much more tentative than they used to be and that we have to learn to be agile and to adapt to changes much more readily over the life of the project.

Carol: So we're really talking about much more people-centric, much more listening to the people who are going to be using the systems. Much more like you would do as a builder would do when you're sitting down with somebody that needs a floor plan or something drawn out. One of the things that hits me that I think is really something that we never really learned in school, I don't know how old you are, but you know, I'm twenty…

Jim: Real old!

Carol: …and you're probably twenty-two. But when I went to school, and I went through mechanical engineering, we were really taught that the people-centric issues, the economics, and the people who were out in marketing and that type of thing, that was fluff. And if it couldn't be measurable, and it couldn't be absolutely objective, fastened down with equations, it really didn't matter. I found that to be completely untrue. But I think in our industry that this is something that's kind of hard to embrace, especially if you're over the age of 30, that people-centric issues are the crux of a lot of our problems.

Jim: Right. Well, actually my undergraduate degree is in electrical engineering, and I'm significantly over 30. And I think unfortunately that some of the people issues have been associated with the word "soft" and some of the analytical issues have been associated with the word "hard." And I would actually offer that it's the people issues that are really hard to do well. And I think if you look at a lot of these agile methodologies, they really focus on what can we do to help people work better together? For example, the extreme programming practice of pair programming, which a lot of people had a lot of controversy about, but it basically is a collaborative people issue. Scrum, which is another of these methodologies that was developed by Ken Schwaber and Jeff Sutherland, they have a daily 15- to 20-minute meeting in which they really focus on the interaction of people and what they've been doing and what they need to be doing, and what the impediments are. In adaptive software development, when I talk about collaboration, I talk about it in six different dimensions, so I think there's a lot of focus on not only the individual people, but also how people work together and then even beyond that, how do we work together in a virtual or distributed environment? I just got back from a two-week trip to India, where I worked with some teams over there who were trying to work with customers in the U.S. and Europe, and it was quite fascinating, all the different ways they went about trying to do that.

Carol: And one thing that hits me… We talked last week with David Zubrow. He was at SEPG in India, and we talked about some of the differences in culture, how a lot of Indian companies are much better able, because they're brand new and they don't have any processes in place at all, it's much easier for them to go in and put in brand new processes that would be level 3 at a CMM level. And that type of thing. And we'll be back with more of Jim Highsmith and talking about adaptive software development, now called "agile" or "agile" software development, after these short messages. Welcome back to Quality Plus e-Talk! I'm Carol Dekkers, and my guest this week is Jim Highsmith, who is one of the fathers of agile systems development, or software development. Let's give out our toll-free number for anyone who's listening, who has the guts to phone in and talk to us live. Our number is 866-277-5369, that's a toll-free number. Again, it's 866-277-5369, and we'd love to talk to you. We went into break, and we were talking a little bit about how developers and communication, and sitting down and talking to the users, that those are really part and parcel of these new adaptive, lightweight methods. And one thing that hit me on the break is that… before we get into alienating developers and quality assurance people, I think that really developers that I've met and developers and quality assurance managers and test managers, and everyone in the industry is really more than happy to sit down and focus on the communication and focus on getting to know the users and what they really need, and doing that planning process. And the brick wall that they run into is management, who says, "How much code have you developed? How much code have you written today?" Because it seems that we only get rewarded when there's pieces of machine code or pieces of computer code that come out at the end of the day, like a widget. Would you say that's one of the resistances, Jim, to adapting to adaptive software development?

Jim: I think so. I wrote down two words as you were talking. I wrote down the word "talking" and the word "coding," because I think sometimes we focus too much on just the coding aspect in terms of measuring results. But I actually think that if we're looking, particularly at projects that are very turbulent and change a lot, where there's a lot of knowledge that needs to be exchanged, that what we really need to focus on, I talk about the difference between documentation and understanding, and what developers need to do is to understand what it is they're supposed to develop and what customers need to do is to understand what it is the developers are trying to build for them. And in fact, most of that understanding does not come from documentation. Most of that understanding comes from conversation, from interaction, from sessions at the chalkboard, those kinds of things, the back and forth, the questioning and response is where that understanding comes from, from which the coders can then do development, the clients can do acceptance testing, or whatever. So we really have to balance those things, and I think all too often we focus just on one thing, i.e. the coding, as the productivity measure that we're looking at, and I think that's erroneous. Carol: And I think that's a good assessment. One thing I think that some of our listeners are thinking is that they're on a project, they're doing fairly gelled requirements, and yet what I run into is that they're not the dot-coms necessarily, you know, we've got so much turbulence in the dot-coms, we've talked about that on our XP shows, but there's a lot of people I've run into that every time I do a class, I say, "How many people have had 100% of the requirements known at the beginning, and they've never changed throughout the entire process?" And no one ever sticks up their hand. It always seems to be a case of there's always that "to be determined" area. And I'd like to explore a little bit, because I think there's a lot of things that can be gained, and some of the XP proponents may disagree with me, but I think that you don't have to apply everything in XP to try anything. And what would you say would be some of the ingredients that you've seen in your practice that people could take from XP, from the lightweight developments, from scrum, from crystal. What would be some of the ingredients that they could take today, from those methods, and apply them on their own traditional waterfall, RAD, object-oriented projects, and gain from? What would you say?

Jim: Well, I think there… it depends on the project, but I think there are a couple of things. One of the things that I talk a lot about is the difference between exploration and exploitation. That many projects are exploratory projects, where a lot of the requirements will change over the life of the project, as opposed to what I call exploitation projects, which is we sort of know what to do when we, and they're more traditional, we don't expect things to change quite as much. I think one of the big things that's in all of these agile methodologies is this idea of short, iterative cycles, whether it's three weeks or four weeks or six weeks, but very short, iterative cycles, where we build something, we show it to the client, we then respond or evolve from that. So I think that's one thing that people can look at. We have seen for years one of the most highly studied practices has been reviews. And they have been sort of, you know, proven over time to be highly effective. To me, the extreme programming practice of pair programming, for example, is just very similar to sort of instantaneous peer reviews. I think that's a practice that involves the interaction of people, and it's one of those collaborative practices that I think people can try. And some people will get something out of it and some won't. But I think that's definite. So I think short, iterative cycles with lots of analysis at the end in terms of feedback, in terms of what does the customer think. What's the technical quality? Those kinds of things at the end of each of these iterative cycles.

Carol: And we will be back at the bottom of the hour with more of Jim Highsmith and talking about the agile software development process. And we'll be back to talk about the manifesto that I think a lot of people will be interested in hearing about. So return after these short messages.

And welcome back to Quality Plus e-Talk! with Carol Dekkers. We're sitting here talking to Jim Highsmith, who has an absolutely illustrious career background. We've been talking to him about "agile" or agile software development. And when we went into the break, we were talking about what are some of the ingredients that people could use even if they're in a traditional lifecycle environment? Never ever have I ever seen projects that have 100% requirements known at the beginning. And one thing that I wanted to add before we went into break and didn't have the time, is that the one piece that I've seen be extremely helpful is a visual tool, something that you can use to show visual learners, which a third of us are, and the kinesthetic learners, the people that learn through touching and feeling, is the index card. And do you want to talk a little bit about that? I know that Martin Fowler did an excellent review, an excellent article in the December 2000 Software Development magazine, about using index cards, the story cards in XP, for other uses, even to compose a book. Can you comment on that a little bit about that, Jim? About the use of index cards, what you've seen in the past?

Jim: Right. I think in general, if you take a poll of the agile methodology people, we're really in favor of simple tools. And probably the index card is as simple as you can get. And it's very visual. I've used it a lot in planning projects. I think there's one other thing about these methodologies, is not only are they short, iterative cycles, but they tend to be feature-driven as opposed to task-driven. And so when we plan, whether it's story cards or whether it's something similar that I would use in adaptive development, we're really looking at what is the feature or the component that we're trying to develop, and let's just sketch that out on a card in terms of, you know, identifying what it is. A card gives you enough room to sort of sketch it out, and yet doesn't give you pages and pages of information. And in this regard, a story card is really an agreement between the customer and the developer to explore the requirements for that particular feature in more detail. And so these cards can then be moved around, they're very tactile, they're very visual. When I do collaborative project planning sessions, the use of something like cards, the use of flipcharts and white boards and those kinds of things that are very visual and tactile, I think it really helps the team… for example, with the group that I was working with in India, if your client is back in the U.S., and you're developing in India, probably the card is not enough permanent documentation, so then you might actually make some other kind of permanent documentation. But for the group that's working together, I think these kinds of things are very useful. Another technique that I use, for example, in terms of product visioning, is actually to get the group together, give them a flipchart and a handful of colored markers and ask the group to design the product box, front and back of the box. And it's amazing what happens when people have to, from among 25 or 50 features of a product, select the two or three that they're going to use to sell their product.

Carol: And I think it's part of what the learning organization, what Peter Senge and a few of the leaders in the neurolinguistic programming area have talked about, which is unleashing the way that you normally would think. We're taught traditionally to think about, you write it down in this order, make sure you don't miss any dots or periods or anything. We get so structured that the creative side, the really unleashing side that we've got gets trampled. And I find when I do my courses, I go through pads of flipcharts, because I'm a visual person. I cannot talk or do anything unless I see it in pictures. And for those of us who are visual, we get lost when it's just spreadsheets or something linear. Jim: Of course. One of the things that's very interesting, I think, about this whole group of people that have sort of been labeled as the Agile Alliance that do the agile methodologies is that many of them have used the concepts from complex adaptive systems theory in how they view projects, how they view people. One of the concepts is this idea of creativity, of innovation, come from a place sort of labeled the edge of chaos. In other words, not too structured, not too unstructured, but right sort of in the middle, where there's enough turbulence to generate lots of good ideas, but not so much turbulence that, you know, everything sort of falls through the cracks. And I think that's one of the things that we're talking about here, when we're doing visual stuff, we're doing sort of, you know, some documentation but not too much documentation. We're really focusing on ways that people interact and how do we capture that simply?

Carol: Now, the audience that you're talking about, the group that you're talking about, that we've been kind of peripherally talking about, is a group of 17 men, and we'll talk a little bit about what that means. Seventeen men that on February 11 - 13, 2001, got together, and people, don't make any assumptions yet, at the Lodge at Snowbird Ski Resort in the Wasatch Mountains of Utah. They met to, and I don't know if this was the order that they met to work in, talk, ski, relax, I'm not going to go into that, and try to find common ground, and of course, to eat. What emerged was the Agile Software Development Alliance, and representatives from extreme programming, scrum, DSDM, adaptive software development, crystal feature-driven development, pragmatic programming, and others sympathetic to the need for an alternative to documentation-driven heavy software development emerged and converged. And I'm just going to read off the names of these people who were involved: Kent Beck, Mike Beadle, Ari Van Venekum, Alistair Coburn, Ward Cunningham, Martin Fowler, James Grening, Jim Highsmith, Andrew Hunt, Ron Jeffries, John Kern, Brian Marick, Robert C. Martin, Steve Miller, Ken Schwaber, Jeff Sutherland, and Dave Thomas. I'm assuming Dave Thomas is not of the Wendy's fame?

Jim: No, a different Dave Thomas. Dave Thomas of pragmatic programming fame. Carol: Okay, that makes more sense. I wanted to get that clear right away. First off, how was the skiing?

Jim: Actually, the skiing was great. We had a couple of feet of new snow during the two days.

Carol: Okay, that makes it important. It makes it worthwhile. And that's probably why you came out with such a productive manifesto. For anyone that's interested, you can go to www.agilealliance.org, and you can see everything about the history of this weekend. Can I get you to talk a little bit about what this "manifesto" is? It sounds kind of like the fathers of confederation sitting around a big fire and, you know, everybody has beards and a big cigar and a glass of brandy. Tell us a little bit about what the manifesto represents, what it means to our industry, and what happened that weekend?

Jim: Well, there were no cigars, but there were a few glasses of wine. Basically, the genesis of this group, there was another group that had gotten together in the spring of last year. It was more of an extreme programming group. But we knew we wanted to bring together a lot of people who, at that time we were sort of using the term "light methodology" or "lightweight methodology," although people really didn't like that term. But we all knew that we had sort of similar views about software development, so we wanted to get together and really promote the whole category. A lot of these people knew each other already, had come from somewhat the same background, agreed on some things, disagreed on some things, but really they said they wanted to promote the whole category, and so whether you were an extreme programming person or an adaptive software development person, or a scrum person, how could we promote the whole category and did we really have some common principles that we could agree on? And we were actually pretty happy with what we came up with. The manifesto consists of two pieces, a purpose, which we have already published, and a set of principles, which we're sort of furiously working on now, and emails going back and forth is a little less productive than actually meeting together, but we should have something out within the next month or so. But just the pieces of the manifesto, and I'll just take a quick look at it, is that "we are uncovering better ways of developing software by doing it and helping others to do it." So that basically says that we don't know it all, but we're trying to do some things and to help others do some things. And that we've really come to value the individuals and the interactions over processes and tools. Again, it doesn't say processes and tools are unimportant, but it says the individual skills and the interactions are more important. "Working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan," is the basics of the manifesto.

Carol: And we will be back after these short messages to talk more about the manifesto of agile software development, how you can get involved, and what it means to our industry. Welcome back in a few moments.

And welcome back to our final segment. We've been talking to Jim Highsmith about adaptive software development, lightweight methods for the new millennium. We've been talking about a manifesto for agile software development. And one of the things that Jim said just before we went into break, that I'd like to just focus on a little bit, is he said the manifesto values individuals and interactions over processes and tools. And this almost sounds like blasphemy in the face of the CMM processes. Do you mean that you value individuals and interactions and you should throw away processes and tools? Jim: Not throw away processes and tools, but I think de-emphasize them in the traditional sense of the high level of emphasis on processes and tools. That in fact, in environments where you have really tricky problems, that it's the skills of the individuals that are going to carry you through as opposed to the process.

Carol: And that's probably true. Especially if really the end results, the products, serve individuals and interactions. And in my mind, they should be supported by the processes and tools. It shouldn't be, processes and tools shouldn't be the means, shouldn't be the end, they should be the means to an end.

Jim: Right. And I think all too often in some environments, they've ended up the other way. They've been the focal point, as opposed to the support for the individuals and the interactions.

Carol: That's often what happens, what a lot of companies do in terms of measurement, they get so tied up in measurement that measurement ends up being the end instead of the means to the end. And then they don't deliver software. And so what good are measurements unless you're delivering software? It's got to be a supportive project.

Jim: Correct.

Carol: A supportive structure. This forum, this whole forum, I think we're going to be looking forward to a lot of things coming out of it. And I think that people can watch your Web site for some of the exciting things as they start unrolling as you gel more of the things that are being sent back and forth right now in private emails. You formed this primarily, the whole XP, adaptive software development, to address some of the needs of E-projects. Is that true? Jim: Correct. I think the term that I mentioned earlier was exploration versus exploitation. And that most of these agile methodologies, while they may be fine in the exploitation area of learning how to do things better and better, they really shine when it comes to exploration. And I sort of define E-projects are projects that need to be completed rapidly, so they're Internet time projects, they're becoming larger projects as we move into more mission-critical systems. They're sort of research-like, in that we don't know exactly what the business is going to be, what the requirements are going to be, what the technology is going to be. And then they're very turbulent, so you know, to kind of summarize, you have to deliver exciting features, you have to deliver them very quickly at high quality, and be prepared to change them.

Carol: When we went into break, you mentioned that Cutter IT had done some research in this area.

Jim: Yeah, we did a study, and we basically used the definition that I have just given in terms of, and we sent a survey out to a number of different companies, to say, you know, do you have these kinds of E-projects. And what we got back from about 40 companies and nearly 40 projects per company, is that this definition of E-project defined about 20% of the projects that they currently had underway. But they consumed 31% of their budgets. That they were initiating about 20 of these projects each year, and so that very rapidly, within 12 to 18 months, half their projects would be of this type. The projects averaged 11 months in schedule and 40 people, so there were not small projects by any stretch of the imagination. So we have in many organizations, up to half their projects that are an average of nearly 500 person-months in size, that are of this exploratory nature. And we're just not used to doing exploratory types of projects, and that's one of the reasons, I think, these agile methodologies will begin to be even more important to organizations.

Carol: I think that it addresses the fact that we don't always know. And that's something that's hard for science-based majors to accept, the fact that there is uncertainty.

Jim: Right. And I think this is the, probably for a lot of people, the most difficult thing to do, as software developers, or as managers in particular, we've been taught that we've got to have the answers. And so it's inappropriate to be asked a question and basically the answer is, "I don't know, but we'll work it out."

Carol: Right.

Jim: And so it takes, you know, some real changes, not only in how we develop. But one of the things that I'm finding is that management has to change how they evaluate project teams. And then we have to change the way we contract with our customers, be they internal or external. So for example, one of the questions that I got time after time when I was in India is how do we write fixed-price contracts in this evolutionary environment? And of course the basic solution is you don't. You have to change a lot of different things to be able to respond in this sort of exploratory kind of environment.

Carol: And I think it partially comes down to trust. It's a matter of, can I trust you as a developer if I give you one million dollars, are you going to go off and squander that and really have fun with it, and charge me a million dollars even if it's only going to cost you to develop it, including your profit, $500,000? And at the same time, I have to trust you that you know what you're doing.

Jim: Well, there's also some verification in there. And that comes from the four- or five-week delivery cycle, so that if you don't deliver something to me in four weeks, I can cut you off at $100,000 rather than $1 million. Carol: And those are really good points. And we'll be back to sum up after these short messages.

And welcome back to the show. I'm glad you've been here and listening to use. We've had a great hour talking to Jim Highsmith - I just had something in my throat there - that's the problem with having a coffee-side chat with my guests, because then if I don't swallow coffee exactly right, people know about it. So keep that to yourself. Jim, it's been wonderful to have you on the show. It's been a real insight. I think that you've given a lot of food for thought to all of our listeners. And I'd like to say thank you for spending the last hour with us.

Jim: Well, great. It's gone really quickly.

Carol: It's amazing how quickly it goes. And in Salt Lake City, you're close to all the skiing, so I'm sure you have a few more opportunities to get your group of 17 together.

Jim: Yes, I'm about 30 minutes from the slopes.

Carol: Oh, how nice. How nice. I'd like to invite anyone who's listening, and I'd like to invite Jim and the entire manifesto group - do you call it the group of 17, or… Jim: The Agile Alliance.

Carol: Oh, Agile Alliance. Agile. You have to pronounce it properly. I'd like to invite you to be part of an extreme programming forum that we're setting up on StickyMinds.com. I introduced it when I did an extreme programming meets measurement presentation at the Applications of Software Measurement conference last month in San Diego, where we had 26 people sign up to be part of this forum. And we'd like to expand it. It's really an experimental forum of people who want to try some of these XP-type methods. Some of the things that may or may not work, and an exchange of what works, what doesn't work, and it may actually form some of the food for thought, or you may think about including it in your manifesto, Jim.

Jim: Good, I will definitely take a look.

Carol: So watch on StickyMinds.com. And if you don't see anything in the next couple of weeks, please send a note in and say hey, what's going on? Next week's guests, we have actually two wonderful guests for you. And I know a lot of people have been waiting and wondering about this. The topic is "Tame Your Process with Standards - Selecting the Right Standard for Your Company." And I have two absolutely illustrious guests. We have Stan Magee, who is the president of Software Engineering Process Technology company, and they specialize in ISO standards, the 12207 standard, he's the convener of working group 7 lifecycle management for ISO on behalf of the United States. We also have Peter Voldner, who is the president of Peregrine Software, who's based in Canada, and whose practice and goal is to help clients reach higher productivity using ISO 9000 and 9001. Those two subjects can get absolutely, incredibly daunting in terms of terminology, in terms of process, centric stuff. It can get absolutely too much like overhead in a lot of cases. And these two guests have written a number of books, they're working on one right now, and they're going to talk to us in layperson's terms about choosing the right process metric, or the right process standards, whether ISO standards may or may not work for your company. And really from a layperson's terms, rather than using the millions of acronyms that seem to be everywhere in ISO standards. I'd like to as well thank all of my listeners, and thank StickyMinds.com for having the transcripts, having the downloads and everything that they've provided for support. Jim, I'd like to give you a quick 30 seconds to just share something with our audience before we sign off.

Jim: Okay. I think there are really four things that are critical in looking at agile methodologies in general and adaptive software development in particular, one of which comes from Gary Hammill, who's a business strategist who wrote a book called, "Leading the Revolution". He says, "Radical innovation is the competitive advantage for the new millennium." So I think in looking at methodologies for the future, you really have to focus in on those that are focused on innovation.

(End of Transmission)

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.