Skip to main content

Agile is Rational, Rational is Agile Series: Making It Real – Getting Agile and Rational Ready

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


[ MUSIC ]

HOLITZA: Good to see you guys again. I really appreciate you both taking time out of your busy schedules to help me get an understanding of what Agile is all about.

We discussed how Agile methodologies can be effective in large organizations, whether they be projects that are greenfield or legacy or brownfield in nature. And the Agile methodologies when done correctly allow organizations to be more effect in governing their portfolio projects. So I'm really wondering what my customers should consider before moving to an Agile methodology?

AMBLER: I think there's a few things. You know, [INAUDIBLE] you need to do a pilot project or several projects to test it out for yourself because Agile is relative, different organizations during different situations, different project teams for different situations.

And you need to be flexible. And you need to see it work for yourself. You know, you should be open minded, but skeptical. So I think there's some good stuff to be said there.

But you also need to get assessed at some point. So it's fairly straightforward to be successful on pilot projects which people have been doing and doing very well, but when you start to roll that out across the organization or across a division or at least across multiple teams, the rules change a bit.

And you start running into cultural issues, and to be fair you'll run into cultural issues on projects as well, but you'll definitely hit them bringing them across the organization. You'll definitely have to get good at identifying what projects are applicable for Agile and what ones you might want to try something else at. And educating people [INAUDIBLE] your stuff.

So there's a fair bit to rolling out Agile, just like there was a fair bit to rolling out object technology or service oriented technology. You've got the same basic issues to deal with.

BOOCH: The other thing I'd observe is that whatever that organization is, they should step back and ask themselves, what value are we expecting? What are our expectations here?

If one is going into Agile just for Agile's sake because it's cool and everybody else is doing it, that's one thing. But on the other hand, if there is a real point of pain or if there's some real value that one is going after, assert that first. And then after you're done with that pilot, ask yourself have we attacked that point of pain, have we addressed that area of improvement?

The other thing I'd observe is that whatever team you are and whatever pilot, there's a wealth of information out there, so don't go it alone. There are books, there are papers. There are things that we have in our products, and white papers, and lectures, and this series itself, for which one can draw upon because there's been a wealth of experience and every team that's starting off on this journey should look at those who have come ahead of them.

HOLITZA: Right. So on that note, how does IBM Rational help customers go Agile, from wherever they may be starting from?

AMBLER: So from a services point of view, we offer a service called Measured Capability Improvement Framework, MCIF. And the goal of that is to help organizations identify what their goals are, what their vision is, what they want to improve both from a...particularly from a business point of view, but also sometimes from a technical point of view as well.

So once we understand those goals, we then start assessing the situation and investigating where you are and where you could potentially be. And so we suggest common practices, some of which are Agile, some of which are not. So it's more than just an Agile type of a service. But the reality is a lot of the practices are very...are considered to be very Agile, with continuous integration and tester and development and good stuff like that. So that's part of it.

We also help to identify, what's stopping you from being successful? I think this is where we really differ from a lot of the other assessments that you see out there, is that we've got a pretty good handle on not only what could be potentially going wrong, what's inhibiting you...

But also, how to deal with those inhibitors and what their impact is on those practices because it's pretty easy to say, oh, you need to do more continuous integration but if there's a few things that are stopping you from being successful at that, then wonderful advice and maybe we'll sell you some tools, but then, you know, six months later you're still haven't adopted them effectively.

So our goal is to make sure that you actually get the benefit that you've been told you can get and that you adopt these tools and practices in an effective manner. So there is that part of MCIF.

The second part, which is also very interesting, is something called Rational Self Check. And the idea is that not only do you have to get on the right path, but you've got to stay on it.

And you've got to measure your success, you've got to...or sometimes, measure your lack of success, and on a regular basis. So a very interesting thing that you see on Agile teams is that they're regularly do something called retrospectives.

And what a retrospective is is an opportunity where at the end of an iteration the team will purposely ask questions like, how can we get better and how can we...you know, what are we doing right, what are we doing wrong, [INAUDIBLE]. Which is great. This is a wonderful cultural thing that you see in the Agile world.

But you can take it one step further and actually measure your progress against what you believe you need to do. So not only should you identify what you can potentially do, but you should actually act on it.

So you'll see in some situations where the team will hold a retrospective, and they'll say we need to get better at testing. And then at the end of the next iteration, we need to get better at testing. And at the end of the next iteration, oh, we need to get better at testing. And they never actually act on their observations.

Or what will happen is, they will act on their observations and then a few iterations later they'll say, you know what? We need to get really better at interacting with our stakeholders.

So then they focus on that and they lose focus on testing. So they never actually get to the point where they've fully adopted it, so then their testing starts to go down because they've changed their focus.

So by measuring what you're doing, by asking common questions at the end of these retrospectives just to sort of judge where you are in adopting whatever practices or principles that you're trying to adopt, what you'll find is that by just by using these very simple measurements and keeping track of them that your process improvement effort will go much better.

So we're seeing a lot of really good stuff here, and it's interesting. Within IBM we've been doing this for six or seven years now and I guess about a year ago somebody said, you know what? This is working really well for us, we should actually bring this out to our customers.

So it's one of those things where the labs were doing good work and nobody really thought to execute. So we've come along and now we're executing. So there's some really good stuff there. So I think MCIF is something that the organization should really consider and take seriously.

BOOCH: Another thing I might mention is sort of an immediate thing that folks can do is go visit the Rational IBM Web site. There's a wealth of information about Agile in general, Rational's products and services there. Scott, help me out, but I believe its www.ibm.com/rational/agile. Isn't that the location for it?

AMBLER: It is, most definitely.

BOOCH: And of course there's our upcoming Rational conference as well, too, coming up in late May, early June, I believe. I don't have the dates at my disposal.

MALE SPEAKER: I believe its May 30th to June 5th.

MALE SPEAKER: And there you'll meet a whole bunch of like minded folks who have had varying degrees of experience with Agile, and you know, it's great to build that kind of community.

AMBLER: Definitely. I just want to point out there is definitely going to be some very interesting talks about Agile. We've got customers coming in sharing their experiences. We did the same thing last year.

There's a couple good panels, I believe, and you'll see some interesting tools. RTC is going strong and a lot of Agile teams are ready to taking it to the next level with products like Rational Team Concert, Rational Requirements Composer.

So we really are helping organizations scale Agile to the real world environments they find themselves in, so going beyond these pilot projects.

HOLITZA: Well that's great stuff, guys. Well, I really appreciate your time, and maybe we'll have to meet again on something else, but this is a great talk on learn about Agile and how we can help the customers, so.

BOOCH: Glad to be here.

HOLITZA: Good.

MALE SPEAKER: Definitely glad to be here, thank you.

[ MUSIC ] [END OF SEGMENT]

Video not available.