ZDNet UK


Skip to Main Content

ZDNet.co.uk - Winner of Best Business Website 2007
  1. Home
  2. News
  3. Blogs
  4. Reviews
  5. Jobs
  6. Resources
  7. Community
  8. My ZDNet

 

ZDNet UK RSS Feeds


Application development Toolkit

Making sense of agile modelling

Nick Gibson Builder AU

Published: 10 Jul 2007 15:19 BST

  • Email
  • Trackback
  • Clip Link
  • Print friendly
  • Post Comment

…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.

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. Firstly, 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 the 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.

For all the talk about communication in the agile community, we really struggle sometimes to communicate what we're doing

Scott Ambler, IBM Rational Software

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 co-ordinating 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.

What would you say to a developer that is dismissive of agile modelling as being unnecessary?
Well first of all, if you're doing agile [software development], you're really doing agile modelling without realising it.

So I start asking questions like: "Are you doing any whiteboarding?" and the answer's: "Yes". It's hilarious. If you go and look at an XP team in operation, there's always a whiteboard in the background with diagrams on it, or a corkboard with index cards, and those are both agile models.

So they're doing this modelling stuff but they're not recognising it as modelling. The planning game in XP — that's a modelling activity, right? So, if you're doing a one month iteration and you're spending the first half day or day planning out what you're doing for the next month, then a lot of that is going to be modelling; you've got a bunch of people together in a room, you're talking it out, filling out your cards and going to the whiteboard, and drawing, sketching and arguing and so on. That's modelling. So they're doing it; they're just not calling it modelling.

What happens as a result is that they talk to management, and they talk to other senior developers, and, since they don't understand and can't communicate what they're actually doing, then they're dismissed by senior management.

Management thinks: "Oh, they aren't doing any modelling, you low-end scumbag hacks". This is what they're thinking because in the '70s and '80s they saw this sort of thing happening by the code fixers and now what's happening is many of these extremists seem bound to the traditionals like code fixers and so they're written off — they're not the same, but it sounds like it.

So, for all the talk about communication in the agile community, we really struggle sometimes to communicate what we're doing, and this is a critical thing. If you're scaling, if you've got any sort of complexity to deal with, if you're offshoring, then you're going to be modelling, you are going to be documenting. Even if you're not modelling…

  • Email
  • Trackback
  • Clip Link
  • Print friendly
  • Post Comment

Did you find this article useful?
20 out of 28 people found this useful


Company/Topic Alerts

Create a new alert from the list below:










Discussions

andyraff99 andyraff99

Questions regarding IT services

Saturday 6 September 2008, 5:46 PM

1 post
182706 182706

dont forget fixed wireless

Saturday 6 September 2008, 5:21 PM

2 comments
ysridhar ysridhar

poweredge

Saturday 6 September 2008, 3:59 PM

1 post
Tezzer Tezzer

Perennial or Hardy Annual?

Saturday 6 September 2008, 3:15 PM

3 comments

Featured Talkback

The fact is: Software developers today are really designers and not coders. The reason that business anlaysts exist today to model solutions is because they understand the value of designing software before writing it. All too often developers create code that has little value because they do not understand that business classes interact with other classes within the confines of a working model or pattern.

By: 1000165269

Read full story:
Making sense of agile modelling