Useful list of possible approaches to make up iterations in agile product development.

... another benefit of having such a Knowledge Base System in place is that it is a valuable source of customer feedback. ... You, as a product manager, could be monitoring the system to understand better what your customers expect from your products...

An excellent introduction to, overview of and fairly comprehensive discussion on continuous integrations. Here's an excerpt from the page: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage."

Very detailed analysis of how usability can be a key component of agile methodologies. Explores the misconceptions and challenges of both schools with respect to the other. Details the agile development methodology. Contrasts the philosophies of both agile and UEX approaches. Discusses user-experience modeling in an agile framework with great examples and explanations.

Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline - and we can apply it to any form of project-status. In this article, we will apply it to documenting business processes.

The topic of applying agile methodologies to your business processes seems to have become quite popular these days. The benefits of becoming agile are pretty attractive for software companies and yet many of them still do not clearly understand how they could make a smooth transition and whether this “agile” thing really works ...

Good article by Jeff Lash about how product managers should keep an open mind about agile development practices and how to adopt them as part of their product management approach.

Good case study / anecdote about how a company responds to competitive pressures in the agile vs. waterfall world.

From the article:

Two years ago, in response to emerging customer needs and a surge of new entries into the network monitoring market, Ipswitch realized it had to pick up the pace of its product development strategy. Although the company's software had been widely regarded as among the best and easiest to use, the game had changed. Overseas companies had started to become serious price competitors. And a number of domestic startup firms, armed with marketing tactics fortified by strong venture funding, had also aggressively entered its space. As a result, unless the company could deliver its products to new and frequently inexperienced customers in ways that would work right the first time, Ipswitch's managers knew their market edge risked being lost for good.

From Scott Ambler:

One of the great debates raging within the IT industry is whether or not agile software development techniques work.  My experience, and the experience of thousands of others, is that they do.  One of several reasons why agile techniques are so effective, in my opinion, is that they reduce the feedback cycle between the generation of an idea (perhaps a requirement or a design strategy) and the realization of that idea.  This not only minimizes the risk of misunderstanding, it also reduces the cost of addressing any mistakes.  In this article I explore this idea in detail. 

From Rachel Davies:

In the last few years, the agile software development movement has created a paradigm shift in how we work to understand system requirements. Agile teams shape software systems using a collaborative process, with executable software at its heart and documents marginalised to a peripheral role. This creates a fundamental shift away from tools for managing requirements artefacts. Instead, we need tools that support collaboration and the gradual distillation of business rules into automated test suites.