how do you think agile methodology differs/should differ between b2b and b2c startups? how can weekly sprint and monthly interation planning take into account a long (~6mo) sale cycle? what're the strategies to negiotiate the uncertainty of exploratory feature development and debugging with the need for contractual deadlines?

I'm actually working on a blog post about this on the heels of my "estimates are stupid" blog post (mattrogish.com).

Ultimately I think the problem (as I see it) is that the negotiation process is fundamentally broken; most client work puts too much risk on the provider end and the deal is negotiated by folks who have the wrong incentives.

I think, with appropriate negotiation, incentivization, and value identification steps, you can arrive at a mutually beneficial arrangement.

It's kind of a non-answer, yes, but I think fundamentally the system dynamics are broken, so there really isn't an "answer" per se. :)

yeah, your blogpost was what got me thinking about this. i really liked your post, but as you know- where I'm working right now doesn't have the same organizational values you espouse, and to a certain extent: it can't. we're trying to working in an agile way, with a somewhat contradictory business plan.

additionally, we're transitioning our target client-base, which radically changes sales practices and user needs. i think there's space to create or reform the agile methodology to compensate for the unique needs of that type of organization and it's something i'm working on right now.

key questions i have:
1) accommodating large bureaucracies that have a lot of unique and often out-dated third-party integrations that require implementing a vast array of unique SDks (if only there was plug+play)
2) maintaining legacy clients while building for a new set of user needs to attract a new client base
3) how to align announcements with the potential release dates of major features to optimize sales given a long sales cycle
4) quantifying (for the purposes of comparing) the value of feature requests that originate in speculative negotiations vs. home-grown feature requests aligned with existing product strat
5) negotiating the timeline of new features vs. refactoring existing infrastructure to build capacity for future features

I'd be curious to see what part of agile is failing you? That might help answer the question.

Reading between the lines and pulling from my experience, my suspicion is that Scrum's iterative-based development using relative estimation (points, are you 1,2,3,5,8?) isn't proving to be very predictable when it comes to dealing with providing an estimate for client work?

The two problems as I see it is that:
1) You're not doing custom development for the client, you're adding features to your core platform on behalf-of a client (it's not like the client has copyright on the finished work-product, like a normal consulting shop)
and
2) You're assuming *all* the risk and you can't price it into your quotes (because of the nature of the product)

Because of the two constraints, you're in between a rock and a hard place. You need to charge your clients for the work, but since they're not owning it, you must charge at a heavy discount. And, your development staff gets paid whether or not you get the client, so any effort spent estimating that doesn't result in a sale is lost work. Any effort spent *over* the estimated hours is not recouped by charging the client. And since the features are one-off there's no economies of scale.

The "iron triangle" (ambysoft.com) limits what you can do. It's worth a read, but the tl;dr is that since TIME and SCOPE and BUDGET are fixed, the ONLY thing you can compromise on is quality. That's hard to do: joelonsoftware.com

Then there's this artima.com

So, my guess is that you should find a way to get the custom stuff done as cheaply as possible: quality doesn't matter, but asking your dev staff to ship shit is toxic to the culture.

Outsource it to the lowest bidder.

Have your in-house staff work on the high value projects that support your strategic goals.

If you have the time, and a client's one-off becomes something others want (or the client engagement grows) you can make the investment to do it "right" and rewrite it with internal devs.

In terms of speculative negotiation (specwork) you should probably use the lowest bidder folks and grind them to get it ASAP, use it as a prototype, then do the math to see if your devs should do it.

I assume you've got statistics that give rough probabilities (heuristics) for any deal going through, the size of the deal, etc. That gives you an expected value for any given deal. If the prototype is more expensive than the EV, pass. If it's under, and the rough estimate for the final item is over EV, pass. Else, give it a try. Something like that.

Also, in regards to refactoring there are generally two kinds of refactors:
1) paying off technical debt (accrued by compromising on quality to hit a date or other external pressure) or
2) restructuring based on new data

Depending on the magnitude of the capacity increase, you should be able to time-box the refactoring (e.g. gives 40% improvement, expect to do it twice, it should take 4hrs)

Anyway, like I said, I'm curious what part of "agile" doesn't work for this. Most of the items you mentioned are really business problems and not technical ones, to which agile is mostly quiet.

I hope some of those ideas I have are valuable, I'm interested what the others in this branch think? Am I way off base? I could be terribly, terribly wrong. Happens often. :)