As part of a response to a ME vendor, and a promise to an old friend... I am posting this partial from the SHAPE forum at www.geraldmweinberg.com. Worth a stop by to read about sensible software practices. Members are a who's who of agile software development. ....

Responding to Startup's thread posted by JB ...

JB >>

Well, there's all kinds of stuff about "those people" doing silly things and how to change it, particularly in established companies with some history. What about startups or spin-outs, or new divisions or any other time you get to do some broken-field running? In my experience they are at least as prone to doing counterproductive stuff as established places. I'd like to hear about it, good and bad.

I know we have several folks lurking here who are or were part of early stage startups, several more who have been part of later-stage startups some big, visible successes with lots of press. We also have a bunch of folks who make their livings telling other folks How It Should Be Done(tm). What's their take when everything is a blank piece of paper?

I'm in the midst of one, my third pre-public one in the last five years. They have a product - sort of. They're scaling up delivery into the market. And as they scale up, it turns out the way they have been doing this or that doesn't work so well any more (if it ever did.) I'm glad to toss in examples & anecdotes from any of my three to keep the conversation lively.

<<
JH >>
My experience has not been very good, most startups cannot scale because the behaviors that get a product out the door, are not the same that sustains the product revenue flow.

I recommend that you ask that they 1) plan for a product line, 2) set out the development principles, and 3) learn software management.

Startups generally build a Product but not a Product Line. Most never survive long enough to know the difference. A product line is a planned series of products drawn from common assemblies for a long term revenue stream. A product line is an essential step to a wide customer base. Recommend developing a product line architecture for manageable product life cycle. CM and QA for a small project does not scale to a multi-customer product line. http://www.sei.cmu.edu/product lines/companion/arch_def.html

Second, Understand good. Agree on the principles of good software development and write them down. Jerry's comment on success is half of the battle, the other half is to get agreement on good.

Third, The roles of software management (as a product portfolio) and software project management. Define the measures of quality for the product and the measures of effectiveness for the business. Site visits are key. Visit successful companies and learn from them.
<<

Best