I am not clear what experience Mr. Starr has with salesforce.com but we are one of Salesforce.com’s larger clients and are not deeply imbedded into an API version. We choose to use an API version for features within that version, for applications that don’t require that new feature we can stay on the older version or move up. So in that sense our applications are an extension of Salesforce.com’s core functionalities rather a wrapper around it.

As to the point of “Ship It;” the incremental deliveries can be partial smaller working functionalities of a larger release released to Staging every cycle (2, 4 weeks) and ultimately combined into a single Live release (Qarterly for example.). There is nothing in the third principle (Deliver working software frequently) that says you need to go Live.

Earlier without Agile practices it wasn’t possible for development teams to deliver regulary now since they can deliver regularly I think IT teams should also INSPECT and ADAPT at the changing scenarios, Agile is the mindset which has to be embraced by an entire organization rather than just a few geeks to get its optimum value.

However, I do think that part of the model working with sales organizations is backward. Some sites like Dell and Amazon continually tinker with their sites and nobody seems to mind. Their secret is that the changes are incremental and the interface is intuitive. Retraining should be minimal or unnecessary.

I don’t believe agile is appropriate for every project but it does show results to the business community quickly for feedback. Waterfall methodologies, with their long development cycles, often go astray of business requirements. By the time they realize the discrepancy its too late to correct.

thanks.

Our WSDLs are dynamically generated, so those change as we upgrade the service. Actually, they are dynamic down to the field level, based on version, permissions, features purchased or activated, who you are, etc, a whole raft of options.

Given the complexity of those combinations, we offer a number of calls that describe additional metadata beyond the type info of the WSDL, e.g., is this field updatable, or createable. All that also has to be versioned (usually).

Here are the API docs.

http://wiki.apexdevnet.com/index.php/Web_Services_API#API

the Describe calls are the additional metadata ones I mention.

Wow. That is cool. Seriously cool and it is interesting to hear how you are bridging the backward compatability gap with what I assume are message interfaces to the same codeset?

Nice, man.

We use agile extensively, and a lot of the items you mention are rolled into the 2 or 4 week sprints. Usability, internal and external docs, systesting (mostly) are all required to be done before a feature is considered finished. Our release sprint is pretty small, and we’re trying to make it smaller.

Of course, the functionality you can deliver in 2 weeks might not be a fully baked “feature”, so the notion of versioning and optional activation has to be baked into your infrastructure (and dev/qa culture) at a pretty fundamental level.

We have a few people that are starting to speak at Agile conferences about scaling agile, I’ll see if there are any online slides.