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."

... 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...

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.

Pragmatic overview of agile, what makes it good, what makes it challenging.

Overview, explanations, and details from Scott Ambler.  This documentation approach can be used for agile and non-agile processes.  It can also be used for product management / development and for business analysis.

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 ...

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

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 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.