ZDNet UK

• CNET NETWORKS UK BUSINESS SITES:
• atlarge.com
• BNET UK
• silicon.com
• SmartPlanet.com
• ZDNet.co.uk

Making sense of agile modelling

• Tags:
• Documentation,
• Evolve,
• Courses,
• Skill

Nick Gibson Builder AU

Published: 10 Jul 2007 15:19 BST

• 
• 
• 
• 
• 

…then it makes a lot of sense to put a little bit of effort into this. Yes, it's going to take several years to pick up these sorts of skills but, percentage wise, it's not such a bad thing.

You've got to get hands-on experience and you have to work with other people who know how to model. There's nothing special about modelling; it's hard to learn unless you have someone to talk you through it.

So, if it's mostly down to experience, what do businesses need to look at if they're looking to hire new people for a modelling job?
A couple of things. The things I'd look for in people: existing experience is good, but are they willing to learn? Are they willing to work side by side with others? Are they willing to work iteratively and focus on software? We've been talking about modelling a lot, but the reality is your goal is to build software; it's not to model.

I think a lot of the professional modellers out there — that's what they struggle with, because what they've been taught for decades: "Do this modelling up front; you're the business analyst; hand your stuff off to someone and they'll take it from there."

No, I don't need that; I need people who can do a bit of analysis, a bit of design, a bit of coding, a bit of testing and then iterate. I don't need someone who's just going to model, or just going to code or just going to test.

I think that's the major difference we're seeing now in the community — people with all-rounded skills. So we've been calling that "generalised specialist", other people call it "craftsperson" or "renaissance developer"; the Gartner group has this new word: "versatilist" — it's a specialist that's versatile, or a specialised something. It's a brutal word; they must have not tried to pronounce it. I don't know what they're thinking, but the idea's right.

Any final thoughts?
I think main thing is just to developers — be fair to modelling.

I think for developers who are a little down on modelling and documentation — it's not a black-and-white world. Modelling is not evil. Documentation is not evil. The goal is to be just enough.

For programmers, you can definitely become significantly more productive if you get some modelling skills. For professional modellers, people who have been told to do all this detailed modelling up front, they can become more productive by doing less modelling and by doing it just in time.

There is significant evidence out there, if you choose to look into it, that a detailed requirements specification early in the lifecycle is actually a bad practice not a good practice. There's evidence out there that doing a detailed design early in your project has no actual effect on the outcome of your project. You're equally as likely to succeed as you are with no design, if you do a whole bunch of detailed design up front, and those are both extremes.

It's not a black-and-white world. I'm not saying: "Don't do any design." I'm not saying: "Do a whole lot of design." Agile modelling is all about finding that sweet spot somewhere in the middle of just enough design, just enough requirements for the situation at hand.

This is what gets missed — the people at either end have to come to the middle. There's no coherent reason to model up front. It's the worse time to model. You can't think things through up front. We know this — we've seen projects fail time and time again from doing this stuff. If you have the skills to model everything up front today, then surely you'll have the skills six months from now when you actually need all that information. Why can't you wait? There's no good excuse to do everything up front.

The longer you wait to gather information the more chance there is that it's information you actually need — you can ask more intelligent questions. If I model something today, then I know the least amount of information about my models. If I model six months down the track, then I have six months more domain knowledge — I can ask better questions. My stakeholders have seen six months worth of software delivered — they can give me better feedback.

So it's far more efficient to take an agile modelling approach than traditional modelling. It's the bridge-building theory; software development is a lot like building a bridge. Well, no, it's not.

The only people telling me that are people who don't build bridges. Although it's interesting, the people who have experience building bridges and building software will tell you that building bridges is a lot more evolutionary than we think.

• 
• 
• 
• 

• Share this article:
• Digg
• Slashdot
• Del.ici.ous
• Stumble
• Reddit

• Most Recent
• Most Popular