Scott Ambler

author
+ Follow
since Dec 12, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Scott Ambler

This coming week in Dr. Dobb's Journal we're publishing our 2008 agile adoption survey results. We asked about agile team size, and some people indicated that they've succeeded at teams of 200+. IBM has shipped product into the marketplace with agile teams of over 200 and we currently have several teams around 5-600 doing agile.

My July 2008 column, online the first week of June, describes strategies for organizing agile teams of varying sizes.

- Scott
The plug in is currently being used internally and at a few select customers in beta. It isn't yet available publicly. I don't have an exact date of when it will be available as GA.

- Scott
Hmmmm... I've seen CC work fine for very large teams. Perhaps you didn't have it installed correctly?

Anyway, as for the agile plug in the best source would be the developer support page but I don't see it. I'll ping the guy who headed up the effort and see what's what.

- Scott
I would suggest reading Phillipe Kruchten's Introduction to RUP book. It covers the basics really well.

An agile version, and a little more up to date, is Agilty and Discipline Made Easy by Per Kroll and Bruce MacIsaac.

Between the two books you should be ok.

- Scott
15 years ago
ClearCase is probably overkill for a team of 4 people. But, if you have 400 people, or 4000, spread out across multiple locations around the world then suddenly it makes a lot more sense.

For a distributed team you'll want ClearCase multi-site.

For an agile team you'll likely want the Agile plug-in. I'm not sure what the public facing name is (likely something really obvious like ClearCase for Agile).

- Scott
At my java articles I have links to a series of articles that I wrote 5-6 years ago on this topic.

- Scott
I've written about distributed agile teams in detail here in part 1 and here in part 2. I might get part 3 online this weekend.

- Scott
The goal should be to use whatever models, if any, get the job done for you in the situation that you find yourself in. Activity diagrams appear to be working well right now for you so use them. Perhaps on the next project that you're on you'll be working with a bunch of BPMN, which is part of the UML now by the way, people. So BPMN will be the better option.

- Scott
Agility At Scale
You might want to read my articles on initial requirements envisioning and initial architecture envisioning to get a handle on how much up-front modeling you might want to do.

- Scott
Yes, this unfortunately happens all the time, which is why myself and others have been pushing for accepted criteria to determine if a team is agile. Until we have such criteria we'll have the problem that ad-hoc hackers will claim that they're agile.

- Scott
For a full view of an agile development lifecycle, my Agile SDLC article gives a good overview.

And yes, there is a bit of hype around agile approaches by it does seem to work better than traditional approaches in practice.

- Scott
The shapes of the bubbles and lines are different. ;-)

- Scott
You might find The Agile SDLC to be of use as addresses the entire software development lifecycle instead of just construction.
- Scott
Talking about techniques, tools, ... often will lose the game for you. You need to be able to talk in business terms to them, the explain the real benefits of doing agile.

What are they concerned about? Quality? Spending the money wisely? Time to market? Without knowing what the really want, how they define project success you're merely shooting in the dark.

They might be concerned about issues that developers generally aren't interested in, such as governance (which is good news because it is easier to govern agile projects) or documentation.

You might also need to make it explicit to them that traditional approaches aren't as effective as people hope. For example, writing a big requirements document up front isn't such a good idea. They inherently know this, but might not know that they have better options.

- Scott