Agile Modelling with IBM's Scott Ambler

It's common for many programmers to be suspicious of modelling, but it doesn't have to be that way. We talk to IBM's Scott Ambler about how you can use agile modelling for any project, and why you probably already are, without realising it.

Builder AU: What does agile modelling mean to developers in the Web 2.0 world?

Scott Ambler: The goal of agile modelling is to describe a collection of principles and practices for modelling and documentation, preferably on agile projects, but if they're not so agile then that's OK too. What we've seen is that the major use was in XP [extreme programming] to make modern documentation more explicit, or with the RUP (Rational Unified Process) to sort of ramp down some of the bureaucracies and make it as streamlined as possible.

It just describes ways for you to be effective with thinking through some of the things you're doing without taking a hit from needless documentation. From an agile point of view it gives some explicit strategies for how to protect yourself from the bureaucrats who want you to do way too much documentation, and provides some advice to govern some of the things you're doing.

Some of the more extreme rhetoric in the agile community really motivates some people to do the wrong thing, not picking on agile fans, but that's probably the wrong way.

"Hey, I did all this modelling and it didn't have any affect on the product whatsoever, what a waste!"

On the perception of modelling.

What do you think the general opinion from programmers is on modelling in business?

I think that a lot of programmers struggle with modelling, for a lot of reasons.

First, they haven't got good training in it. I don't think that schools do modelling justice at all, they might never for all I know, but they certainly don't do it well now.

A lot of the time developers will show up to their first job and the first time they do modelling they'll almost always be put into one of two dysfunctional situations. Either they'll be put into a project team where you're given all this modelling up front, and then you ignore it towards the backend. So they see all this wasted effort around modelling documentation and then they say "Hey, I did all this modelling and it didn't have any effect on the product whatsoever, what a waste!" And so they get bitter about modelling.

Or worse yet, they'll do the work, they'll successfully deploy the project into production and then someone will come along and say: "Well, now we need to spend the next two months writing all the documentation we should have to make it look like we followed the process." That is a complete waste of effort, that's just somebody justifying their job, it has nothing to do with delivering value. A lot of developers get bitter about this sort of stuff.

Another common issue is that they struggle to distinguish between modelling and documentation. If I'm doing a sketch on a whiteboard then that's a model, but it's not a very good document. What will happen -- and in a way the fault lies with the vendors because we want to sell CASE tools -- is that we try to convince developers that modelling has to be done with these heavy tools.

Well no, not all of it -- and let's just observe the fact that a lot of modelling will happen on whiteboard and it will happen on paper, and that's perfectly fine. When you want to get more sophisticated though, you need more sophisticated tools. For example, I've got pretty good modelling skills, so I'm far more effective using a tool like RSA (Rational Software Architect) or RSM (Rational Software Modeller) to do my modelling, and then generate my code and generate my database stuff than I am "hand-jamming" it.

It's just crazy writing code when I can generate it -- I'm assuming that the tools generate decent code here. The problem is though, that it requires a heck of a lot of skill -- if you don't have that skill, and haven't taken the time to get it or been in a situation where you can work with someone who does it, then that's pretty rough. A lot of developers are finding that given a choice they'd do more modelling, but they haven't had the opportunity to learn it well.

We definitely need to distinguish between models and documents, they're totally different concepts, and while some models will evolve into documentation, many will not and that's perfectly fine.

How strong is the connection between modelling and documentation?

It's very strong in the traditional world, which is why we're all so hung up on it, but really it's not that strong at all. Ninety percent of modelling is done on the whiteboard and in a recent survey we did, modelling turned out to be the fourth most effective practice being done on teams. Paper modelling was not that popular, for all the stories about User Stories and CRC cards and whatever, which is what I like to see.

The vast majority of it is done in these throwaway kind of models. But you can make a very strong argument that writing a test before you start writing your code is actually modelling, you're specifying your program before you start writing it. Just because I'm not doing a UML diagram doesn't mean I'm not modelling.

Most models will not evolve into documentation, some will, but a common thing you'll see in an agile team is whiteboards everywhere and people drawing models and so on, and over time you'll see them evolve. What will happen when you get down to writing documentation is that the models that survived on the boards are the useful ones, the ones you put into your tools and you write-up and make look good and so on.

On the educational side, what do you think needs to be done to fix this situation?

Well I think universities struggle with a couple of things: Firstly they just don't have near the funding they need, and they never will, that's just the way it is. They also, for whatever reason, tend to shy away from group work. Modelling is a group activity and you need multiple people to do it, and you need to work together. If you are doing assignments and you are asking individuals to sketch stuff, then that's great, but they'd probably just as well be banging out code. They also chop things up into different courses, so you get the Java course, the database course, the mathematical theory course, so what happens is that the focus is just on numerical programming or whatever and they never bring the full lifecycle in.

The other thing is that they don't do projects, they'll do problem sets or they'll give you an assignment to go off and build something, but they don't say "Let's work on this system for the next two years of your degree" and so for two years they're working on different aspects. You're not getting any real world experience.

I'm not saying that it's easy to do, but these are the things that they need to start doing. I was working at the University of Toronto years ago, and one of the things we did, and it was really hard to do, was in this group work course we told students that they'd be developing a system all the way, then in the middle of the way through we yanked all their stuff and replaced it with work that had been done in previous years and said "Okay, now you're maintaining a legacy system, what are you going to do now?"

They were shocked, there was all this whining and complaining about how evil we were, but that's the real world. In the real world you have to maintain someone else's code. I've run into people years later and they've said that it was the only course that was actually useful to them, and it's because that's what's happens, that's real. You need to simulate things like that, and it's hard.

I want to know why can't a third year computer science course just take on an open source project, why couldn't the assignment be that these three people work on some project they want and they have to show evidence that they added a feature that somebody was actually interested in -- they designed, implemented, tested and delivered it. That would be the entire work. That's an easy thing to do and it would be much more useful.

Just because I'm not doing a UML diagram doesn't mean I'm not modelling

How important to do you think agile development processes become when you've got a more globalised development model?

It's critical for a couple reasons. First, people are doing it, so for people doing offshoring, why can't the offshore team work in an agile manner? Nothing's stopping them. Why can't the onshore team work in an agile manner? Nothing's stopping them either.

So the issue becomes how you communicate between those teams, and you have to be smart about that. How do you organise your teams in such a way that you can still be effective when your team's on the other side of the planet? It's never going to be totally easy, but you can be smart about it.

Give as much responsibility as possible to each location. So if I've got a sub-system that I'm offshoring, then offshore almost all of it. If the onshore team does the requirements and the architecture and then they hand that off to offshore team, you've just sucked all the life out of the project. If you've done all the big thinking onshore, you're trying to minimise risk, but you've actually increased it.

If I hand an architecture document or a detailed requirements document to the offshore team and say "build this", well, what are you going to do if you're the offshore team? You'll put your junior staff on it because it's all laid out for you -- this is what happens, anyone senior isn't going to want to do that work, you're just a coding monkey at that point.

You need to give as much responsibility as possible -- I've actually seen some very successful teams where they flew their business people to India and that was it, you had a project manager coordinating on the other end, but that was all there was. It was a lot less risky and a lot less expensive in the long run. This is actually a very interesting way of working, but you've got to have a heck of a lot of trust in the people working on it.