Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

I think for Saas this is going to work out to be one to two weeks between releases.

Business people and developers must work together daily throughout the project.

Co-Evolution of Business and Technical Plans

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Essential in a startup.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Certainly where there is a need to get emotional calibration you need at least voice (telephone, VoIP) but face to face is the highest bandwidth.

Working software is the primary measure of progress.

If only because it’s the easiest thing for customer’s to judge. But a sales pitch that accurately represents what will be delivered is as necessary, and should in fact precede working code in the early days of a startup. Sell, then Build.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is a “no finish line” model that assumes you will need to continue to tune and evolve your offering rapidly after it’s introduction.

Continuous attention to technical excellence and good design enhances agility.

Especially if you can measure what you mean by excellence and keep score transparently for the whole team.

Simplicity–the art of maximizing the amount of work not done–is essential.

Simplicity forces you to focus on customer’s key needs and minimizes the work needed for the next release. Giving the customer software to work with speeds their understanding of their true needs faster than almost anything else (if you start by observing their actual behavior in their environment).

The best architectures, requirements, and designs emerge from self-organizing teams.

This to me seems a little to IT or development centric. Many times visionary customers will supply critical insights on architecture and requirements.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Wynton Marsalis advises that “the humble improve.” You need to balance regular celebrations with an appropriate amount of both internally driven and customer solicited evaluation of quality and productivity (yes your customers are making an assessment of how productive the team is and how quickly you can understand, master, and deliver on emerging needs).

More to come on this, in particular what one to two week release cycles mean for how you organize and execute as a software startup.