Skip to main content

Agile is Rational, Rational is Agile Series: Agile for Legacy Projects, Are You Serious?

To watch the Flash version, you need Flash 8 or later, and Javascript must be enabled in your browser.


HOLITZA: All right, good to see you guys again. So you know we talked a lot about a lot of different subjects in Agile, and the last one I want to talk about is there's a misconception out there, and I'm guilty of thinking it, too, is that Agile is really good for greenfield projects but will is work for brownfield or legacy projects?

BOOCH: I might explain what you mean by brownfield, because there may be some folks listening in here or watching us that don't exactly grock what that means. There's a great book, gosh, its title escapes me, I'll dig it up in a bit.

AMBLER: I think it's Eating the IT Elephant.

BOOCH: Eating the IT Elephant, thank you. That's the one, Eating the IT Elephant, by a group of other IBMers talking about the brownfield problem.

And of course the brownfield problem is one of, you've got legacy and legacy can be a millstone around your neck. And the challenge is to not make it a millstone but to leverage it and find a way to continuously evolve it. And I think that's the key there, that Agile is not just about starting things afresh, but it's working in the context of other things that already exist out there.

And in this case, it's the context of the legacy that [we have]. So the same things apply. You know, working with an iterative way, a focus upon results with code, these principles are equally appropriate in the case of brownfield.

AMBLER: Yes, I fully agree with that, and I think there's a few important things to point out. I believe that very few IT projects are actually greenfield. There's order of magnitude difference between the amount of discussion about greenfield and the amount of books written about it as opposed to the actual amount of work that's being done.

And almost nothing gets written about brownfield, and yet that's what we're all doing. It's one of those just strange things about the IT world. And if you go back in history and read some of the object books from the nineties or some of the end user computing books from the eighties, or whatever you want to call them, there's very little discussion about working with legacy systems. And it was always about new development.

So I think this is a cultural challenge that the IT industry has just in general and the Agile folks are equally as guilty of it. But you know, it is happening. And there's a couple of good books that I'd like to reference. First, [Mike Feather's] book on working with legacy code is absolutely critical I think if you're doing any sort of clean up or refactoring of your existing legacy stuff.

And then I also plug one of my own books that I wrote with [INAUDIBLE] which is refactoring databases, and what the book focuses on is, how do you fix the data stuff. So we've got it coming from both aspects. So I think that's pretty critical.

But I think we do need to recognize that we are working for legacy code, this is the norm, we do want to leverage legacy assets and we need strategies for that. And I think that the methodologies don't cover that very well, it's sort of an afterthought which is a real shame.

BOOCH: And in fact there's another book I'd like to point out too and that's the Refactoring the Patterns book as well. In fact there's a couple of phrases worth mentioning.

The notion of refactoring applies very, very much so for working in legacy systems, because often you're dealing with systems for which the architecture is accidental. It's not exactly like you would have done and created this point from a greenfield approach, but it's a matter then of continuous improvements to keep moving forward and making that existing legacy system better and better with each release.

The other I think aspect that makes brownfield different than greenfield is the notion that you're given this body of things you have to understand the as built, and alas, for a variety of reasons, the documentation is often wanting, even that within the code, as well as it may be inaccurate as well, too.

So the challenge as a team comes into legacy systems is one of understand the as built. And once you start building those kinds of models and those models evolve over time, then you fall into the same kind of patterns as you would apply even to greenfield.

HOLITZA: That's great guys. That's good information. So is it really a resistance to change do you think?

BOOCH: Is what a resistance to change?

HOLITZA: Just the notion that Agile or any other iterative process won't work for code that was originally developed in more of a waterfall method, some of the [INAUDIBLE] there.

BOOCH: I'd react here by saying that where working in greenfield is more fun in some ways, because you're not constrained by any other reality other than the code you produce.

And in the presence of brownfield, you do have these increasing constraints of compatibility with existing things and that limits your degrees of freedom. So I'd say the issue is one of just the challenge of working with constraints that you have no control over.

AMBLER: And I'd like to point out that it's often easier to work with those constraints which doesn't seem natural but because you're constrained, suddenly you don't have as many decisions to make anymore and often the path becomes a lot more clear.

And for example at [Docker Dobbs] we recently ran a survey on looking at the success rates of different types of projects. And what we found was that the legacy update projects had the highest rate of success.

Now, there's probably a couple of factors there. I think often the legacy folks are a bit more mature and a bit more experienced than maybe some of the people doing new development, but also I think there is something to be said about just being constrained in the range of solution that you can actually provide.

It has a tendency to focus you on actually getting to the solution as opposed to imagining what the solution could potentially be if you had no constraints at all. So it's a bit different.

BOOCH: The very fact that you have legacy is an indication that by one measure or another there is value in that legacy otherwise it would have been discarded long ago. And ergo, there is some reasonableness in the architectural decisions and detail design decisions that have come together to converge to the current set of legacy that you have.

So Scott's exactly right, that starting with a blank page is one of the hardest things because there are no constraints whatsoever. But the very fact that I have some legacy for better or worse this represents a collection of design decisions that have somewhat proven themselves over time and that provide a laser like focus to the team.

Does this mean that you can't ever improve it? No, you certainly can, and in fact the Agile process will give you a meaningful way to say, how should I improve it? Because there are many ways that I can improve that code base, but you really want to only do so in ways that provide fundamental value in the end. And that's what Agile is all about, providing value.

HOLITZA: That's great, insight guys. So it sounds like that really Agile is, when done correctly is a good methodology for anything you really want to do in the way of development.

Whether you're doing new projects, you're working on legacy code, you're maintaining legacy code, that doing something iteratively and in a more Agile method would be more effective.

BOOCH: The way you couch that, it sounds like it'll also make my teeth whiter and my children like me and communicate.


But I guess the point is, I would agree with you that the Agile principles, there's no domain and no kind of development culture that I have encountered for which the Agile principles are not applicable. So I'll cast it in that way.


AMBLER: I definitely have to second that. And if you go clicking around the Web or go click on developerWorks, you'll find a lot of examples of Agile being applied in wide range of situations.

So some of the advice I always give people is that if you think you can't become more Agile, then you need to sort of explore why you think that and perhaps assume that you're wrong and look for ways to become more Agile.

I think if you approach it with an open mind you'll see that, yes, I could become more Agile because Agile is value focused, its quality focused, it's about working with people more effectively.

And what situation have you ever been in where at least one of those factors couldn't have been improved? So go in with an open mind, and I think you'll see that Agile works very well.

HOLITZA: Great. Well, this has been great information and let's, I'd like to get together and really kind of wrap this up and kind of talk about what we've discussed over the last five or so chats we've had, and really talk about where customers should go from here, where and how Rational might be able to help them.

BOOCH: You bet.

AMBLER: You bet.



Video not available.