[DanielBMarkham]

I'm consulting for a really large client, teaching teams how to deliver technology quickly, so I'm not working on my startup. I don't believe you can do a startup half-way.

But in my spare time I'm thinking about writing a book about how to run Agile projects in large organizations. If anybody is interested, drop me a line. My email is in my profile.

[jkush]

Do you see a difference between teams using Agile to maintain existing products and teams building brand new stuff?

I've found in my experience so far, that Agile works better for new development and can't or shouldn't be used as a hammer for everything.

[DanielBMarkham]

I think in general you are correct, but the devil lies in the details. The way people think about the word "agile", oddly enough, can be really inflexible. Somebody gets a CSM, reads a few Cohn books, or gets hooked on Crystal. Suddenly their definition of "agile" is exactly what they read -- no more and no less.

I read once that a programmer tried agile and gave up after arguing for two hours about what to put on the story card. This kind of BS happens a lot: it's the nature of dealing with large numbers of people who see things as binary. If you understand the _principles_ of agile, and why they work, then all the books and authors are just re-digesting common sense and peddling them as books. At that level of understanding you can work on all sorts of things: new development, existing development, non-software work, etc.

That's where my team is trying to take this organization I'm working with. The problem is that influencing large populations (thousands and tens of thousands) of technical people is far worse than herding cats. It's more like trying to get angry flaming weasels to perform circus acts by using a twinkie and a Disney song.