 | Level: Introductory Scott Laningham (scottla@us.ibm.com), Podcast Editor, IBM developerWorks
10 Apr 2007 IBM Agile Development Practice Lead, Scott Ambler, explains this iterative and incremental approach to development, lays out the business case for it, and dispels some myths in the process.
developerWorks: You're listening to developerWorks interviews where we feature conversations with technical luminaries and thought leaders from a variety of disciplines on topics of interest to technology professionals. I'm your host, Scott Laningham. And our guest today is Scott Ambler, Practice Leader, Agile Development, with IBM Rational.
Scott, welcome to the podcast.
Ambler:Oh, thank you.
developerWorks: Now, the word agile in that term, agile development, must hint at something of what agile is all about -- meaning, of development process that's adaptable on the fly and graceful in doing so. Would I be right to assume that?
Ambler: Yes, definitely. So when we talk about agile, there are several key issues that apply. First of all, it's an incremental approach to development, so it's evolutionary in nature. It's also highly collaborative, so developers are working together with, you know, both with each other as well as with the stakeholders. So it's a very, very nice way to work.
|
Guest: Scott Ambler
Scott W. Ambler is the Practice Leader Agile Development at IBM Corporation. Scott works in the IBM Methods group developing process materials and travels the world helping clients understand and adopt the software processes which are right for them. Scott is an award-winning author of several books, including books focused on the Unified Process, agile software development, the Unified Modeling language, and CMM-based development. Scott is a regular speaker at international IT conferences and is a contributing editor with Dr. Dobb’s Journal. Prior to working for IBM, Scott led the development of several software processes, including Agile Modeling (AM), Agile Data (AD), Enterprise Unified Process (EUP), and Agile Unified Process (AUP) methodologies. Scott holds a BSC in Computer Science and a Master of Information Science from the University of Toronto.
|
|
We have just enough ceremony. So we're not burdened by lots of documentation. We still do some documentation, but we're very smart about it. We focus on very high-quality software. So when you think about agile, you really do need to think, you know, high-quality, high-end type stuff. We do it in a cost effective and timely manner. And most importantly, I guess, and this is probably where a lot of the differences are, is we focus on developing software that meets the changing needs of our stakeholders. We welcome change. I think it's a good thing to do.
developerWorks: Now, why is IBM talking about Agile development right now? It's not necessarily a new term, is it?
Ambler: No, it's not a new term at all. It became popularized in 2001. In early 2001, there was basically a ski trip where a bunch of methodologists got together and had a good time and talked about software process. And they actually came to a few conclusions which eventually became the Agile Manifesto. And then Software Development Magazine -- one of the magazines that I used to write for -- basically popularized it within the community with a few feature articles.
And so why are we doing agile? Well, I think there's some very significant business benefits. Agile software development really does...when you do it right, at least, it results in improved time to market. It also results in significantly improved quality. Agilists do a lot more testing, we refactor our code to make sure it's of high quality at all times, good stuff like that. So as a result we're doing far better work than what we see in the traditional world. It actually has a much greater chance of fulfilling our stakeholder's needs. Our stakeholders are not good at defining up front what they want. They change their minds. When they see something, they say, well, that's not really what I wanted, you know, I really need you to give me something else. So by welcoming change, by having techniques that allow us to change easily, we actually have a much greater chance of building systems that people actually want, and at reduced cost. We do, we're much more efficient at developing software because we focus on what people actually want and we don't build things they don't want whereas some of the stats show that traditionalists really sort of struggle with that.
A couple other reasons from an IBM point of view, I guess, is not that the business benefits aren't sufficient, but agile is quickly being adopted worldwide. There's been a range of surveys that have shown this. And so the writing is on the wall, Agile is real and it's here to stay, and our clients are doing it, so we need to be doing it too. And quite frankly, the traditional approach to development doesn't quite work so well. And we really need to start rethinking how we work. And I think that's what Agile is all about. It's a bunch of smart people that have rethought the general approach.
developerWorks: So what is it about the current state of software development that demands more of this type approach right now? Is it...I assume it has something to do with the speed of innovation within the very dynamic atmosphere of the Web?
Ambler: Yes, there's definitely that. The only constant is change, you know, it's the same old rhetoric, I guess. But we're discovering that the big systems of yesteryear which were fairly reasonably straightforward...they're complex, but they're fairly straightforward things, they're no longer applicable. So the projects for the most part are shorter. They're faster. They're much more dynamic. And you've got to meet the market needs much quicker so I think the marketplace demands far more, people's expectations are rising and we have to meet them.
developerWorks: If you could, for a second, tell us about the foundational points of Agile development. What makes it different from more traditional software development methods?
Ambler: I think...so one of the main points that I want to do is that there's always this risk of whenever I describe agile to people it's always, oh, yes, I've been doing that for years. More than likely you haven't. And we saw that same sort of thing with object stuff and we're seeing it with Agile stuff. So, yes, you might have been really smart in the past, but you could be smarter, I guess, is part of the situation.
So how is it different? First there's a much greater focus on collaboration. Writing documentation and sharing it with people is the absolute worst way to communicate. So we try to avoid that. The best way to communicate is a bunch of people standing up in front of a white board talking and sketching and doing good stuff like that. Now, if your team happens to be dispersed, well, then, you know, maybe you've got to do phone calls or send e-mails or do video conferences. But you can get around those sorts of problems. Our stakeholders are actively involved with the project. We respect our stakeholders. They're very smart people. So we find ways that they can be actively involved in the modeling. We use inclusive modeling techniques and simple modeling tools whenever we possibly can.
The second major point is that we focus on working software. And I think this is critical. The only true measure of progress on a software development project is the delivery of working software. Everything else is sort of fictional. So in the traditional world, the claim to earn value by delivering requirements documents, or architecture documents, or stuff like that, but the only thing I can tell you is that a document was written. I have no idea if people are reading it, if it makes any sense. Yes, it passed a review but that doesn't really mean anything in the long run. And I think this is a serious challenge. So as a result we've produce a lot less documentation. We still produce some docs, but nowhere near as much. But we focus far more on this delivery of working software because people can understand that. They give us some money and a couple weeks later we've got something to show them. That's pretty strong.
The third thing is that agilists is for something that we like to call generalizing specialists or perhaps craftspeople is a better way to look at it. With a generalizing specialist, that's somebody with one or more specialties, who, you've got to have something to add, some value to add to the team, but you have a general knowledge of software development -- better yet, a general knowledge of the domain you're working in, at least a general knowledge. And you're willing to learn, and you're willing to roll up your sleeves. So there's none of this, oh, that's my job, and that's your job type stuff. It's, you know, that's our job, let's work together to get it done. So as a result of building teams of generalizing specialists, there's less hand offs between people because the people are more highly skilled. And so this is a challenge particularly in an environment where for years we've been rewarding people for becoming overly specialized. So you have use case modeling specialists, or data modeling specialists, or testing specialists. We're moving away from that so that there's going to be a little bit of a challenge there for a lot of people.
And then finally, I think the main observation is that Agile is based on practice, it's not based on theory. Traditional development techniques are based on theory. And that's something, because we've had them forced on us for so long now, a lot of people have forgotten that. There's a lot of evidence that the theory is false. So the Agile stuff is coming from people who are in the trenches and do this stuff for a living.
developerWorks: So maybe that brings us to this logical point of the naysayers out there. And I know in the presentation that you do on this you take myths and then you look at reality. And maybe we can take those as a list and you can kind of quickly dispel them if you want to. Like the first one, no documentation. You already talked about that a little bit, but dispel that one.
Ambler: Yes, so we do write documentation, but we treat it like a requirement. And so we ask people to estimate the cost of that. And we make the cost explicit. So it's amazing what happens when you say, oh, you want that document? Great. It's going to cost us $50,000 of your hard earned money to produce that document. And when you say things like that, the very next question is 50,000? Are you kidding? What can I get for 10,000? So, and you start negotiating from there. Or they say, oh, I didn't know I actually had to pay for that. Forget it, we don't need it. So it really sort of makes things smarter. It really motivates you to write very tight and concise documentation.
So one of the things that agilists do we document stable concepts and not speculative concepts. So we don't write as much documentation up front because that information is going to change. So putting it down on paper isn't that good of an investment in your time. It's just sort of crazy. So we really force people to think and justify why they want the documentation. So as a result we do less.
developerWorks: What about the charge that Agile development is undisciplined?
Ambler: Completely false. I would argue traditional development is undisciplined. There's a lot of paper pushing and bureaucracy going on in the traditional world, but that's not discipline. It requires great discipline to do test first development or to do just enough work and then to move on and do something else, and to stay focused on high-value activities. Yes, that's just false.
developerWorks: Now, some people tend to equate iterative with no planning, and that's not what that means, is it?
Ambler: No, no, not at all. We do just in time planning. So we'll do a little bit of planning up front, because you've got to identify your main milestones and the major dependencies that you have other teams because you've got to manage to that. But we do just in time planning. We also do self-organizing teams. Developers are smart people. They know how to do their jobs. They know how to organize their work. They don't need some manager to come along and produce this detailed Gantt chart thing, you know, for this four hours today you're going to be doing this -- because you know what? The developers ignore that sort of stuff any ways. They do the right thing when they're allowed to.
So we recognize the fact that, you know, people can pretty much figure out how to do their own work. And as a result we do a lot less planning. We do enough planning to get the job done. That's about it.
developerWorks: Now the next one seems to follow suit, not predictable. I mean, you're already talking about how that's not applicable. But go ahead on that one.
Ambler: Yes. Well, traditional development is not predictable. Well, actually, I guess it is: I can predict you're more than likely going to be late. You're more than likely going to be over budget, and you're more than likely going to produce software that doesn't meet the real needs of your users. So if that's your goal, then, yes, do the traditional stuff. But I can predict that, you know, if you're truly doing Agile you're going to be writing high-quality software. You're going to be doing stuff that provides the greatest ROI to your stakeholders as they define it. I can predict that you're going to meet the schedule as your stakeholders choose to set it. So this is far more predictable.
Now, can I predict up front how much money you're going to spend? No. All I can do is predict you're going to spend it really wisely. Can I predict exactly what you're going to build up front? No, but I can predict you're going to build the highest-value stuff. So I think that's the level of predictability that I would prefer to have. So I guess it matters the way you look at it.
But I think there's a lot of false confidence that gets built up by these detailed estimates and detailed schedules. And it's interesting that many people are unable to observe the fact these estimates rarely seem to come true and the schedules rarely seem to work out in the long run. Unless of course, there's phenomenal amounts of padding and you had to lie your way your way through it all. So, and I would prefer not to do that.
developerWorks: Now, what about, does not scale? What about that one?
Ambler: Yes, that's also a misnomer. Now, to be fair, a lot of the Agile literature does focus on small co-located teams. But the reality is the Eclipse project is an Agile project, and that's hundreds of developers worldwide working on a complex system. And they've been meeting their dates for years now, and you know, they argue that they're one of the most successful projects in the history of computing. Now, I don't know about that. They're really successful, I know that. But if they're the most successful, I'll let them argue about that. But they're definitely doing a great job. So that's one of several examples of agile at scale. ibm.com, our Web site, was developed using an agile process, and you know, it's a fairly big system.
developerWorks: Okay. What about, you already spoke about this a little bit, but that it's a fad. Obviously you said it's quickly becoming the norm now, right?
Ambler: Yes. All the numbers... There's several surveys out there. I ran one for Dr. Dobbs about a year ago. My survey was probably the most pessimistic one, but within North America the results were 45 percent of organizations polled had adopted one or more methods; 65 percent had adopted one or more Agile techniques. So it's pretty obvious the direction that we're going in. I would argue that, you know, take a look at any software development conference these days. It's pretty hard to find talks where people aren't talking about Agile software development.
developerWorks: Does it introduce challenges when it comes to contractual negotiations or issues with the price being solid, that kind of thing?
Ambler: Well, contractual negotiations are difficult no matter what you do. So we need to recognize that. But there's fixed price, you know, there's some realities, you know, the clients force us to do this. But at the end of the day fixed price isn't good for anybody involved. It actually increases your risk. It forces you to do a lot of up front work that doesn't help you at all and actually decreases your efficiency. So it's just bad news. Yes, you can do, you know, agilists can do fixed price along with traditionalists: we can do the same sort of thing, we're going to do a little bit too much work up front and we're going to...you know, we'll make up a number just like the traditionalists do.
The main difference is that we'll be honest about it and we'll say, you know what? This isn't such a good number, and if you insist on an exact number we're going to pad the bid. And so that's just the realities. There's no magic.
developerWorks: How tough is it to get the culture to change to this type of thing? Is that a challenge?
Ambler: Yes, definitely. It's like any paradigm shift. You're just going to get beat up on with the existing culture. You know, we've been rewarding people for years to be specialists. We've got divisions and departments that have built up their little empires over the years. And whenever you change the power structure you've got a few people that aren't going to want to change. People are just resistant to change naturally. So we're changing the rules on them, I guess. But at the same time I think you've got to recognize that this is coming your way, like it or not. And you've got to do it.
developerWorks: And of course, who wants to argue that, well, let's not do it even though it's progress, because it's too hard, you know?
Ambler: Yes, and it is hard. We're going to have to, we definitely need to help people do this. And we've got some stuff underway within IBM to help people learn this Agile stuff. But I highly suggest people start reading, start re-thinking, even just step back and observe what actually happens.
I speak at conferences a lot, and some of the advice I give people is, sure, you want to listen to speakers, but more importantly, talk to the people that are sitting beside you. And what you'll do is you'll discover that you're all suffering from slightly different flavors of the same problems. And they're all based on this false theory that traditional software development is based on. And until we start recognizing that and until we observe that the traditional way of working is horrendous and doesn't really seem to work all that productively, we're really not going to be motivated to change appropriately.
developerWorks: You know, it sounds to me as you talk about it also like you're putting more faith in developers up and down the chain of command. And it's not the traditional top-down organizational look at things, right?
Ambler: Exactly. You still have governance. You can still keep an eye on things. I would argue it's easier to govern an Agile project than it is to govern a traditional project because it's really difficult to hide on an Agile project. If you have to deliver working software every couple of weeks, I can't fool around for very long on that sort of a project. People are going to notice that you're not producing, and they'll start asking some nasty questions. So I think there's some value there.
developerWorks: So the idea that it's only appropriate for senior level developers is just not true?
Ambler: No, not at all. The real issue is that you're going to have some novices on the team. You're going to have some mid-level people, you're going to have some senior people, just like on any given team. The main feature, I guess, is that they need to be willing to work together. They need to be willing to learn. And I think that's critical.
developerWorks: What is IBM...kind of as a wrap-up, maybe. What's IBM doing around this topic right now?
Ambler: We're doing a lot of pretty interesting stuff. Now, IBM Rational is soon going to have an Agile campaign where we're communicating the message, there will be some good stuff going there. We've got IBM developerWorks, there's some great stuff on there. The Rational Edge, some great articles, the Rational Unified Process, we've got some really good process assets.
IBM Global Services has some Agile efforts underway. We've got a few teams that are doing some pretty good stuff. And so we're growing those practices. IBM Research in May has a conference in Alamedan, in California. If you can, I highly suggest going to that. I'm on the conference committee and we're just about to send out final acceptances for papers. And our biggest problem right now is we have a lot of really good proposals and we can't accept all of them. So this is going to be a really solid conference. We have some really good industry experts on staff. It's amazing. I recently joined IBM, and I just bump into some really smart people doing some really cool stuff all the time, so.
And we've got some really good open source projects underway, you know, obviously Eclipse. But I can't remember what the numbers are, but there's three or 400 open source projects where IBMers are actively involved. So we're doing some really leading-edge stuff in the community. And I think we need to get better at communicating that.
developerWorks: Well, a lot of very interesting and very encouraging stuff in your comments today, Scott.
Ambler: Thank you.
developerWorks: Thanks for bringing us up to speed on agile development. Really appreciate your time.
Ambler: Oh, my pleasure. Thank you very much.
developerWorks: Our guest again was Scott Ambler, Practice Leader, Agile Development, IBM Rational. Find out more about what Scott talked about at ibm.com/developerworks. Just type in Agile development in the dW site search and a number of articles will come up.
Also check my blog for the show notes for this podcast, which offers related resource links. You can find it at ibm.com/developerworks/podcast, along with a listing of other interviews we've done. That's it for this edition of developerWorks interviews. I'm Scott Laningham. Thanks for listening.
Resources
About the author | 
| | Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician. |
Rate this page
| |
