Skip to main content

Agile is Rational, Rational is Agile Series: Agile Scales

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


[ MUSIC ]

HOLITZA: Hi, guys. Well, thanks for joining me, you know, at this dinner party. I know you guys are busy with other people, but I thought maybe we could chat a little bit more about Agile and talk a little bit about architecture, a little bit about testing that we...

I really want to talk to you guys about how Agile scales, because this customer that I'm working with, they were acquired recently by a conglomerate and they were concerned to see if Agile will be, will work on a large scale in their organization. You know, is this valid concern?

AMBLER: Oh, yes, it's definitely a valid concern to be worrying about the scalability of Agile. But the good news is that yes, Agile definitely scales very well.

So for example, within IBM we've delivered software in the marketplace with Agile teams of over 200 people. And we currently have Agile programs around the five or six hundred person size. So from a scaling point of view, at least from a size point of view, Agile definitely scales.

One of the things we've also noticed is that you need to worry about more than just sizing when you're talking about scaling. So for example, team distribution is a scaling factor as far as I'm concerned. Regulatory compliance, governance, good things like that. So I think there's a lot to be considered when we talk about scaling.

HOLITZA: Great. So now it works for larger organizations, but what if the company I'm looking at is...or, the company I'm talking to is located globally, they're distributed across the world. So I've heard that Agile teams work best if they're collocated in small teams located in the same room. Is that true, or is that a misconception?

AMBLER: It's definitely true. I think software teams in general work better in collocated situations. But the reality is is that you're not always collocated. So for example if you've got people in different cubes, you're distributed now, you're no longer collocated let alone if you're on different floors or in different buildings, or if you've got people working from home. Or worst case, if they're working across the world.

So there's very good reasons to distribute your team. You want to leverage expertise wherever you possibly can, but we also need to recognize that we're taking on a lot of risks so when we do so.

So to mitigate that risk, well, first of all I would advise people don't take the risk on if you can avoid it. You know, it's just...you know, why put your project at risk if you don't have to? But if you do decide to take on that risk, then there's two basic strategies that you want to employ.

First, you want to adopt better processes. So one of the things I always advise distributed teams is to organize themselves around the architecture of the system that your team structure and your architecture should reflect each other so that that way if I have teams in three different locations...

Perhaps I've got teams in Toronto, Bangalore and London, then the Toronto team should be working on one or more subsystems, the London team should be working on one or more subsystems and the Bangalore team should be working on one or more subsystems.

A common mistake is to actually spread the...to organize the team around job functions. So for example, to have the business analyst in Toronto, the developers in Bangalore and the testers in London. And the problem with that approach is that when you step back and observe the collaboration patterns that occur on software development teams, the most collaboration occurs between the people who are developing the subsystem.

So by organizing your team around those subsystems, by having the people in the same geographic area, you're actually minimizing the amount of collaboration that needs to occur between sites. And that actually reduces your risk. That's a very good thing. So I think that's an absolutely critical observation to make.

The second thing is to improve your tooling. So having integrated tool sets. One of the...a newer product from Rational is called Rational Team Concert. And I like to say that it's a distributed Agile development environment that's built by a distributed Agile team.

And so as a result the features and the functionality that we see in RTC the Rational Team Concert actually reflects the realities that distributed Agile teams face. And I think this is one of the reasons why we're seeing so many Agile teams move to RTC now, is because the tooling actually reflects what they're trying to achieve.

BOOCH: You know I'd observe, too, that what the concerns of team are, any individual development team are, are different than the concerns of the enterprise because in the one case, you're dealing with the development of an application at the enterprise level. To jump to the other extreme, you're dealing with the creation of systems of systems and therein the concerns are very, very different.

As Scott pointed out, architecture is a key way of governing things across a lifecycle, and the practices one has for doing Agile approaches for individual people can also be moved up to the individual teams as well.

There's the delightful book, Organizational Patterns for Agile Development in which Coplien and his co author have taken a look at what hyper productive teams have done for large systems. And there's a lot of wisdom in there that I'd urge your customer to take a look at.

And my observation, too, is you start moving at the level of scale of the enterprise, then you've got to worry about true architectural issues that means you need some other structures in place. You probably need an architecture board, you need some chief architects, you've got to apply those notions at the enterprise level, not just the team level.

HOLITZA: Right, right. So, you know, one thing that I've heard about, too, is this concept that Agile teams use note cards to document their requirements and their user stories, I guess they call them. So how does something like that scale in an Agile world on an enterprise...

BOOCH: You get bigger cards, of course.

[LAUGHTER]

No, I'm just kidding.

AMBLER: White boards.

Yes, it's pretty hard to scale cards. So, I think the index cards definite work well for collocated teams, but once you get out of the...you know, once you get into that space, then suddenly you need some sort of electronic format, some sort of electronic way to capture the information that you're trying to share between the teams.

And this is I think one of the reasons why I started to looking at some of the Jazz platform, because it really is geared to split Agile development in a distributed manner like that.

BOOCH: In effect, Jazz makes the Web as the virtual meeting place for these teams that are both temporally, as well as geographically distributed. And notice my intentional use of those phrases there.

We've been talking about geographically dispersed teams, but one also has to deal with temporal distribution in the sense that especially at the enterprise level, you find that groups build something and they off and do something else. And that previous legacy is something that then gets integrated.

And preserving the knowledge, the tribal memory of that, is something that the Web provides a great virtual meeting place to observe those things. The code's the truth, but the code is not the whole truth.

HOLITZA: Right, you want some kind of living documentation, right?

BOOCH: Yes, living. Just the minimal necessary because there's a lot you can gain from the code itself, but there is also things you cannot determine, you can't grock just by looking at the code.

HOLITZA: Right, right. Do you have something you wanted to add Scott?

AMBLER: No, I think that's well said. I think that the minimal documentation is actually critical, and just observing the fact that, you know, temporal distribution is absolutely critical.

Systems are long living. I think that I've lost track of the number of systems that I've been involved with where we honestly intended that they would only last for six months. And then 10 or 15 years later, you're getting phone calls about them and people asking questions about how it was built and what you were thinking. So keeping the temporal issue in mind is absolutely critical.

BOOCH: Every code you write today becomes tomorrow's legacy that your children's children end up debugging.

HOLITZA: Right, right.

AMBLER: Exactly.

HOLITZA: Well, guys, you guys are looking awful dapper. I think we should get back to the party, and maybe get together again and talk some more about maybe some of the issues around working with Agile and legacy systems, and maybe talk about some other things to wrap up our conversations. What do you say?

BOOCH: Gladly. There's a great jazz club that I can take you guys to when we're done here.

HOLITZA: All right, let's get out of here.

[ MUSIC ] [END OF SEGMENT]

Video not available.