"Those of us living in the world of software need to remember why we're in this business. It's not about process, it's not about methodology, it's not about how Agile you are. It's about creating kick ass software that users love. Users can't fall in love with something that isn't shipped."

Actually, those were created in order to ship. In order to fulfill customer expectations, in order to make sure the customer's software does what they want it to do, not how the developer wants it to do.

It's not Agile if you aren't meeting that.

I will go as far as to say that if it is about the customer in Agile, then when it ships is secondary to 'did it meet their expectations'.

The users should be falling in love with it long before it ships because they see it's progess iteratively and know exactly what it does and have made all the decisions leading it to what it does.

It isn't agile if you are pulling a red cape off an unknown entity (think 'IBM commercial).

Just recently I've watched a developer lose total sight of the customer, the product is late, the customer has seen it once, and the customer is piping mad on why he isn't seeing progress. It's now due in July in and was originally due in November of last year. Developer doesn't follow any agile software practices and likes to tell the customer what his product should be rather than listen to the customer. At this point it's like being in an emergency room trying to save a patient.

I coach sports and Agile is like this: great plays don't get you far without great execution and great finishes.

I know exactly what Agile is all about. You're exactly right that Agile is meant to help you ship, and its meant to help ensure you fulfill customer expectations. But in the end Agile isn't what it's about. Agile is the means to an end, not the end. Shipping software is the goal. It goes without saying that shipped != success. There is a lot more to great software than just shipping it. It needs to do what the customer wants, it needs to empower them, and it needs to help them kick ass. Agile can help increase the likelihood of all these things, as well as increase your chances of shipping in the first place. But Agile isn't some magical potion that you can just sprinkle on top of your software. "Being Agile" shouldn't be our goal, shipping kick ass software should be.

Shipping (or going to production) is a consequence of a completed product. We show the progress to clients every Friday, it's up to them to say, 'hey, this is all I need to put it online'.

So I don't think our world revolves around shipping a product, but instead get it done fast and get it done right.

Why do you need to get it done fast and get it done right? Is it so it can be "shipped", and your client can start seeing value from all the work you've done? :) Without getting it done fast and getting it done right you can't ship. Without shipping you're client won't be happy.

They get it done fast and right so it's less expensive to the customer who will hopefully support your next product :)

But the cost of something depends on when it ships doesn't it? If it doesn't ship you need to keep paying for it to get developed (depending on how you bill). Shipping lets you move onto the next product. If you don't ship you customer won't have you build the next thing. They need "this thing" before the "next thing". Right?

>>We show the progress to clients every Friday, it's up to them to say, 'hey, this is all I need to put it online'.

That's all well and good when you are doing a specialized product for ONE customer or some internal IT project. What about when you have a general large Financial Services product with over 70 different customer banks? You have to know roughly when you are going to ship so that the marketing folks, sales folks, services folks can ramp up their plans to be ready at some point. And customers making $1 million+ purchases have to be given some committments. You can't just "put it online". Shipping is important and Soul of a New Machine gives that great analogy of this being pinball. You play to win, to get to do V2 and V3, based on shiping kick ass products that meet the customer needs.

We do have ONE customer for a certain sub-product and we DO weekly Iterations for them. They get regular releases and they're happy. I do think we know Agile as I was there when Ron Jefferies, Kent Beck and others developed it in front of me and others on Ward's Wiki in the years 1996-2000. I have been doing XP ever since. Jim Shore spent 3 months with our dev team and said we are one of the best Agile teams he has worked with. I think we get it.

I also get some people misuse Agile and the process becomes everything. More and more time is spent on Retrospectives. Endless refactoring can go on. People chant that they don't have to have a freaking end date to ship the product because they're "Agile." Bull. I say it's important to be a Shipper, to be able to make the tough decisions to get a product out there with good quality so that you can get to market. Then you get to play again another day, and another...